[plug] What was that? (firewall breached?)

[Craig Ringer]

> With most shells, you can construct a script that would behave
> in this way:
> 
>  - executes a block of statements which could succeed entirely, or fail
>    part-way through,
>  - handles specific failures, such as return codes or programme output,
>    via specific handlers ("except"-like blocks),
>  - contains a catch-all error handler and/or a "finally"-like block,
>  - allows unhandled errors to fall through to the parent shell,
>  - includes an alarm handler in case one of the statements takes too
>    long.
> 
> Expressions that you would find in such scripts include "set -e",
> "trap" and "$?".

Interesting.... that's something I'll have to look into more. Thanks.

> I suppose something that makes Linux stand out from other operating
> systems is that many tools are written in C or perl and shell scripting
> doesn't play a very visible role, apart from the /etc/init.d scripts,
> perhaps. Some other operating systems (perhaps those that have had some
> BSD heritage?) have a larger proportion of shell scripts, so you would
> commonly see error handling and flow control of this nature. (I don't
> know what SCO is like for you.)

*arrgghhhhh*

It may use a fair bit of shell scripting, but it also uses C utils where 
I /really/ wish it'd use shell scripts (transparency is sometimes 
needed), and as for error checking and handling - what's that?

I'd cite SCO as the "don't" handbook example for UNIX development. I'm 
sure it has some nice features, but OMG....