Python as a scripting language. Alternative to bash script?
in [Python]
|
From: Jorgen Grahn on 29 Jun 2010 05:06 On Mon, 2010-06-28, John Nagle wrote: > On 6/28/2010 7:58 AM, Benjamin Kaplan wrote: >> How does a program return anything other than an exit code? > > Ah, yes, the second biggest design mistake in UNIX. > > Programs have "argv" and "argc", plus environment variables, > going in. So, going in, there are essentially subroutine parameters. > But all that comes back is an exit code. They should have had > something similar coming back, with arguments to "exit()" returning > the results. Then the "many small intercommunicating programs" > concept would have worked much better. Like others said, you have standard output. sys.stdout for data, sys.stderr for human-readable errors and warnings, and the exit code for machine-readable errors. > C was like that once. In the 1970s, all you could return was > an "int" or a "float". But that got fixed. Huh? The C we have today cannot return a float, and not even a full int. 0 and 1 work, small integers up to 255 are likely to work, but beyond that common systems (Unix) will chop off the high bits. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
From: Jorgen Grahn on 29 Jun 2010 05:18 On Mon, 2010-06-28, Dave Pawson wrote: > I've a fairly long bash script and I'm wondering > how easy it would be to port to Python. > > Main queries are: > Ease of calling out to bash to use something like imageMagick or Java? > Ease of grabbing return parameters? E.g. convert can return both > height and width of an image. Can this be returned to the Python program? > Can Python access the exit status of a program? > > I'd prefer the advantages of using Python, just wondering if I got > so far with the port then found it wouldn't do something? As other remarked, bash has advantages, too. Personally, if my main job is chaining other non-trivial programs into pipelines and sequences, I don't hesitate to use Bourne shell or bash. Perl is for heavier text processing, and Python for problems with more elaborate data types. Note the distinction Bourne shell/bash. If you can get away with it, use bash for medium/large-sized scripts. Many people try to avoid bash-specific syntax, but they miss out on lots of things that make programs maintainable, like local variables. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
From: eric dexter on 29 Jun 2010 05:29 On Jun 28, 5:48 am, Dave Pawson <dave.paw...(a)gmail.com> wrote: > I've a fairly long bash script and I'm wondering > how easy it would be to port to Python. > > Main queries are: > Ease of calling out to bash to use something like imageMagick or Java? > Ease of grabbing return parameters? E.g. convert can return both > height and width of an image. Can this be returned to the Python program? > Can Python access the exit status of a program? > > I'd prefer the advantages of using Python, just wondering if I got > so far with the port then found it wouldn't do something? > > Has anyone made this comparison please? > > TIA > > -- > Dave Pawson > XSLT XSL-FO FAQ. > Docbook FAQ.http://www.dpawson.co.uk You do have a couple of couple of python scriting programs that are like bash. I don't know if they are worth using though (you would have to look them up I don't recall the names right now)
From: Robert Kern on 29 Jun 2010 14:44 On 6/29/10 4:06 AM, Jorgen Grahn wrote: > On Mon, 2010-06-28, John Nagle wrote: >> On 6/28/2010 7:58 AM, Benjamin Kaplan wrote: >>> How does a program return anything other than an exit code? >> >> Ah, yes, the second biggest design mistake in UNIX. >> >> Programs have "argv" and "argc", plus environment variables, >> going in. So, going in, there are essentially subroutine parameters. >> But all that comes back is an exit code. They should have had >> something similar coming back, with arguments to "exit()" returning >> the results. Then the "many small intercommunicating programs" >> concept would have worked much better. > > Like others said, you have standard output. sys.stdout for data, > sys.stderr for human-readable errors and warnings, and the exit code > for machine-readable errors. > >> C was like that once. In the 1970s, all you could return was >> an "int" or a "float". But that got fixed. > > Huh? The C we have today cannot return a float, and not even a full int. > 0 and 1 work, small integers up to 255 are likely to work, but beyond > that common systems (Unix) will chop off the high bits. I think he's talking about C functions now, not programs. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
From: Mithrandir on 30 Jun 2010 15:31
Michael Torrie <torriem(a)gmail.com> wrote in news:mailman.2313.1277759925.32709.python-list(a)python.org: > On 06/28/2010 02:06 PM, Mithrandir wrote: >> I can't see Python as an alt. to bash. (As I recall) Python is much >> more object-oriented than bash, but also there are many commands >> (such as apt- get, etc.) that would need Python equivs. However, I >> can see Python being used as a scripting alt. to C. > > OO is a plus for most things, in my book. As for "commands" they have > *nothing* to do with Bash. apt-get is not a Bash command. By your > logic tcsh or zsh would not be an alternate to bash, but in fact they > are. > > I use python for shell scripting quite often now. Anytime one of my > own Bash scripts exceeds 100 lines, I know it's time to switch it to > python. > Please read that link I posted a while back on how you can use > generators in python to replace many of the things that piping to > external commands did in Bash. > > There certainly are a few tasks that Bash is best at (chaining > commands together through pipes), but often Python already has support > for many of the things I'd use external commands and pipes in Bash > for. Bash is designed for working down at the level of files, > directories, and processes, but Python works pretty well too, if you > make some abstraction modules like my runcmd module that I use > extensively. > You both are correct. :) (I wrote that before my first cup of coffee, so my wording was way off. That, and I'm new to Python.) :) I think that Python "could" be a alternative to bash and have some advantages, but it's a long way off from being fully implemented. |