Python as a scripting language. Alternative to bash script?
in [Python]
|
From: Mithrandir on 28 Jun 2010 16:06 Paul Rubin <no.email(a)nospam.invalid> wrote in news:7xpqzbj8st.fsf(a)ruckus.brouhaha.com: > Re: Python as a scripting language. Alternative to bash script? > That's interesting but I'm having a hard time seeing how it would work. > I think environment variables didn't exist in early versions of Unix, > and argc/argv were passed to the child process on its stack. I guess > the reverse side could involve the "wait" system call taking a callback > parameter with a buffer to receive the returned data. But that still > only happens when the child actually exits, and presumably > intercommunicating netween programs should be bidirectional. But Unix > has always had pipes for that. 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.
From: Stephen Hansen on 28 Jun 2010 16:28 On 6/28/10 1:06 PM, Mithrandir wrote: > Paul Rubin<no.email(a)nospam.invalid> wrote in > news:7xpqzbj8st.fsf(a)ruckus.brouhaha.com: > >> Re: Python as a scripting language. Alternative to bash script? > >> That's interesting but I'm having a hard time seeing how it would work. >> I think environment variables didn't exist in early versions of Unix, >> and argc/argv were passed to the child process on its stack. I guess >> the reverse side could involve the "wait" system call taking a callback >> parameter with a buffer to receive the returned data. But that still >> only happens when the child actually exits, and presumably >> intercommunicating netween programs should be bidirectional. But Unix >> has always had pipes for that. > > > 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. Wait, what? o.O First, you don't really have to use any of the object-orientedness of Python. It doesn't push anything on you. Second, why would apt-get need a Python equiv? Just use apt-get. And, ... "a scripting alternative to C"? How's C a scripting anything, that you need an alternate for? :) I mean, "scripting" is what you use to push around C programs :) -- ... Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/
From: Michael Torrie on 28 Jun 2010 17:18 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.
From: Rhodri James on 28 Jun 2010 18:12 On Mon, 28 Jun 2010 18:57:45 +0100, John Nagle <nagle(a)animats.com> 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. That's not just a little harsh, given that I've never known any operating system that returned more than an integer exit code, it's blithely ignoring the Unix paradigm. It's stream-based processing; argv and the environment are better thought of as switches, controlling how a program treats stdin to produce stdout. Classic Unix programming is a matter of stringing a bunch of tools together with pipes to get the output you want. This isn't a great paradigm for GUIs (not without tweaking that hasn't really been done), but then again it was never meant to be. > C was like that once. In the 1970s, all you could return was > an "int" or a "float". But that got fixed. Strangely, these facts are not unconnected. -- Rhodri James *-* Wildebeeste Herder to the Masses
From: Peter H. Coffin on 28 Jun 2010 23:25
On Mon, 28 Jun 2010 23:12:47 +0100, Rhodri James wrote: > On Mon, 28 Jun 2010 18:57:45 +0100, John Nagle <nagle(a)animats.com> 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. > > That's not just a little harsh, given that I've never known any operating > system that returned more than an integer exit code, it's blithely > ignoring the Unix paradigm. It's stream-based processing; argv and the > environment are better thought of as switches, controlling how a program > treats stdin to produce stdout. Classic Unix programming is a matter of > stringing a bunch of tools together with pipes to get the output you > want. This isn't a great paradigm for GUIs (not without tweaking that > hasn't really been done), but then again it was never meant to be. 'zactly. Arguements aren't data. They're essentially passing data by reference. Some unix utilities allow you to specify output where to put output (that is, an output file); some only to one output stream. -- I didn't need to sabotage anything. Not being around to say "No that won't work" or "you can't do it that way" is more than enough damage. (Ego problem? It's not a problem.) -- Graham Reed, on job endings |