Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CLI: Improved

remysharp.com

Post reply on HN
Print view View original

91–100 of 280 posts

Re: CLI: Improved

#91

Post by vram22 »

skissane wrote: post #70
AnIdiotOnTheNet wrote: post #42

Earlier quoted context omitted.

I don't feel the plain text portion has aged well at all in regards to composability. It leads to a lot of headache as the complexity of the task grows because of the in-band signaling and lack of universal format. I think it is high time the standard unix tools were replaced with modern equivalents that had a consistent naming scheme and pipelined typed object data instead of plain text.

If Unix pipes gained support for exchanging some kind of out-of-band signalling messages, then CLI apps could tag their output as being in a particular format, or even the two ends of a pipe could negotiate about what format to use. If sending/receiving out-of-band messages was by some new API, then it could be done in a backwards compatible way. (e.g. if other end starts reading/writing/selecting/polling/etc without…

>your CLI tool could mark its output as 'text/html', and then your terminal could embed a web browser right in the middle of your terminal window to display it.

Ha ha, I had dreamed up something like this in one of my wilder imaginings, a while ago: A command-line shell at which you can type pipelines, involving some regular CLI commands, but also GUI commands as components, and when the pipeline is run, those GUIs will pop up in the middle of the pipeline, allow you to interact with them, and then any data output from them will go to the next component in the pipeline :) Don't actually know if the idea makes sense or would be useful.

Re: CLI: Improved

#92

Post by bradknowles »

l0b0 wrote: post #62
barbegal wrote: post #51

I feel like these tools very much go against the Unix philosophy of "Write programs that do one thing and do it well". They try to do the pretty user interface and the underlying operation in a single tool. I prefer PowerShell in this respect where the output of each command is not text streams (as in the Unix world) but objects which can be operated on in a more object oriented way. You spend less time thinking abou…

"One thing" has never been very well defined - basically every common Linux shell tool could be said to do more than one thing. GNU `grep` supports four different pattern styles (fixed strings, basic regex, extended regex and Perl regex), has lots of options for output formatting (counting, line numbers, whether to display file names, etc.) and has a bunch of rarely-used (but useful!) options for various corner cases…

The thing I would like to see with grep is to have it optionally give me a 0 return code if it doesn't find anything.

I know why the authors chose to use a non-zero return code as the default, but when I'm using grep deep in a pipeline and doing my own checking of the results to see if nothing was found, I don't need grep bombing out the whole pipeline with a non-zero return code.

The alternative of being forced to use "(grep pattern||true)" instead of a plain "grep -q" is kinda painful.

Re: CLI: Improved

#93

Post by bradknowles »

burntsushi wrote: post #55
barbegal wrote: post #51

I feel like these tools very much go against the Unix philosophy of "Write programs that do one thing and do it well". They try to do the pretty user interface and the underlying operation in a single tool. I prefer PowerShell in this respect where the output of each command is not text streams (as in the Unix world) but objects which can be operated on in a more object oriented way. You spend less time thinking abou…

ripgrep definitely goes against the Unix philosophy. This is intentional. The Unix philosophy is a means to an end, and not an end unto itself. The key way that ripgrep violates the Unix philosophy is that it couples the filtering of what to search with the act of searching. You hit the nail on the head with styling, because the output of ripgrep is itself the thing that prevents composability. However, from my own o…

Which I can then pipe to "gron" so that I can make something sensible and greppable out of that json output, right?

;)

Re: CLI: Improved

#94

Post by adwhit »

dijit wrote: post #35
orf wrote: post #29

Is anyone else impressed with the quality (and speed!) of some of the tools written in Rust? I'm an avid user of fd and bat, the former being ridiculously fast. Often I find something on github, I'm impressed by the quality of the documentation, features, UI etc, then lo and behold it's written in Rust. Another one potentially for this list is tokei[1] I was trying to count the code in our repos at work and used the…

I wonder if there's a name for this phenomenon. New and not-popularly adopted languages tend to have more senior people learning and developing software using them; this leads to people (read: recruiters) looking for the people with experience.. People equate the quality of software with something innate with the language, or that the developers are exceptional. Then after being popularly adopted it slumps in perceiv…

A more generous interpretation might be that Rust has sparked a CLI renaissance, since it lets developers write CLIs that have that satisfying zip that previously was only possible in C. None of PHP, Ruby or Java is responsive enough for a good CLI tool (also, static compilation is a must for wide deployment).

Re: CLI: Improved

#95

Post by IronBacon »

bronlund wrote: post #48

I was wondering if any of you use alternatives or hacks for the cd command? I've been testing out a couple of different ones, like xd, fcd, wcd and pushd/popd, but I'm not quite sure which I should commit to or if there are better ways :)

Nothing fancy. I simply use the Zsh dirstack (with auto_pushd) so 'cd -' instead to be limited to the previous path only like in Bash, can be expanded with Tab to one of the last DIRSTACKSIZE path.

The dirstack can also be saved to a file and reused on the next session.

Then I've stolen the "up" function somewhere to cd to a specific level using a part of the path when I'm deep in a FS tree.

Finally, not limited to cd only, Zsh can also expand paths with only the initials of the dirs, so 'cd /v/c/a/aTab' is expanded to 'cd /var/cache/apt/archives/', usually with less typing required on Bash...

Re: CLI: Improved

#96

Post by nextos »

JoshMnem wrote: post #77
nextos wrote: post #28

GNU Parallel is the first thing I usually install on top of a standard Unix userland. It's almost a superset of xargs, with many interesting features. It depends on perl, though. htop is also pretty much a great replacement for top. And ripgrep a great replacement for the find | xargs grep pattern. Aside from that, I'm pretty content with the Unix userland. It's remarkable how well tools have aged, thanks to being co…

> Tools like e.g. mutt are little silos and don't compose that well. I've migrated to emacs, where the userland is much more composable. What do you use for reading email in Emacs?

Notmuch, which is IMHO superb and totally underrated.

I like it a lot due to its clever architecture. It never ever touches your email. It operates on a separate tag database.

Then, it's the task of a backend to translate tag changes into maildir actions before and after syncing email. Keeping tag to actions decoupled from the GUI is extremely clever, because it allows implementing basically any email workflow you can imagine.

For simple workflows, calling a one liner notmuch command is sufficient. You don't really need to implement anything.

Mu4e is an alternative client to Notmuch. Quite similar to Mutt. Gnus is the other big alternative. It's quite old, and complex to configure. Besides, the codebase is overcomplicated as it tries to do email in a news-like fashion. Still, it has lots of great ideas on how to deal with email from many sources. E.g. using predictive scoring.

Re: CLI: Improved

#97

Post by canhascodez »

I'm so relieved that this blog post isn't about a Bash library. It's definitely a great collection of tools; I'm going to have to add some of these to my recommendations.

Re: CLI: Improved

#98

Post by ratboy666 »

skissane wrote: post #70
AnIdiotOnTheNet wrote: post #42

Earlier quoted context omitted.

I don't feel the plain text portion has aged well at all in regards to composability. It leads to a lot of headache as the complexity of the task grows because of the in-band signaling and lack of universal format. I think it is high time the standard unix tools were replaced with modern equivalents that had a consistent naming scheme and pipelined typed object data instead of plain text.

If Unix pipes gained support for exchanging some kind of out-of-band signalling messages, then CLI apps could tag their output as being in a particular format, or even the two ends of a pipe could negotiate about what format to use. If sending/receiving out-of-band messages was by some new API, then it could be done in a backwards compatible way. (e.g. if other end starts reading/writing/selecting/polling/etc without…

I am not sure how this would work. rsh/ssh may be involved. I wouldn't even know how to express:

ssh carthoris ls /mnt/media/Movies | grep Spider

(this is just an example). Note that in this example, we have two processes running on two different machines. Indeed, the OSs and systems on these machines may be, um... different. Indeed, I routinely include "cloud" machines in pipelines. Indeed, with ssh, the -Y (or -X) option can introduce a GUI to a part of the command.

I have wished that shar was part of SUS. Also, I find that "exodus" is useful (across Linux anyway -- the systems have to be "reasonably" homogenous). https://github.com/intoli/exodus

Re: CLI: Improved

#99

Post by sharkdp »

geoalchimista wrote: post #20
another-cuppa wrote: post #13

"bat" is not a better version of cat, it's a completely different tool. cat is short for concatenate. If you want to view a file use less, and if you want syntax highlighting etc. then use view (comes with vim).

> if you want syntax highlighting etc. then use view I'd like to recommend pygmentize also for syntax highlighting. Works like cat and supports a lot of languages. But since pygmentize is written in Python, it may not run as fast as bat. (I haven't tried bat though, because pygmentize is fast enough for my daily use cases.)

I have written a short (and definitely subjective) overview of the different alternatives here: https://github.com/sharkdp/bat/blob/master/doc/alternatives....

Re: CLI: Improved

#100

Post by jgtrosh »

burntsushi wrote: post #55
barbegal wrote: post #51

I feel like these tools very much go against the Unix philosophy of "Write programs that do one thing and do it well". They try to do the pretty user interface and the underlying operation in a single tool. I prefer PowerShell in this respect where the output of each command is not text streams (as in the Unix world) but objects which can be operated on in a more object oriented way. You spend less time thinking abou…

ripgrep definitely goes against the Unix philosophy. This is intentional. The Unix philosophy is a means to an end, and not an end unto itself. The key way that ripgrep violates the Unix philosophy is that it couples the filtering of what to search with the act of searching. You hit the nail on the head with styling, because the output of ripgrep is itself the thing that prevents composability. However, from my own o…

I wonder if there is or could be a good standard way of providing decoupled tools and their coupled interface.

Last year I wrote a friendly script to search content on YouTube, which prints human-readable content if plugged to a terminal and URLs otherwise, and another one which applies a pattern to turn such YouTube URLs to the underlying video or audio streams using youtube-dl. (I don't think this plays along nicely with YouTube's ToS but whatever I'm the only user.)

The obvious use case is to look at the output of the first command, and then pipe it to the second after choosing what to watch, and find a way to feed that to mplayer. So you'd want to provide a shortcut script, maybe make it interactive… but when does it go from an alias to a new program altogether? This interaction is very intuitive in the browser and I find trying to reproduce it with a CLI tool is quite challenging.

Btw I love ripgrep, it made me look very hip in front of colleagues a couple of times.

Post reply on HN