life is way too short to deal with this nightmare of a language and its 50000 footguns for anything longer than a 2 line script, especially in the age of LLMs. Just write a python/TS/any real language script instead. Bash is great for the command line, it should be limited to use there.
I find LLM's too fall into the trap of writing a bash script for a task that clearly needs to be implemented in an Actual Language with Real Data Structures. For example, ask an LLM to bring up a SQL server with some schema + data preload step, and it will write a profoundly long bash script to do that task, every time.
It turns out that LLMs are really good at writing bash too. even perl! maybe we should rethink some of these lost bits because we no longer need to worry about the arcane parts.
Define "really good?" I don't think I've ever had them produce a script that I didn't need to correct in some way. They can write it, that's true, but we still need to be able to read it.
Fair. I'm comparing it to the output I see generated in more mainstream, day to day, languages. I'm not going to bother to get into an argument on if the frontier models can generate amazing code in general.
What I've found is I can get get the frontier models to generate bash scripts, perl one liners, etc that do exactly what I need at roughly the same quality as any other code it generates.
100% They're super useful and I often use them to generate bash scripts of, but that's exactly how I know how important it is to check their work!
I'm a shell scripter at heart, the arcane stuff has always been a delight for me, so I've driven them to do some pretty complex stuff where previously I would have "copped out" and used python. I'd say the general adage of them being at the level of a very talent junior holds true.
I agree with you, instead of working on creating a bash script if we just sit as a senior developer ,check and correct what is needed is the way forward, it kind a remind me Pair programming when one do the scripting and other corrects it
I am not a huge fan of most of these, but a few do seem useful.
: "${1:?missing argument, aborting!}"
I wouldn't use this because I would want to give $1 a name for the rest of the script, so I would assign. But it can be a nice way to give a clear error for missing required environment variables.
Many of the others (like truncating files) are probably more clearly written with dedicated commands, but may come in useful if you are going to extreme lengths to avoid dependencies outside of the shell.
You are very much correct and I 100% agree with you, I have updated the first example to include a snippet where a proper env-var is used to show of the automatic diagnostic.
> Though.. what if I told you the above four lines could be replaced by just... one?
I'd reject the pull request. Bash is already bad as programming language (the goodness of language for long code is inversely proportional to how nice it is for shell one-liners), this is just turning "bad" into "line noise"
If your bash script takes more than one screen, rewrite it in Python, hell, rewrite it in Perl, even that's better
First of all, I must salute you on the joke; well put haha!
---
It is a (contrived) example of usage where a command is required and `:` can fill in the blanks. There are certainly scenarios where negating an expression becomes harder than doing the "dumb" way, and I for one has written code where `:` can be used as a placeholder meaning "fill this in later" or equivalent.
With that said, 100% agree with you that in actual "production" code - there is always a cleaner way.
- it creates the file if it does not exist, not merely truncate. as a tutorial kind of blog post this incomplete description matters IMO.
- it would work the same without the colon (similar for default variable assignment examples). we generally strive not to have "extra" things, like useless use of cat.
- educationally it's useful to demonstrate that redirection, like parameter expansion, works before the command executes (the null command in this case), but the article doesn't explain that at all!
otherwise i <3 this article. some uses of colon i had never thought of or seen before. like file truncation, not sure i'd use them but it was cool to see them.
What I've found is I can get get the frontier models to generate bash scripts, perl one liners, etc that do exactly what I need at roughly the same quality as any other code it generates.
I'm a shell scripter at heart, the arcane stuff has always been a delight for me, so I've driven them to do some pretty complex stuff where previously I would have "copped out" and used python. I'd say the general adage of them being at the level of a very talent junior holds true.
Many of the others (like truncating files) are probably more clearly written with dedicated commands, but may come in useful if you are going to extreme lengths to avoid dependencies outside of the shell.
> Why use the null-command when I could do VAR=${VAR:-default-value}?
and points out it's one less thing to typo, but that assumes the name is the same; I like e.g.
You are very much correct and I 100% agree with you, I have updated the first example to include a snippet where a proper env-var is used to show of the automatic diagnostic.
Thanks for your feedback, much much appreciated!
I'd reject the pull request. Bash is already bad as programming language (the goodness of language for long code is inversely proportional to how nice it is for shell one-liners), this is just turning "bad" into "line noise"
If your bash script takes more than one screen, rewrite it in Python, hell, rewrite it in Perl, even that's better
---
It is a (contrived) example of usage where a command is required and `:` can fill in the blanks. There are certainly scenarios where negating an expression becomes harder than doing the "dumb" way, and I for one has written code where `:` can be used as a placeholder meaning "fill this in later" or equivalent.
With that said, 100% agree with you that in actual "production" code - there is always a cleaner way.
- it creates the file if it does not exist, not merely truncate. as a tutorial kind of blog post this incomplete description matters IMO.
- it would work the same without the colon (similar for default variable assignment examples). we generally strive not to have "extra" things, like useless use of cat.
- educationally it's useful to demonstrate that redirection, like parameter expansion, works before the command executes (the null command in this case), but the article doesn't explain that at all!
otherwise i <3 this article. some uses of colon i had never thought of or seen before. like file truncation, not sure i'd use them but it was cool to see them.
I agree with you, and for what it's worth the truncation snippet is very much tongue-in-cheek much like `( : >> output ) && echo "is writable"`.
I wasn't expecting anyone to actually use these in Prod, rather I aimed to show what can be done with a command designed to.. do nothing (crazy).
Happy you enjoyed the article, and thank you!