Dennis Lee Bieber wrote: > On Wed, 6 Feb 2013 17:16:04 +1100, Chris Angelico <ros...@gmail.com> > declaimed the following in gmane.comp.python.general: > >> >> 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". >> > Though that is the nice feature of REXX*... Anything that wasn't > parsable as a REXX statement was automatically sent to the current > command processor.
Nice? Are you being sarcastic? What you're describing sounds like a classic "Do What I Mean" system, which invariably end up being followed by anguished shouts of "Noooo, I didn't mean that!!!". The Zen of Python is not just design principles for *Python*. They hold for other languages as well. Having to explicitly send a command to an external command processor (say, the shell) is much better **and safer** than implicitly doing so on SyntaxError, even if such a requirement makes your program more verbose. > Converting such to Python turns into a mishmash of (pick your > favorite) os.system(), subprocess.Popen(), etc. with their particulars > of how to pass command line arguments. Why on earth would anyone use a "mismash" within the one script? Pick one and stick to it. If you have only wish to give a few commands, and don't care about getting data back from them, use os.system which is embarrassingly easy and almost as concise as the REXX script above: from os import system as s s("@logon SOME_USER /pSOME_PASS /vl") s("@e:\rexx\load") s("@db2 start database manager") s("@exit") If you find yourself needing complicated string escapes, use subprocess.call instead. If you do care about getting data back from the external system, then you need to integrate the external code with your Python (or REXX) code, and that requires more than just firing off a few system commands and forgetting about them. That's inherently complicated, because there are many possible factors to care about: - do you care about stdout, stderr, stdin? - start a new subshell? - deal with shell metacharacters? - deadlocks? etc. Lack of terse syntax is the least of your worries here, doing these things *correctly* is hard in the shell. Having to type a few extra symbols doesn't make it any harder in any meaningful way, and readable syntax can actually make it simpler to reason about the code. If you say "Anything that isn't parsable is automatically sent to the shell", it doesn't sound too bad. But when you say "Unparseable junk is implicitly treated as code and sent off to be executed by something which traditionally tends to be forgiving of syntax errors and has the ability to turn your file system into so much garbage", it sounds a tad less appealing. -- Steven -- http://mail.python.org/mailman/listinfo/python-list