It seems like it does stuff differently for the sake of it being different.
Programmer Humor
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
And I thought I was the only one… for smaller bash scripts chatGPT/Deepseek does a good enough job at it. Though I still haven’t tried VScode’s copilot on bash scripts. I have only tried it wirh C code and it kiiiinda did an ass job at helping…
PSA: Run ShellCheck on your shell scripts. It turns up a shocking number of programming errors. https://www.shellcheck.net/
I wish it had a more comprehensive auto correct feature. I maintain a huge bash repository and have tried to use it, and it common makes mistakes. None of us maintainers have time to rewrite the scripts to match standards.
I don’t write very small shell scripts because I am not a job destroyer.
every control structure should end in the backwards spelling of how they started
Once you get used to it it is kind of fun.
Shame about do
though.
it could have been not
since there's no try
.
That's why I use nushell. Very convenient for writing scripts that you can understand. Obviously, it cannot beat Python in terms of prototyping, but at least I don't have to relearn it everytime.
We have someone at work who uses it and he's constantly having tooling issues due to compatibility problems, so.. yeah.
I'm sure it's fine for sticking in the shebang and writing your own one-off personal scripts, but I would never actually main it. Too much ecosystem relies on bash/posix stuff.
So the alternative is:
- either an obtuse script that works everywhere, or
- a legible script that only works on your machine…
Ruby and calling bash like this
`cat a.txt`
Nu is great. Using it since many years. Clearly superior shell. Only problem is, that it constantly faces breaking changes and you therefore need to frequently update your modules.
They’ve slowed down with those a bit recently, haven’t they?
Not really. They've been on the stabilising path for about two years now, removing stuff like dataframes from the default feature set to be able to focus on stabilising the whole core language, but 1.0 isn't out yet and the minor version just went three digits.
And it's good that way. The POSIX CLI is a clusterfuck because it got standardised before it got stabilised. dd
's syntax is just the peak of the iceberg, there, you gotta take out the nail scissors and manicure the whole lawn before promising that things won't change.
Even in its current state it's probably less work for many scripts, though. That is, updating things, especially if you version-lock (hello, nixos) will be less of a headache than writing sh
could ever be. nushell is a really nice language, occasionally a bit verbose but never in the boilerplate for boilerplate's sake way, but in the "In two weeks I'll be glad it's not perl" way. Things like command line parsing are ludicrously convenient (though please nushell people land collecting repeated arguments into lists).
Not a problem for me in Nix, seems like a skill issue ~/j~
So true. Every time I have to look up how to write a bash for loop. Where does the semicolon go? Where is the newline? Is it terminated with done
? Or with end
? The worst part with bash is that when you do it wrong, most of the time there is no error but something completely wrong happens.
It all makes sense when you think about the way it will be parsed. I prefer to use newlines instead of semicolons to show the blocks more clearly.
for file in *.txt
do
cat "$file"
done
The do
and done
serve as the loop block delimiters. Such as {
and }
in many other languages. The shell parser couldn't know where stuff starts/ends.
Edit:
I agree that the then
/fi
, do
/done
case
/esac
are very inconsistent.
Also to fail early and raise errors on uninitialized variables, I recommend to add this to the beginning of your bash scripts:
set -euo pipefail
Or only this for regular sh scripts:
set -eu
-e
: Exit on error
-u
: Error on access to undefined variable
-o pipefail
: Abort pipeline early if any part of it fails.
There is also -x
that can be very useful for debugging as it shows a trace of every command and result as it is executed.
Maybe applies more to regex, the write only language.
Back when I did a lot of Perl, those were okay-ish to parse. Nowadays, not so much. I guess it's like Bash. If you write a lot of it (maybe some people do), it's probably simple. If it's only once every six months or less, eeehhh...
It all boils down to familiarity, which comes from repetitiveness.
The copy paste language. AI writes better regex than I do
and you won't get better if you use ai for it
Meh I rarely use it. Even if I don’t use AI I wouldn’t get better at it, since I will forget everything the next time I will use it.
Wait im not the only one? I think i relearned bash more times than i can remember.
Knowing that there is still a bash script i wrote around 5 years ago still running the entirety of my high scool lab makes me sorry for the poor bastard that will need to fix those hieroglyphs as soon as some package breaks the script. I hate that i used bash, but it was the easiest option at the time on that desolate server.
Bash scripts survive because often times they are the easiest option on an abandoned server
Or it’s because other people are assholes. And write shit garbage. And then you go to fix a bug or add an enhancement. And then you are stuck.
Very true. Been programming/scripting in Bash since many many years, I could almost consider myself an "expert", however I still need to look up the same crap over and over again, since remembering weird symbol constellations is the last thing you should do, when you actually just wanna achieve a goal with the script and not learn how to summon the spirit of some C-related language creator.