Something I learned recently is that the Bourne shell (and by extension, bash and POSIX's sh) have syntax inspired by Algol 68 (source [0]), which explains some of the funkyness. One thing I've been doing recently is writing scripts in rc, the default shell for plan9. It's a bit saner syntax-wise IMO. Versions linked against readline have file-based completion, but it's otherwise not quite robust enough for me to switch away from fish as my default, but it has some things I prefer over both bash and fish.
I encourage people to give rc and awk a shot, they're both small and learnable in an afternoon!
I've grown rather fond of bash in my current role. I work mainly on developer tools and CI pipelines, both of which mean gluing together lots of different CLI tools. When it comes to this kind of work I think it is quite hard to beat the expressiveness of shell scripting. I say this as a former hater of bash and its syntax.
Much credit to copilot and shellcheck, which have made complex bash ever the more write-only language than it already was.
> I've grown rather fond of bash in my current role. I work mainly on developer tools and CI pipelines, both of which mean gluing together lots of different CLI tools. When it comes to this kind of work I think it is quite hard to beat the expressiveness of shell scripting.
Every time I have to express logic in YAML, I miss shell. Shell’s really not great, and it could be improved upon (my vote? Tcl), but it’s so much better than where the industry is these days.
Bash actually has more warts than competing shells because of its historic stance.
My bugbear is that "alias p=printf" works well in any POSIX shell script, including bash when it is invoked as #!/bin/sh - but when called as #!/bin/bash, the alias (used in a script) fails with an error.
While the Korn shell managed to evolve and comply with the POSIX standard, bash decided to split the personality, so one solution to the above alias failure is to toggle POSIX mode.
Bash was forced to do this, to keep a decade of shell scrips that were written for it working. Pity.
The standard for the POSIX shell looked very hard at Korn, and credits it. Bash is not mentioned.
Thanks, I had no idea. I guess I've never used aliases in scripts, but I would've assumed that they'd just work the same as in interactive mode. Good to know.
Functions don't work everywhere. Bash functions only work in the current shell context unless exported via an `export -f myfun' statement in between the function declaration and downstream sub-shell usage.
Working example:
pzoppin() {
printf 'echo is for torrent scene n00bs from %s\n' "$*"
trap "printf '%s\n' <<< \"$*\"" RETURN EXIT SIGINT SIGTERM
}
export -f pzoppin
echo -e 'irc\0mamas donuts\0starseeds' \
| xargs -0 -n 1 -I {} /usr/bin/env bash -c '
echo hi
pzoppin "$*"
echo byee
' _ {}
The above will fail miserably without the magic incantation:
`export -f pzoppin'
Why'd they design an otherwise perfectly usable, mapless language without default c-style global functions? :)
I typically just give up on weird corners of shell when I find an working version of the same.
For instance -- why would you use "alias" when you can make a function? The syntax is a little weird with functions, but it's a lot more clear what's going on.
The same goes for "test" vs the seeming magic of [ where it seems like [ is language syntax (it's a single character!) when in fact ... it's just another executable that communicates with logic evaluation like anything else (like grep or false).
Gluing together tools with shell scripts is a significant cause of CI failures in my experience. There's no reason to do it. Use a real language - at least Python, but my preference is Deno because it's not dog slow and you don't have to deal with venv.
The subprocess.run args argument is a list of strings, not a single string with whitespace-delimited parts, so you're all good quotingwise. This is now effortlessly a lot better than what you get with bash in terms of how brittle things are!
Supply check=True and the script will barf on subprocess failure. Another useful upgrade.
Take a look at https://sh.readthedocs.io/en/latest/ for a very usable solution to easily run other processes in Python. It has made my life a lot easier whenever I've had to migrate a shell script to Python.
> Maybe it makes more sense to post the link to YT, as you did in 2022
Based on the comments there, it seems like OP posted this current (shellhaters.org) link then too, and it's the mods that replaced it to point to the YouTube video. Hopefully the same will happen this time around as well.
I tried following the slide deck (to get an idea of the content), but that's pretty rough too. The page reloads itself constantly and is very inconsistent with responding to input keys, it's not a pleasant experience.
Thanks for the (indirect) link to the YouTube video, will give that a try.
A brilliant historical artifact, and the irony that macOS has been Unix for most of the Mac's existence, and that Windows has included POSIX and/or Linux for most of its existence, is not lost on me.
The Dennis Ritchie anti-forward makes it even better:
> The rational prisoner exploits the weak places, creates order from chaos: instead, collectives like the FSF vindicate their jailers by building cells almost compatible with the existing ones, albeit with more features. The journalist with three undergraduate degrees from MIT, the researcher at Microsoft, and the senior scientist at Apple might volunteer a few words about the regulations of the prisons to which they have been transferred.
I'm not familiar with the landscape - is there a "compiles to reasonably-readable [ba]sh" language that's gotten any traction anywhere? That seems like at least an interesting possible solution.
YouTube link for video if it's broken for others and not just me:
https://www.youtube.com/watch?v=olH-9b3VJfs
Something I learned recently is that the Bourne shell (and by extension, bash and POSIX's sh) have syntax inspired by Algol 68 (source [0]), which explains some of the funkyness. One thing I've been doing recently is writing scripts in rc, the default shell for plan9. It's a bit saner syntax-wise IMO. Versions linked against readline have file-based completion, but it's otherwise not quite robust enough for me to switch away from fish as my default, but it has some things I prefer over both bash and fish.
I encourage people to give rc and awk a shot, they're both small and learnable in an afternoon!
[0]: https://doc.cat-v.org/plan_9/4th_edition/papers/rc
Influence of Algol 68 doesn't even really explains requirement of semicolons (or equivalently, new lines) in weird places.
argubaly should just work, the presence of do/then/done/fi keywords makes semicolons quite superfluous yet the correct forms are Which is strange, because Algol's grammar actually prohibits ; before ELSE, FI, and OD keywords yet the Bourne shell requires them!The Bourne shell was hilariously written in horribly deformed C resembling ALGOL by way of macros:
https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/sh...
https://news.ycombinator.com/item?id=22191790
That's amazing
I've grown rather fond of bash in my current role. I work mainly on developer tools and CI pipelines, both of which mean gluing together lots of different CLI tools. When it comes to this kind of work I think it is quite hard to beat the expressiveness of shell scripting. I say this as a former hater of bash and its syntax.
Much credit to copilot and shellcheck, which have made complex bash ever the more write-only language than it already was.
> I've grown rather fond of bash in my current role. I work mainly on developer tools and CI pipelines, both of which mean gluing together lots of different CLI tools. When it comes to this kind of work I think it is quite hard to beat the expressiveness of shell scripting.
Every time I have to express logic in YAML, I miss shell. Shell’s really not great, and it could be improved upon (my vote? Tcl), but it’s so much better than where the industry is these days.
You can't use a shell script or a TCL script to generate the YAML file?
Bash actually has more warts than competing shells because of its historic stance.
My bugbear is that "alias p=printf" works well in any POSIX shell script, including bash when it is invoked as #!/bin/sh - but when called as #!/bin/bash, the alias (used in a script) fails with an error.
While the Korn shell managed to evolve and comply with the POSIX standard, bash decided to split the personality, so one solution to the above alias failure is to toggle POSIX mode.
Bash was forced to do this, to keep a decade of shell scrips that were written for it working. Pity.
The standard for the POSIX shell looked very hard at Korn, and credits it. Bash is not mentioned.
Huh, why wouldn't that alias work?
Good question. Something to do with interactive mode?
Edit: Ah yes, the man page says so.> Aliases are not expanded when the shell is not interactive, unless the expand_aliases shell option is set using shopt
Thanks, I had no idea. I guess I've never used aliases in scripts, but I would've assumed that they'd just work the same as in interactive mode. Good to know.
Why use an alias in a script? Or in general? Functions work everywhere.
Functions don't work everywhere. Bash functions only work in the current shell context unless exported via an `export -f myfun' statement in between the function declaration and downstream sub-shell usage.
Working example:
The above will fail miserably without the magic incantation: Why'd they design an otherwise perfectly usable, mapless language without default c-style global functions? :)Aliases are like C macros
Functions are functionsSo then use $variables for evil syntactic tricks? That works everywhere. Functions where hygiene counts? Aliases never?
>use $variables for evil syntactic tricks
Can't do that without eval, which is another can of worms. Aliases are fine
I suppose aliases predated functions. Can't find a reference to support that, though. Just a possible reason.
BTW aliases come from csh, and there they support arguments, which makes them similar to functions.
I typically just give up on weird corners of shell when I find an working version of the same.
For instance -- why would you use "alias" when you can make a function? The syntax is a little weird with functions, but it's a lot more clear what's going on.
The same goes for "test" vs the seeming magic of [ where it seems like [ is language syntax (it's a single character!) when in fact ... it's just another executable that communicates with logic evaluation like anything else (like grep or false).
Gluing together tools with shell scripts is a significant cause of CI failures in my experience. There's no reason to do it. Use a real language - at least Python, but my preference is Deno because it's not dog slow and you don't have to deal with venv.
I mean I guess but what's your plan when your script is just a bunch of subprocess.run calls? I promise you it won't be any less brittle.
The subprocess.run args argument is a list of strings, not a single string with whitespace-delimited parts, so you're all good quotingwise. This is now effortlessly a lot better than what you get with bash in terms of how brittle things are!
Supply check=True and the script will barf on subprocess failure. Another useful upgrade.
Take a look at https://sh.readthedocs.io/en/latest/ for a very usable solution to easily run other processes in Python. It has made my life a lot easier whenever I've had to migrate a shell script to Python.
I promise it will! It will handle weird filenames properly for example.
But realistically it's rarely that simple and even when it starts that simple it will grow to not be.
The downvotes are a very disappointing attitude.
(2010)
Sadly the video seems to be missing; the whole GoGaRuCo conference site is gone, actually.
Maybe it makes more sense to post the link to YT, as you did in 2022 https://news.ycombinator.com/item?id=32521080
> Maybe it makes more sense to post the link to YT, as you did in 2022
Based on the comments there, it seems like OP posted this current (shellhaters.org) link then too, and it's the mods that replaced it to point to the YouTube video. Hopefully the same will happen this time around as well.
I tried following the slide deck (to get an idea of the content), but that's pretty rough too. The page reloads itself constantly and is very inconsistent with responding to input keys, it's not a pleasant experience.
Thanks for the (indirect) link to the YouTube video, will give that a try.
And its inspiration is still great but could use a refresh: https://web.mit.edu/~simsong/www/ugh.pdf
A brilliant historical artifact, and the irony that macOS has been Unix for most of the Mac's existence, and that Windows has included POSIX and/or Linux for most of its existence, is not lost on me.
The Dennis Ritchie anti-forward makes it even better:
> The rational prisoner exploits the weak places, creates order from chaos: instead, collectives like the FSF vindicate their jailers by building cells almost compatible with the existing ones, albeit with more features. The journalist with three undergraduate degrees from MIT, the researcher at Microsoft, and the senior scientist at Apple might volunteer a few words about the regulations of the prisons to which they have been transferred.
Thanks for reminding me about this gem! :)
I'm not familiar with the landscape - is there a "compiles to reasonably-readable [ba]sh" language that's gotten any traction anywhere? That seems like at least an interesting possible solution.
There was a pretty great-looking one that I saw on HN in the last few months. I didn’t end up trying it, and I don’t remember what it was called.
There’s also babashka, which pretty much let’s you write clojure in your shell scripts.
Might have been Oil shell, which is worth looking at: https://www.oilshell.org/
Oil shell is the way forward for shell.
Was it https://amber-lang.com?
Getting a DNS error from confreaks.
You can get the video here:
* https://web.archive.org/web/20140207100122/http://confreaks....
Sorry, really don't have time to sit on my arse and watch a video