Opinion on best practice...

Chris Angelico rosuav at gmail.com
Wed Feb 6 07:16:04 CET 2013


On Wed, Feb 6, 2013 at 12:55 PM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> Chris Angelico wrote:
>
>> Python is not an "excellent option". It's a bad fit for shell
>> scripting, it just happens to be way better than a weak shell. Having
>> grown up on command.com, I found OS/2's cmd.exe to be a massive
>> improvement, and Windows's cmd.exe to be rather less impressive... but
>> both of them pale into insignificance compared to bash.
>
> I have to disagree with much of this. bash is a poorly designed language
> which, in my opinion, is only good enough for short (under 20 lines)
> throw-away scripts.
>
> [snip rant]

Your points are valid, and yet I still can't push Python as a command
execution language better than bash scripting. "Nobody" was right: as
soon as you are actually *processing* data, you want something better
than bash.

If I want to make a simple command that pulls the latest project
changes and then shows me those changes, I'm going to write a bash
script that does this:

git pull --rebase
git log --oneline origin/master..master
gitk &

Actually the script's a bit more detailed than that (variable branch,
makes a tag 'lastsync' so that I can go back to it later, passes gitk
some args so it shows me the commit most likely to be of first
interest, etc), but it's still pretty much all command execution. Now
maybe if I were using Mercurial, I could script some of that using
Python; but that would be a special-case that stems from Mercurial
actually having been written in Python, and it doesn't help if you're
working with some other set of commands that don't happen to be
importable.

But what tends to happen at work is that a script like that grows
until it hits a couple dozen lines of code, and then it gets
transparently rewritten into some other language (change the shebang
at the top, nobody needs to know/care that it got a complete rewrite).
My weapon of choice for these rewrites is usually Pike, not Python,
mainly because we don't currently have any significant amount of
Python in our codebase, but either would most likely do. (I haven't
looked into subprocess and how portable my code would be across
2.6/2.7/3.3, though.) The fact remains, though, that an applications
language is definitely *second choice* to bash scripting when it comes
to tasks that involve lots of command execution.

It feels silly enough translating this OS/2 batch script:

@logon SOME_USER /pSOME_PASS /vl
@e:\rexx\load
@db2 start database manager
@exit

into this REXX script:

/* */
"@logon SOME_USER /pSOME_PASS /vl"
"@e:\rexx\load"
"@db2 start database manager"
"@exit"

And that's a change I've made myriad times (to \startup.cmd on many an
OS/2 boot drive) It's far far worse translating it into Python, Pike,
or any other "good language".

ChrisA



More information about the Python-list mailing list