Live data from Hacker News

Become Shell Literate

drewdevault.com

11–20 of 341 posts

Re: Become Shell Literate

#11
that one tip about using touch to modify the video file metadata resonated with me.

at the same time, it is a bit of a hack. what is the minimal non-hack version of this technique? seems abstractly like liking a file-descriptor.

thanks for the article. it reminds to get better at awk.

Re: Become Shell Literate

#12
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…

It wouldn't be coherently unixy if it was. Small tools that do a limited subset of things, and reliably take/output data from stdin/stdout is the way unix is done. sh is just the glue we use to tack it all together.

Bash (and other shells too) is like it is, because it's an accretion of 50 years of history rather than a singular top down design.

Re: Become Shell Literate

#13
Author here! Some extra tips for HN:

If you dislike POSIX sh, consider looking at Plan 9's rc before you look anywhere else (including bash): http://man.9front.org/1/rc

Also, I would advise you to learn about these four tools in depth: sh, sed, awk, and make. Learn when to use each, and don't use one when another would be better.

Re: Become Shell Literate

#14
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…

Yeah, Perl started out a bit like this. I never adopted it for myself or my company, but I did get a chance to have lunch with Larry Wall and talked to him about Perl. This was back when Perl was quite a young and promising language for a certain class of problems.

Perl had very good performance, despite being a "scripting" language, because so many of the tasks that a typical shell script might need to do were supported by built in features in the language (for example handling regular expressions, interacting with command line arguments, exec'ing other programs).

Today, once a shell script requires very much logic, I'm inclined to use Python. I know Python and find programming in it easier than Perl and bash and other shells. Furthermore, other programmers understand Python better than bash.

Re: Become Shell Literate

#15
post #12
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…

It wouldn't be coherently unixy if it was. Small tools that do a limited subset of things, and reliably take/output data from stdin/stdout is the way unix is done. sh is just the glue we use to tack it all together. Bash (and other shells too) is like it is, because it's an accretion of 50 years of history rather than a singular top down design.

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).

Re: Become Shell Literate

#16
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've been trying to build a computer with a single principled HLL included that can also double as a shell. There's also http://www.oilshell.org which _also_ tries to be compatible with existing shell. It also tries to include features from awk and sed: https://www.oilshell.org/blog/2016/11/13.html

If these design points turn out to be over-constrained and have to make major compromises, yes the next thing I would try would be a small separate language for shell.

Re: Become Shell Literate

#17
post #12

Earlier quoted context omitted.

It wouldn't be coherently unixy if it was. Small tools that do a limited subset of things, and reliably take/output data from stdin/stdout is the way unix is done. sh is just the glue we use to tack it all together. Bash (and other shells too) is like it is, because it's an accretion of 50 years of history rather than a singular top down design.

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 programming language can you put spaces in variable names? In the shell, filenames are variable names! It is only natural that a space cannot appear inside a filename (but of course, most other unicode characters can).

Re: Become Shell Literate

#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 called based on who wrote the code for a particular language construction-- that might get across the frustration I feel when using the shell. (Well, honestly I just StackOverflow for the shell incantation I need and that seems to work well enough.)

Re: Become Shell Literate

#19
post #7

TIL "git status -s". So much ad hoc bad parsing no longer necessary!

If you really intend to parse the output of "git status" (or any command, really) you want the --porcelain option which is guaranteed to stay somewhat stable and parsable by scripts.

Many other commands have such an option. As an example, iproute2 has -json.

Re: Become Shell Literate

#20
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 wish that shell would be more sane.

Absolutely agreed, shell is in many respects terrible.

>I don't think that a shell should be a complete programming language.

On the contrary, I think shell should be a more complete programming language! Drop the stringly typing and add actual types (hence eliminating 80% of bothersome awksedgrep magic; yes, no need to tell me it's a real tall order), add proper error handling...

I truly value simplicity where possible, but I think that the primary interface that I use to communicate with my computer should be as powerful as possible. Numerous times I've built up a shell pipeline only to realize near the end that I need to do something that shell is horrible at, and had to redo the whole thing in Python from scratch. I cannot really see a reason to limit it.

>Some of the most commonly used utils like awk '{ print $2}', sed, grep, sort, ... should be included out of the box to improve performance and to provide consistency across distributions.

UNIX "philosophy" got a lot of things wrong, but not this one. These common utilities you mention are good especially when they're separate, because it's not the shell's job to improve performance, provide consistency, etc... of a dozen and a half different utilities, a number sure only to grow in time as people discover what commonly used thing they want in their shell. Though I'll give you that `awk '{ print $2 }'` should definitely be its own utility or a built-in.

Post reply on HN