Suppose that you’re writing Bourne shell code that involves using some commands in a subshell to capture some information into a shell variable, ‘AVAR=$(….)’, but you accidentally write it with a space after the ‘=’. Then you will get something like this:
$ AVAR= $(... | wc -l) sh: 107: command not foundSo, why is this an error at all, and why do we get this weird and obscure error message? In the traditional Unix and Bourne shell way, this arises from a series of decisions that were each sensible in isolation.
I love these kinds of investigations.
Uh, there’s nothing “weird” or “obscure” about this. I wouldn’t even suggest that. In fact, it’s pretty detailed.
This it the tech equivalent of writing 400 words around someone’s tweet, describing the tweet, the person, the situation in so many words, but ending up with nothing you couldn’t have gleaned yourself. Bash is a very simple scripting language, its not trying to do complex parsing kung-fu like Perl or PHP or use a very strict syntax like python or ruby, so it ends up failing with supposedly unintelligible error messages that relates to how bash interprets scripts.
As a software developer, I hate unix shell programming. Shell programming is significantly more difficult, less capable, more difficult to debug, quirkier, less performant than regular programming. I like being able to pipe things around at the command prompt but as a programming language everything feels clumsy and awkward. The biggest “pro” I see is that you don’t need any other language dependencies, which can be a problem with node.js, python, php, etc. But as long as they’re available I’ll take a real language over shell scripting any day!