Become Shell Literate

Post by dafoex » Sat, Dec 12, 2020, 6:35 PM UTC

Closi wrote: post #28

tutfbhuf wrote: post #4

I wish that shell would be more sane. I don't think that a shell should be a complete programming language. If you need a programming language, then better use one. There is xonsh if you are looking for something like this. I think there should be a better bash with an very clean and consistent interface. Some of the most commonly used utils like awk '{ print $2}', sed, grep, sort, ... should be included out of the b…

> I think there should be a better bash with an very clean and consistent interface. Absolutely! Some work should be put into making it way more intuitive. Having to remember what every flag means (which is different in every app!) is not intuitive at all. By default there should be some sort of intelisense auto-complete which can also provide guidance on what on earth all the flags mean, and maybe eventually it coul…

Post by layer8 » Sat, Dec 12, 2020, 6:37 PM UTC

enriquto wrote: post #17

CJefferson wrote: post #15

Earlier quoted context omitted.

One of the best things (in my opinion) shells could have done is do newline separated filenames instead of spaces, which would make filenames with spaces much easier to handle (you can have newlines in filenames, but in this magic world let's ban those).

That would pose problems also. The real solution, with no need to magic as you say, is to disallow spaces at the filesystem level (just like slashes and the null character are forbidden). For users typing filenames, this shouldn't be a problem, as those can be encoded e.g., as unicode's non-breaking space. Using space as a separator is a very important power, that other programming languages share. In what other prog…

Post by boogies » Sat, Dec 12, 2020, 6:42 PM UTC

acabal wrote: post #26

jancsika wrote: post #18

I can just never get past the arg/flag inconsistency/complexity across commands. Perhaps if the docs started with a simple example of what has been seen over time to be the most common incantation for each command it might be tolerable. But as it is, I spend more time dealing with idiosyncracies of a command than I do expressively piping stuff. Perhaps if Rust had five mutually incompatible borrow-checkers which get…

The inconsistency sometimes bothers me too, but it makes me feel a little better to remember that so many of the CLI commands we take for granted are part of an old historical heritage. The inconsistency is part of that heritage--today's CLI wasn't designed all at once by one group, but rather evolved over 50+ years from many contributors, back when nobody expected that people would still be using `sed` in 2020. For…

Post by turbinerneiter » Sat, Dec 12, 2020, 6:44 PM UTC

gfxgirl wrote: post #29

Someone should write "become IDE literate" as a response to opening of using vim with no extensions and using grep a lot. I've been using editors that are language aware since at least the late 90s. Depending on the language they'll show me all references, take me to the definition or declaration, stack those jumps so as I follow the links I can pop back a level to where I was. All of this is instant. 1000x faster th…

Post by acabal » Sat, Dec 12, 2020, 6:47 PM UTC

boogies wrote: post #45

acabal wrote: post #26

Earlier quoted context omitted.

The inconsistency sometimes bothers me too, but it makes me feel a little better to remember that so many of the CLI commands we take for granted are part of an old historical heritage. The inconsistency is part of that heritage--today's CLI wasn't designed all at once by one group, but rather evolved over 50+ years from many contributors, back when nobody expected that people would still be using `sed` in 2020. For…

(nit) > `grep --extended-regexp` but `sed --regexp-extended` Why not use `grep -E` and `sed -E`?