Regex
Edit: to everyone who responded, I use regex infrequently enough that the knowledge never really crystalizes. By the time I need it for this one thing again, I haven't touched it in like a year.
this post was submitted on 05 Mar 2025
1064 points (99.0% liked)
Programmer Humor
30162 readers
807 users here now
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
founded 2 years ago
MODERATORS
You get used to it, I don't even see the code—I just see: group... pattern... read-ahead...
Most of regex is pretty basic and easy to learn, it's the look ahead and look behind that are the killers imo
(?=) for positive lookahead and (?!) for negative lookahead. Stick a < in the middle for lookbehind.
twitch
You always forget regex syntax?
I've always found it simple to understand and remember. Even over many years and decades, I've never had issues reading or writing simple regex syntax (excluding the flags and shorthands) even after long regex breaks.
It's not about the syntax itself, it's about which syntax to use. There are different ones and remembering which one is for which language is tough.
load more comments
(1 replies)
load more comments
(5 replies)
Clearly you don't write enough bash scripts.
Or scripts for basically any other variant of the Bourne shell. They are, for the most part, very cross compatible.
That's the only reason I've ever done much of anything in shell script. As a network administrator I've worked many network appliances running on some flavor of Unix and the one language I can count on to be always available is bash. It has been well worth knowing for just that reason.
load more comments
(3 replies)
load more comments
(1 replies)
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.
load more comments
(1 replies)
In fairness, this also happens to me when I write the bash script myself 😂
load more comments
(1 replies)
Yeah, an LLM can quickly parrot some basic boilerplate that's showed up in its training data a hundred times.
For building a quick template that I can tweak to my needs, it works really well. I just don’t find it to be an intuitive scripting language.
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)
I try to remember to use man when learning a new command/program. And I almost always half-ass it and press the search button immediately to find whatever flag i need.
load more comments
(1 replies)
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.
I consider python a scripting language too.
load more comments
(2 replies)
PSA: Run ShellCheck on your shell scripts. It turns up a shocking number of programming errors. https://www.shellcheck.net/
load more comments
(2 replies)
Wait im not the only one? I think i relearned bash more times than i can remember.
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.
So the alternative is:
- either an obtuse script that works everywhere, or
- a legible script that only works on your machine…
load more comments
(1 replies)
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.
load more comments
(4 replies)
load more comments
(1 replies)
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
Any no-SQL syntax for interacting with databases.
Me with powershell. I'll write a pretty complex script, not write powershell for 3 months, come back and have to completely relearn it.
This. But Pandas and Numpy.
Pandas and Numpy and Bash.
.loc and .iloc queries are a fun syntax adventure every time
load more comments
(1 replies)
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.
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.
Bash substitution is regex-level wizardry.
Slapping a $ before an environment variable name is "wizardry?"
Nope, the whole ${variable/regex/replacement} syntax
All the string manipulation functions are easy: https://tldp.org/LDP/abs/html/string-manipulation.html
load more comments
(4 replies)
Incredibly true for me these days. But don't fret, shellcheck and tldp.org is all you need. And maybe that one stackoverflow answer about how to get the running script's directory
view more: next ›