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.
When I was finishing of my degree at Uni I actually spent a couple of months as an auxiliary teacher giving professional training in Unix, which included teaching people shell script.
Nowadays (granted, almost 3 decades later), I remember almost nothing of shell scripting, even though I've stayed on the Technical Career Track doing mostly Programming since.
So that joke is very much me irl.
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…
AI does decently enough on scripting languages if you spell it out enough for it lol, but IMO it tends to not do so well when it comes to compiled languages
I've tried Python with VScode Copilot (Claude) and it did pretty good
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.
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.
There's always the old piece of wisdom from the Unix jungle: "If you write a complex shellscript, sooner or later you'll wish you wrote it in a real programming language."
I wrote a huge PowerShell script over the past few years. I was like "Ooh, guess this is a resume item if anyone asks me if I know PowerShell." ...around the beginning of the year I rewrote the bloody thing in Python and I have zero regrets. It's no longer a Big Mush of Stuff That Does a Thing. It's got object orientation now. Design patterns. Things in independent units. Shit like that.
Je comprend tellement! Je répond en français pour ma première réponse sur Lemmy juste pour voir comment ça va être géré!
Si yo también comprendo, qué necesidad de comentar todo el tiempo en anglais?
Wait im not the only one? I think i relearned bash more times than i can remember.
I don't normally say this, but the AI tools I've used to help me write bash were pretty much spot on.
Yes, with respect to the grey bearded uncles and aunties; as someone who never "learned" bash, in 2025 I'm letting a LLM do the bashing for me.
Until the magic incantations you don't bother to understand don't actually do what you think they're doing.
I wonder if there's a chance of getting rm -rf /* or zip bombs. Those are definitely in the training data at least.
The classic rm -rf $ENV/home where $ENV can be empty or contain spaces is definitely going to hit someone one day
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
It seems like it does stuff differently for the sake of it being different.
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.
Today I tried to write bash (I think)
I grabbed a bunch of commands, slapped a bunch of "&&" to string them together and saved them to a .sh file.
It didn't work as expected and I did not, at all, look at any documentation during the process. (This is obviously on me, I'll try harder next time)