Can we use the term text user interface (TUI) and not CLI for stuff talked about here. I don't like the confusion and I think TUI I'd appropriate, just because something is launched by command line doesn't make it a CLI. A CLI is good for pipes, these things are interactive post start.
CLI: Improved
131–140 of 280 posts
Re: CLI: Improved
#132Earlier 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…
Unix domain sockets. Bidirectional, and you can use datagrams to bypass the effort of framing data yourself.
Re: CLI: Improved
#133Earlier quoted context omitted.
"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 u…
I'm not in my computer now, but doesn't "grep -v" solves your issue? If I remember correctly, it inverts the query, so it would return 0 if there wasn't a match.
Re: CLI: Improved
#134He mentions using ccat previously, I've been using it for a while (aliased as `cat`) but I've been meaning to switch away from it since it sometimes panics. `bat` looks very nice, just installed it and played around with it a bit.
Re: CLI: Improved
#135I'm surprised that no-one has mentioned mtr yet. I like it much better than ping/traceroute and I don't really see anything in prettyping that makes me willing to switch.
Re: CLI: Improved
#136Is 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…
Have you done any comparison (even informal) of similar tools written in Rust and Go?
A very informal analysis of bat and ccat is that ccat (written in Go) has choked on large files multiple times (which resulted in panics), while bat hasn't crashed on me yet. Of course I've only tried bat on two files so far ;)
Re: CLI: Improved
#137Earlier quoted context omitted.
Git has such a terrible command line that most things are easier in (good) GUIs than on the command line. The only exceptions I can think of are interactive rebase which has a weirdly good command line interface and is really confusing in every GUI I've tried; and continuing/aborting rebase and cherry picks when there is a conflict. And that's only because most GUIs don't bother to actually implement that properly an…
I find git to be one of the best CLI programs I've ever used. There are a few things I don't like, like how `git blame` requires me to put my terminal in fullscreen to see the output properly. I wish there was an option to make the output group changes of a commit together. It could put the commit details on a line before and add a single character prefix to all lines to differentiate between file lines and commit li…
The CLI for Git is one of the most confusing CLIs I've ever seen. I can describe all the warts here, but other did that better than me:
http://stevelosh.com/blog/2013/04/git-koans/
Besides the inconsistencies, there are many gotchas which keep tripping developers. For instance, git pull always tries to merge in the remote branch, but you almost never want that. You can do: git pull --ff-only, but most developers I know don't know that and end up with a mess they have to spend time cleaning up.
The main issue is that git commands mix up so many concepts and the defaults are almost always useless. For instance, git add manages tracking files and staging commits. git rebase both deals with rebasing and history clean-up (rebase -i).
A better CLI would just have consistent clear verbs that expose the git model properly instead of mixing up concepts:
git track
git untrack
git stage
git unstage
git commit
Re: CLI: Improved
#138As far as pretty CLI diff tools goes, the prettiest by far is: https://sw.kovidgoyal.net/kitty/kittens/diff.html
The downside being it requires the kitty terminal as it uses features not present in other terminals.
Re: CLI: Improved
#139I'm surprised that no-one has mentioned mtr yet. I like it much better than ping/traceroute and I don't really see anything in prettyping that makes me willing to switch.
I use mtr every day, and I haven't seen anything that beats it.
You can even press 'd' twice, and you'll get something similar to prettyping, but you get it for each hop along the path.
Re: CLI: Improved
#140Earlier 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.
I think you should check out Powershell.
I'm actually a fan of Powershell, but unix people take it as a personal insult if you try and tell them their 70s-era tooling is inferior in some way to something designed with 30 years of hindsight.