Re: bash vs. python scripts - which one is better?

[Steve Lamb <grey@dmiyu.org>]

Jeff D wrote:
> It has nothing to do with shell, python, perl or what ever.  You would
> still have rename the file extention:

    Yes, you would.  And therein lies the point.  One liners often aren't.
Quite often something comes up and "whoops, need to do this" and then "d'oh,
need to do that" and pretty soon that one liner is taking up 3 lines on the
screen and would be far easier to read if it were written in a text file.

    I prefer to just skip the "whoops, need to add this step" prior to getting
to the text file and just write in a language that is far better suited to the
task.  For extremely small operations I lose a small amount of time.  For
anything barely above the most basic complexity I gain time.  Not only that
but I gain a metric buttload of functionality for a minimum of trouble.

    Quick, take your one liner, have it traverse an entire directory tree
converting all the wavs (regardless of capitalization) to mp3s, oggs and flac,
sorting all 4 into their own directory trees.

    For me I just need to change my small script into a function, wrap it
inside os.walk() and have calls to os.makedirs() and shutil.copy() to do all
the work.  Several more minutes of work and I can add in checks for the same
files with different names, prompt the user to pick a name to use, convert
that one and delete the rest.  Then for my final trick I can wrap it all up as
a library, still retaining its ability to run as a stand alone script, and
import it into other Python scripts.

    That is where shell falls down.  A decent tinkerer starts with a "this'd
be neat" few lines of code and expands it to a dozen, several dozen, hundreds
of lines of code.  I have not found a person who would argue that shell is
viable outside a dozen or so lines of code; at least not when there are
alternatives like Python, Perl or Ruby laying around to be used.  It is that
capacity to keep adding, and adding, and adding, growing it larger, splitting
it into parts, reusing all those parts that shell simply cannot do as
effectively as languages designed to do that from the get go.

    Real world example.  At work there was a daily reports process that I
wanted to automate.  Since we're working on Windows conventional shell was
right out.  So I convinced them to install Python on that machine.  In the 10
months since that time the original report-filing script has exploded into 3
discrete libraries, 3 main scripts which call approximately 8 other scripts
(which are usable stand alone).  It does everything from report-filing to
account verification and a baby-DB query.  It all grew from a simple 2kb
script which was replacing a badly broken batch file to the current size in
excess of 40kb of Python code.  Note that none of the functionality in it
today was planned from the first day.  I would have tore my hair out doing the
simplest things in shell much less when the time came to rewrite all of that
from shell to Python.  Better that I started in Python and grew from there.