Hacker News Reader

Comment by woodruffw | Hacker News Reader

For people who think that they're the intended audience of these kinds of guides: do you find them effective?

I learned how to use a POSIX shell years before I learned how to program (outside of a shell, that is), and I've often wondered how to help people (particularly younger colleagues) who learned things the other way around.

My experience so far is that a lot of people get stuck in an "experience trough," for lack of a better phrase: they're comfortable navigating around the filesystem and running basic commands, but struggle with some of the more powerful building blocks that can make someone a real shell power user (`xargs`, nontrivial uses of `find`, here-strings, subshells and blocks, process substitution, etc.).

View on HN

The single biggest stumbling block I've seen in my co-workers is quotes. Most of them think in terms of python/javascript/etc where quotes mean string type, and have no concept of how args and splitting on spaces works, or how it's all stringly-typed.

That "experience trough" you describe I think exists because they don't actually understand the fundamentals, so any time they've attempted something new it's based on assumptions from a totally different paradigm, does something strange and unexpected, and reinforces sticking to the same safe and simple commands.

Yup. I came the same path as you, and realized about the same.

It's just a different mindset. Instead of a std library you have tons of prebuilt binaries ready to perform actions and talk to one another. And that is really, really, powerful once you learn what's all available and how to use/abuse it.

Software engineering in general is so different. Tons of mantras to follow, TDD, OOP, etc.

Each has its place, but generally if I can do it in a few lines of shell, why spend 20 minutes writing a hundred lines of something more pure? On the other hand, shells do not seem well suited for anything large and complex, admittedly. So watching people waste an hour writing something that could be a Bash one liner is about as painful as watching someone try to debug a 500 line bash script.

The better phrase might be the "tar pit of immediacy", from the Unix chainsaw talk by Gary Bernhardt. Highly recommend: https://www.youtube.com/watch?v=ZQnyApKysg4

I did “enough shell to be dangerous” which I guess counts as “these kinds of guides” and it opened the door for using the shell for me.

I’m not really sure it’s fair to assume that you can use advanced topics after reading any book aimed at beginners.

Also, no one is going to learn how to use any of your advanced topics unless they have a need. And people rarely have a need for those things.

Do you mind elaborating? What do you recommend for progressing out of that? I'm pushing for Red Hat learning from my employer. Any favorite learning resources?

This is the problem: I don't really know. It doesn't help that POSIX sh (and GNU Bash) are objectively terrible programming languages, and that it takes a decent amount of masochism to "enjoy" them in the way that (I think) engenders competence.

For me, it was a lot of scripting and then iterating on those scripts when I realized that they conceptually broke down in places (even if they never broke in practice). Things like spaces where you don't want them, needing to pass around data that might be too large for `argv` (because of stack limits), etc.

One needs to sit down and read through in-depth documentation or a book like this one. Many people don’t seem to have the patience or interest to do so.

have you found any ways to get past that experience trough? I definitely feel like i’m there now

The author of the musl C library has a very poor opinion of the POSIX shell, and has published his "tricks" to force expected behavior.

This is very useful for those who are stumped by a failing script.

"I am a strong believer that Bourne-derived languages are extremely bad, on the same order of badness as Perl, for programming, and consider programming sh for any purpose other than as a super-portable, lowest-common-denominator platform for build or bootstrap scripts and the like, as an extremely misguided endeavor. As such you won’t see me spending many words on extensions particular to ksh, Bash, or whatever other shells may be popular."

https://www.etalabs.net/sh_tricks.html

For me, it helped to stop thinking of the shell as an efficient way to accomplish a task (it certainly is), but as a way to express my intent (the way I would in a normal programming language). That, combined with some automated tooling (shellcheck) and a handful of best practices (arrays over strings, avoiding the "cat pipe" pattern[1], etc.) has worked well for me. But I don't know how well that generalizes!

[1]: https://www.linuxjournal.com/content/put-down-pipe

> avoiding the "cat pipe" pattern

For me, `cat | grep/sort` is easier to remember as it follows some unixy philosophy on how to do things.

I wonder why that article author is so obsessed with putting down cat/pipe. Maybe in scripts where you process large files and sort/grep it is less ineffective. But when writing shell commands, I see this as an empty argument to retrain my "muscle memory" and learn "different syntax".

In fact, when writing powershell I do the same: `gc something | sls something`. But I know it is less effective, but I'm lazy to look up proper syntax: `sls ?? something` - But if I ever will need that in a script to process non trivial amount of files-lines - I'll look it up.

Along those lines it's interchangeable with other sources like nc or ssh or whatever, with no changes to sort/grep.

I did it by blocking out time to read the manual pages. Yes, it is slow and tedious. But the manuals make a lot more sense once you already know how the tools work at a basic level.

> but struggle with some of the more powerful building blocks that can make someone a real shell power user (`xargs`, nontrivial uses of `find`, here-strings, subshells and blocks, process substitution, etc.).

I am one of those... as soon as I don't know how to do something in the shell, though, I just fire up a REPL or a "scratch" in the IDE and write what I want in a "proper" language. Sorry, but shel scripting is not always the best way to go. I eventually did learn me some AWK and that was useful, but most of the time I don't use even that, it's just so much easier for a programmer to use a programming language to do stuff.

Which repl do you use to replace xargs?

Conceptually, xargs applies some logic to each item in a list. Many programming language support this, e.g. Python:

    for item in some_list:
        foo(item)

Of course, the above is a replacement for "xargs -n 1" only; but I argue that the batching functionality of xargs isn't really needed in programming languages.

Not GP, but I use perl, which I suppose isn't much better from the perspective of something that's easy to learn :/

You don't need xargs when you're using a programming language.

Reply on news.ycombinator.com