From: Mithrandir on
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
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
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
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
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