[gecko]

The only thing I don't quite grok is that, as the complexity of a given bash script increases, it moves ever-closer to looking exactly like the well-written-by-90s-standards Perl I remember from when I was just learning Unix.

Given that Perl's about as ubiquitous as bash (and arguably more so, since I literally don't know any mainstream *nix that ships without Perl in the core, and I know several that ship without bash), why not just use Perl in the first place? This is exactly what it was designed to do well, back in the beginning.

[Scaevolus]

Learning the different things you can do with bash scripts, especially the string operations, made me a lot faster at doing batch tasks from the command-line.

For longer-term scripts over a few lines, it's easier to use a powerful language you're comfortable with (maybe one of Perl, Python, Ruby) than to waste time (re)learning shell scripting whenever you need to extend the script.

[0xbadcafebee]

Since OP's subject is becoming a better Unix hacker, I recommend staying away from Bash's more advanced (or just useful) features. The more Unix you touch, the more you realize you can't rely on Bash to work how you expect it across all different systems (if they have Bash installed). You will end up relying more on sed, awk, grep and your shell scripting will become more generic - but more portable.

On the other hand, Perl rarely changes. If you find yourself forced into a Perl 4 system you can still use the basics of Perl 5. IMO, if you have a relatively complex job to perform, Perl is going to be more reliable than Bash.

[kwis]

I tend to agree with you. When I write scripts, I target sh, not bash. If it doesn't fit in sh, then I look at a dedicated scripting language (perl/ruby/python) that will almost certainly be a better fit.

[spudlyo]

Most shell scripts are a collection of undeclared external dependencies. You can't really rely on sed, awk, and grep to behave the same way on Linux as they do on Solaris or AIX.

It seems like if you're concerned with portability, you shouldn't be writing a shell script in the first place.

[peterwwillis]

Au contraire, shell script in a (real) POSIX environment is one of the most portable things... It's interpreted and there's always some kind of shell on any Unix system, unlike other interpreted languages. That's why lots of 3rd party vendors use shell scripts to package their setup tools.

Yes the tools behave differently on different systems, but 99.9% of the time there's very basic syntax that is respected across all versions of the tools. Stick to BSD4.4 C Shell syntax (http://docs.freebsd.org/44doc/usd/04.csh/paper.html), don't rely on regular expressions in grep, and stick to the very basics of sed and awk and you can go pretty far in Unix.

Any of the following commands which existed on some archaic version of Unix will still exist and their limited but useful functionality can be extended in lots of ways, and is pretty darn portable. https://secure.wikimedia.org/wikipedia/en/wiki/List_of_Unix_...

[tequilarection]

Except that Perl changes often. There are regular major releases of perl itself, and countless actively maintained modules.

[alexkay]

> since I literally don't know any mainstream -nix that ships without Perl in the core, and I know several that ship without bash

FreeBSD doesn't have Perl in the base system (but of course has it in the ports). Same with Bash though, but the Bourne shell is of course in the base.