As a go-to idiom for a writability test, it gives me pause. If the file didn't exist, we created a zero-length one. That might be okay if we are going to write to it anyway as the next action.
If we are testing because we intend to overwrite it, why not just "> result.json" (which is by itself an idiom for truncating a file to zero length).
When would we every do this? Maybe before some command which takes the file name as a destination file argument rather than using output redirection, and which performs a lengthy computation before trying to open the file for writing. We can catch the permission error early.
I don't think I've ever coded such a test; normally you just do the operation that writes to the file and let that fail.
In POSIX C, there is a function access() for doing these kinds of tests. But it has a special purpose: it is meant to be used by a setuid root process to perform a permission test as if it were the real user/group (the one which elevated privilege to root). I.e. it's not can we do this operation, but should we do this operation (would we still be allowed, if we dropped privileges back to the original user).
They are NOT superflous, and all you need to prove it is `zsh` (but there are others that follow suit in similar fashions):
zsh% echo "hello world" > data
zsh% < data && echo "READABLE" # <- will print the contents of data
hello world
READABLE
zsh% : < data && echo "READABLE" # <- this will not
READABLE
So, if you want something that "everyone can use" without going into details about the difference between commonly used shells.. you'd use the null-command.
---
and given that we use the null-command, it _WILL_ behave different with or without subshell.. and all you need is `bash --posix` to prove it:
% cat subshell.sh
#!/bin/bash --posix
( : < missing.json ); echo AFTER # <- will echo AFTER
% ./subshell.sh
./subshell.sh: line 2: missing.json: No such file or directory
AFTER
% cat no-subshell.sh
#!/bin/bash --posix
: < missing.json; echo AFTER # <- this will not
% ./no-subshell.sh
./no-subshell.sh: line 2: missing.json: No such file or directory
% : ^- apparently.. there is a difference
The output above is not truncated, `no-subshell.sh` will stop executing due to the broken read.
---
One should never trust things just because they are written, but that also applies to comments on HN. Originally when I read your message I actually thought I made a mistake, I was very close to writing an apology comment and adding a note to the blog post, but not close enough - I had to test it again.
I'm thankful for the watchful eyes and scrutiny when reading things online, that's good - keep it up, but your message is factually wrong - on so many levels.
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.
Try being on linux and using zsh, it constantly fucks up scripts. Having it run commands via SSH into a windows machine is even more a comedy of errors.
I have to put in every claude.md that the shell is zsh. It's reached the point of annoyance I might just go back to bash.
my experience as well. claude produces functional but over-engineered scripts fairly frequently with often very questionably useful safety checks, especially for powershell.
a common tell of ai generated powershell is a script that has dedicated functions to check types, often via several methods, and happily prints the output of the checks to shell. i do not get why it does this but it often adds dozens of lines that really serve no purpose but to make the shell output look fancy
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 have seen them write massively more complex bash scripts than any normal person would ever attempt, but the failure rate is absurdly high compared to when they write sane typed languages.
Bash scripts requires "set -eu" at minimum, when written by LLM or human.
It's the only language terrible enough to make the default behavior ignore undefined variables, commands, and execution errors, and happily continue executing whatever was produced by me smashing my hands on the keyboard, until the end of the file, while returning an exit code of 0, claiming complete success.
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.
"Shortcuts" like :? that tie together two unrelated things (checking a variable for a condition, expanding the value of that variable) drive me up the wall. It makes expressing just one of the two things harder than expressing both, leading to contortions when you want just one, like this use of :.
I really hate bash because of its unreadable syntax, and this does not help it in any way.
We have some large bash scripts in my company, ~10,000 LOC spread across multiple files, all sourcing each other and what not. It is truly hard to read bash, which means it is truly hard to maintain bash, which means that when the one person knowing the bash scripts in your company goes away, you're in for some "fun".
My point is, these quirks are not useful, except for some bash enthusiasts.
I've read through all of the examples in the article & they all seem to serve to sole purpose of turning readable multiple line code into one-liners.
One-liners are a cool little artifact of early shell culture & are sometimes still useful today if they're short to avoid the readability problems of `/` when copy pasting a quick shell command to run, but they have no place in scripts.
None of this seems useful to me.
> if you are like me and prefer less typing (gotta go fast)
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.
> 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
- 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.
This is an excellent article that helps people decide
against writing shell scripts. I abandoned doing so
shortly after I switched to linux. Since then I was
also using ruby. I still do not understand why people
would prefer shell scripts over ruby (or python). On
systems without ruby or python, one may see a benefit
in using shell scripts; other than that I fail to see
why shell scripts are necessary.
Shell scripts simply suck for many reason. They are
ugly, verbose, convoluted, outright stupid too such
as argument passing into functions. Then there is
straight up retarded stuff such as case/esac. Whoever
came up with that was clearly an incompetent language
designer.
> ( : < dataset.json ) && echo YES # is dataset.json readable?
The subshell execution parentheses and the colon are superfluous here, just:
Redirections do not require a colon command to hang off of, and there is no need to fork a subshell to execute such a command.> ( : >> result.json ) && echo YES # is result.json writable?
As a go-to idiom for a writability test, it gives me pause. If the file didn't exist, we created a zero-length one. That might be okay if we are going to write to it anyway as the next action.
If we are testing because we intend to overwrite it, why not just "> result.json" (which is by itself an idiom for truncating a file to zero length).
When would we every do this? Maybe before some command which takes the file name as a destination file argument rather than using output redirection, and which performs a lengthy computation before trying to open the file for writing. We can catch the permission error early.
I don't think I've ever coded such a test; normally you just do the operation that writes to the file and let that fail.
In POSIX C, there is a function access() for doing these kinds of tests. But it has a special purpose: it is meant to be used by a setuid root process to perform a permission test as if it were the real user/group (the one which elevated privilege to root). I.e. it's not can we do this operation, but should we do this operation (would we still be allowed, if we dropped privileges back to the original user).
They are NOT superflous, and all you need to prove it is `zsh` (but there are others that follow suit in similar fashions):
So, if you want something that "everyone can use" without going into details about the difference between commonly used shells.. you'd use the null-command.---
and given that we use the null-command, it _WILL_ behave different with or without subshell.. and all you need is `bash --posix` to prove it:
The output above is not truncated, `no-subshell.sh` will stop executing due to the broken read.---
One should never trust things just because they are written, but that also applies to comments on HN. Originally when I read your message I actually thought I made a mistake, I was very close to writing an apology comment and adding a note to the blog post, but not close enough - I had to test it again.
I'm thankful for the watchful eyes and scrutiny when reading things online, that's good - keep it up, but your message is factually wrong - on so many levels.
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.
Try being on linux and using zsh, it constantly fucks up scripts. Having it run commands via SSH into a windows machine is even more a comedy of errors.
I have to put in every claude.md that the shell is zsh. It's reached the point of annoyance I might just go back to bash.
my experience as well. claude produces functional but over-engineered scripts fairly frequently with often very questionably useful safety checks, especially for powershell.
a common tell of ai generated powershell is a script that has dedicated functions to check types, often via several methods, and happily prints the output of the checks to shell. i do not get why it does this but it often adds dozens of lines that really serve no purpose but to make the shell output look fancy
I think they've learnt from decades of humans using Bash for tasks that clearly need to be implemented in an Actual Language.
The knowledge that Bash is awful and should be avoided as much as possible is surprisingly and disappointingly rare.
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 have seen them write massively more complex bash scripts than any normal person would ever attempt, but the failure rate is absurdly high compared to when they write sane typed languages.
Bash scripts requires "set -eu" at minimum, when written by LLM or human.
It's the only language terrible enough to make the default behavior ignore undefined variables, commands, and execution errors, and happily continue executing whatever was produced by me smashing my hands on the keyboard, until the end of the file, while returning an exit code of 0, claiming complete success.
“Only language” eh? I only have a passing familiarity or very distant memory so could be wrong but I’d say these are the same:
Perl (needs use strict)
Ancient VB/VBA/VB script
Original PHP (no idea about modern)
PowerShell
Old Windows/DOS batch
Javascript
Python startup time is a problem. I don't know about ts but I bet it's worse.
Just use Fish
Or better yet Nushell
I am not a huge fan of most of these, but a few do seem useful.
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.
Yo, author here.
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!
Agreed; author does note
> 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.
"Shortcuts" like :? that tie together two unrelated things (checking a variable for a condition, expanding the value of that variable) drive me up the wall. It makes expressing just one of the two things harder than expressing both, leading to contortions when you want just one, like this use of :.
I really hate bash because of its unreadable syntax, and this does not help it in any way.
We have some large bash scripts in my company, ~10,000 LOC spread across multiple files, all sourcing each other and what not. It is truly hard to read bash, which means it is truly hard to maintain bash, which means that when the one person knowing the bash scripts in your company goes away, you're in for some "fun".
My point is, these quirks are not useful, except for some bash enthusiasts.
I've read through all of the examples in the article & they all seem to serve to sole purpose of turning readable multiple line code into one-liners.
One-liners are a cool little artifact of early shell culture & are sometimes still useful today if they're short to avoid the readability problems of `/` when copy pasting a quick shell command to run, but they have no place in scripts.
None of this seems useful to me.
> if you are like me and prefer less typing (gotta go fast)
Yeah, no.
Good to know, but looks less readable than `if` example.
Maybe it's just the fact that I woke up 10 minutes ago, but the readability of this looks awful. Even more than just usual shell scripts.
Prefer
over Really? Colon is the appendix of the shell.Aside: hacker news doesn't do markdown code blocks, but instead uses 2 spaces before text;
Thanks, fixed
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.
https://www.gavi.org/vaccineswork/what-does-appendix-do-biol...
> 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
the truncation is a poor example.
- 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.
Hey jiveturkey, author here!
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!
This is an excellent article that helps people decide against writing shell scripts. I abandoned doing so shortly after I switched to linux. Since then I was also using ruby. I still do not understand why people would prefer shell scripts over ruby (or python). On systems without ruby or python, one may see a benefit in using shell scripts; other than that I fail to see why shell scripts are necessary.
Shell scripts simply suck for many reason. They are ugly, verbose, convoluted, outright stupid too such as argument passing into functions. Then there is straight up retarded stuff such as case/esac. Whoever came up with that was clearly an incompetent language designer.