[lug] BASH Scripting book recommendations?

Steve Sullivan sullivan at mathcom.com
Tue Dec 27 17:21:03 MST 2011


Wow Rob,

So many interesting baits!
I bit my tongue so hard some of it's stuck in my cheek :)

Have a great new year -

Steve


On Tue, Dec 27, 2011 at 04:03:53PM -0700, Rob Nagler wrote:
> 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
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety

-- 

========================================
Steve Sullivan      sullivan at mathcom.com
303-494-7144        http://www.mathcom.com
========================================



More information about the LUG mailing list