On Wed, Feb 6, 2013 at 12:55 PM, Steven D'Aprano <steve+comp.lang.pyt...@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 -- http://mail.python.org/mailman/listinfo/python-list
