3 ms·

Bash is kinda like the last remnants of Perl. I know it's not perl, but it's similar. And it has similar conventions. And like Perl, it gets shit done pretty co

Bash is kinda like the last remnants of Perl. I know it's not perl, but it's similar. And it has similar conventions. And like Perl, it gets shit done pretty concisely. It's also a write-only language (easy to write / hard to read). I do find it interesting that bash has kinda become the DevOps root tool. I don't think DevOps would have had it's moment without Bash or if bash was similar to DOS Batch files instead, for example.

mhd 6y ago
I agree with the DevOps theory, but precisely for the opposite reason. People wrote all kinds of automated tools etc. to replace weird BOFH shell scripts. Almost no syntactical improvements upon Bourne sh (which was a weird Algol-like in C-land), but introducing plenty of incompatibilities because other systems might have just regular sh or an older version of bash. Compared to Korn Shell or yes, Perl, it's a major step back. (I'd also say it's a lot harder to write than read, given that once you're reading a working script, you've already got most of the whitespace issues and badly formed command argument worked out). The Unix commandline as a way to pipe together commands was a pretty great idea. But every inch you step away from that abstract ideal is just mired in a geological accumulation of oddities and bad design (Plan 9 probably being the closest ever attempt of making that work less painfully)
qiqitori 6y ago
TBH, calling Bash 'write-only' makes me a bit sad. Bash should be very easy to read for people familiar with the command line. Except for boilerplate (e.g. set switches, documented in 'help set', but just ignore them if you're just reading) or if switches (documented in 'man test', but you really just need to memorize three or so) and a handful of commands that don't tend to be used outside of scripts -- all have a help or man page. You could argue that DOS batch files are hard to read too. Of course, bash's tacked on features -- regex, array/hash syntax, etc. can get a bit hairy, but it's all highly documented. To me, bash is more the polar opposite: hard* to write, easy to read. * not that hard

mhd 6y ago

I agree with the DevOps theory, but precisely for the opposite reason. People wrote all kinds of automated tools etc. to replace weird BOFH shell scripts. Almost no syntactical improvements upon Bourne sh (which was a weird Algol-like in C-land), but introducing plenty of incompatibilities because other systems might have just regular sh or an older version of bash. Compared to Korn Shell or yes, Perl, it's a major step back. (I'd also say it's a lot harder to write than read, given that once you're reading a working script, you've already got most of the whitespace issues and badly formed command argument worked out). The Unix commandline as a way to pipe together commands was a pretty great idea. But every inch you step away from that abstract ideal is just mired in a geological accumulation of oddities and bad design (Plan 9 probably being the closest ever attempt of making that work less painfully)

qiqitori 6y ago

TBH, calling Bash 'write-only' makes me a bit sad. Bash should be very easy to read for people familiar with the command line. Except for boilerplate (e.g. set switches, documented in 'help set', but just ignore them if you're just reading) or if switches (documented in 'man test', but you really just need to memorize three or so) and a handful of commands that don't tend to be used outside of scripts -- all have a help or man page. You could argue that DOS batch files are hard to read too. Of course, bash's tacked on features -- regex, array/hash syntax, etc. can get a bit hairy, but it's all highly documented. To me, bash is more the polar opposite: hard* to write, easy to read. * not that hard