[lug] BASH Scripting book recommendations?

[Rob Nagler]

Jeff sez:
> Some problems are better solved in the shell.  "Better" can mean faster to
> code, easier to maintain, or more suited to the language in other ways.
> It's the same answer for "Why bother to write in Perl?  Every system I work
> on has Java."

(Since it's Friday... :-)

I guess the point I'm making is that you are likely to be faster to
code at the language you are most familiar with whatever it is.  If I
program in Perl all day, it's highly likely I'll be able to code
anything in Perl faster than in Java or sh.  While I think Java sucks
for just about anything (read "bait"), if I'm a Java programmer, I've
got tools to get stuff done, and I would have added to that toolkit
over the years to make that toolkit very efficient.  Wait, maybe I
wouldn't, and I'd just use JNEE and copy-and-paste all day.

> (2) Most programming isn't writing code.
>
> Most programming is maintenance -- fixing someone else's code.  (Or your
> own that you wrote so long ago that you don't remember why you wrote it that
> way.)

Is that a soft pitch or what?

So when I "maintain" software it is not "coding" but "programming".
Heavens...

If I don't remember what I did, I look at the test I wrote which
documents the use.  If there's no test, I go look for all the uses.
If I write in Perl, I'm very familiar with the tools to look for uses.
 If it's another language, I'm less familiar, and therefore slower.
And, of course, before I modify the code, I write a test so that I
know my change is going to do what I want it to do.  I'm most familiar
with the testing framework I use every day, written in the language I
use everyday, using the IDE I use every day, etc.

"someone else's code"?  You've got to be kidding.  I spend very little
time fixing other people's code, because my code is so lousy. ;-)
Seriously, if you a job hopper, you are absolutely right.  However, if
you are a job hopper, you get good at programming the same thing over
and over again.  Not my idea of a good time...  And, anyway, if you
are a job hopper, code your toolkits on your own time, make them open
source, and carry them from job to job.

> Sometimes, especially in a Linux world, that code is in shell scripts.

Hmmm.... I program in Linux all the time, and it's 99.9% Perl.  You
make your bed, and you sleep in it.  The only scripts I end up dealing
with are /etc/*.d, and even those, we generate from Perl.

>  Even if your fix is a Perl script, you often have to be able to read, and
> sometimes debug, the original code.

I have often been faced with this question.  Perhaps it comes down to
what you do for a living.  I'm a programmer who has to do sysadmin to
deploy his systems.  I want that FULLY automated, because it is not
something I do every day.  When I upgrade to a new distro, it takes
quite a while, but then I don't touch that code (too much) for another
few years.  Daily Distro changes are busy work, and I'd rather provide
my customers with value than play with the latest and greatest.
(Indeed, the whole concept that distros are stupid egotistical games
that people play....)

So, if you write it in Perl, it survives distros, even something like
/etc/init.d scripts should be written in Perl.  Show me any of these
scripts, and I'll show you ten bugs or more within a few minutes.
It's an abomination, frankly, that /etc/init.d is written on a
scaffolding that's so rickety.  If you write it in Perl, you can write
tests against them and share code more easily.  Indeed, people are
starting to figure this out, and SLOWLY we are getting to real process
management on Linux.   And, the reason Linux init scripts (again just
by way of example) for forty years is that people have the belief that
"code is in shell scripts" means that it has to stay that way...

Have a nice day. :)

Rob