Python as a scripting language. Alternative to bash script?

[Peter H. Coffin]

On Mon, 28 Jun 2010 23:12:47 +0100, Rhodri James wrote:
> On Mon, 28 Jun 2010 18:57:45 +0100, John Nagle <nagle at 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