Hacker News new | ask | show | jobs
by latexr 335 days ago
As someone who has been writing shell scripts for a few decades (though not as long as you), I’d instead recommend “learn what your tools are appropriate for and use them that way”. There are plenty of cases where shell scripts are the right tool for the job.

I can’t even tell how many times I’ve seen multi-line Python scripts which could instead have been a shell one-liner. Shorter and faster.

I have also written shell scripts with hundreds of lines, used by thousands of people, which work just fine and would be more complicated and slower in other languages.

I firmly disagree with the all too pervasive blanket statement of “there are better languages”. It depends. It always does.

2 comments

I'll put a point on the "it depends" bit.

If you have a standard-ish environment, you'll have an array of Unix tools to compose together, which is what a shell is best at. Even a minimal image like busybox will have enough to do serious work. Golfing in shell can be a pipeline of tools: lately "curl | jq | awk" does a lot of lifting for me in a one-liner.

As soon as you say "switch to (favorite decent scripting environment)", you're committing to (a) many megs of its base install, (b) its package management system, (c) whatever domain packages you need for $work, and (d) all the attendant dependency hells that brings along. Golfing in a scripting environment is composing a bunch of builtin operations.

> Golfing in shell can be a pipeline of tools: lately "curl | jq | awk" does a lot of lifting for me in a one-liner.

> As soon as you say "switch to (favorite decent scripting environment)", you're committing to (a) many megs of its base install, (b) its package management system, (c) whatever domain packages you need for $work, and (d) all the attendant dependency hells that brings along.

OK, but isn't jq just an example of a favorite scripting environment with a multi-meg install and a dependency system? What are you doing that's different from what you're advising everyone else not to do?

> Golfing in a scripting environment is composing a bunch of builtin operations.

Neither curl nor jq is a builtin operation.

> OK, but isn't jq just an example of a favorite scripting environment with a multi-meg install and a dependency system?

No? jq is a single binary a little over half a MB with no runtime dependencies. You can simply download it and use it. And you only need that if it’s not already included in whatever system you’re using, which it likely is. It even comes with macOS these days, which is more than what you can say for Python.

https://news.ycombinator.com/item?id=44408432

> Neither curl nor jq is a builtin operation.

Pretty sure they meant it as in builtin with the system, not the language. As per their first paragraph:

> Even a minimal image like busybox will have enough to do serious work.

> No? jq is a single binary a little over half a MB with no runtime dependencies.

I just downloaded it to see what size it was, and it's 2200 KB.

> Pretty sure they meant it as in builtin with the system, not the language. As per their first paragraph:

>> Even a minimal image like busybox will have enough to do serious work.

Busybox doesn't include curl or jq. They aren't builtins by any standard.

This becomes obvious every time you set up a new machine and try to curl something, and then realize you have to install curl.

> I just downloaded it to see what size it was, and it's 2200 KB.

We both saw different versions. You looked at the Linux one, but I looked at the macOS one. The version which ships with macOS is smaller than the one on the website, but even so the website version is under one MB.

I’m intrigued by what causes the large difference.

> Busybox doesn't include curl or jq.

Thank you for the correction. In that case I don’t know what the other user meant. Perhaps they’ll come back and can clarify.

Fair enough point but for many years I wasn't aware of what bash COULD do. I mean one should get to learn more about [[]] and how it does regexps and while read loops:

ls *.txt | { while read FILENAME; do <something> to $FILENAME; done; }

and so on. Once you know, you can get a lot done on e.g. a docker image, without having to install lots of other things first.

When it comes to shell scripting, I personally avoid golf at all costs. I'll take an extra verbose, easy script to parse (for a human) any day of the week when it comes to operations.

Yes it's a tradeoff. Every line of code is a liability. Powershell or python are probably "slower" which in my use case is negligible and almost never relevant. On the other hand, I can't help but view the often esoteric and obscurely clever bash mechanisms as debt.

I’m not talking about code golf. Verbosity and clarity are not directly correlated. The examples I’m talking about are also often easier to read as shell scripts.

For example, let’s take a file as input, filter for every "mypattern" line, then output them sorted.

Python example:

  import sys
  print(*sorted(line for line in open(sys.argv[1]) if 'mypattern' in line), sep='')
Shell example:

  grep 'mypattern' "${1}" | sort
The shell version is shorter, easier to read, easier to understand, easier to search for, and an order of magnitude faster. You can certainly make the Python version more verbose, yet it’ll never reach the same level of clarity and immediacy as the shell version.