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
Thanks for the (indirect) link to the YouTube video, will give that a try.
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.
You can get the video here:
* https://web.archive.org/web/20140207100122/http://confreaks....
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!
https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/sh...
while false do echo 1 done
if false then echo 1 fi
argubaly should just work, the presence of do/then/done/fi keywords makes semicolons quite superfluous yet the correct forms are while false ; do echo 1 ; done
if false ; then echo 1 ; fi
Which is strange, because Algol's grammar actually prohibits ; before ELSE, FI, and OD keywords yet the Bourne shell requires them!I'll stand on the point that if you're gonna forego (ba)sh compatibility, 95/100 times you might as well write Python scripts. Shell syntax generally sucks, and the only reason we still roll with it is legacy code, universal compatibility, and pipes.
Managing concurrent processes is arguably also easier in shell scripts, in that you can just append “&” to run stuff in the background and “wait” to sync.
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.
Much credit to copilot and shellcheck, which have made complex bash ever the more write-only language than it already was.
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.
$ cat l.sh
alias l=ls
l
$ sh l.sh
file1 file2 l.sh
$ bash l.sh
l.sh: line 2: l: command not found
$ bash -i l.sh
file1 file2 l.sh
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
BTW aliases come from csh, and there they support arguments, which makes them similar to functions.
$ alias foo='seq 3 | '
$ foo cat
1
2
3
Functions are functionsCan't do that without eval, which is another can of worms. Aliases are fine
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? :) [ "${BASH:-}" ] && shopt -s expand_aliases
[ "${ZSH_VERSION:-}" ] && setopt SH_WORD_SPLIT
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).
1. Aliases can work with the callee scope.
alias MY_VAR_MODIFIER='local foo=bar'
MY_VAR_MODIFIER () { local foo=bar; }
Calling the alias by the name will set the callee's variable foo, while calling the function does nothing (local foo is local to the function and never leaves scope).It also works similarly for working with the set ($@). You can do `set --` stuff and it works on the scope of the callee.]
Aliases on most shells also don't need to be fully valid _before_ expansion. You can alias a compound command:
alias foreach='for EACH'
foreach in $MYVAR #perfectly valid for most shells.
Only ksh93 will complain about it, it requires aliases to be complete valid shell programs.Finally, alias calls don't appear in xtrace (set -x). Only the final expansion will appear.
TL;DR aliases in scripts work a lot like macros.
Supply check=True and the script will barf on subprocess failure. Another useful upgrade.
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.
I agree that some work is better suited to a real programming language, however the driving force isn't the problems you speak of, which are trivial, it's when the logic/control flow of the overall problem becomes more complex.
It will try to prevent you. It isn't perfect though, and whitespace errors are only the tip of the iceberg.
Shellcheck doesn't tell you to enable pipefail for example, so there's a huge foot-gun.
Pipefail itself is kind of impossible to use correctly anyway.
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.
I think in part it's a skills mismatch - a lot of devops/sysadmin type folks I encounter, while very talented, are not prolific coders. So code-forward solutions like jsonnet, starlark, dhall, nix, etc. are rather unfamiliar familiar.
It doesn't help that all but one of those languages mentioned are odd little functional languages, increasing the familiarity gap even further.
There’s also babashka, which pretty much let’s you write clojure in your shell scripts.
Even the project names: osh, and ysh, and oils, where osh is short for Oil Shell, but so is OilS I think...
It makes it really annoying and difficult to read, IMHO. Maybe it's just me.
Life is too short for videos.
There have been GUI shells that didn't perceptibly suck at all, such as early versions of the Windows 9x shell, classic MacOS, and Acorn RISC OS, but they're all largely dead and gone now.