os.system question

[norseman]

Asun Friere wrote:
> On Aug 8, 6:07 am, Mike Driscoll <kyoso... at gmail.com> wrote:
>> On Aug 6, 8:07 pm, Kevin Walzer <k... at codebykevin.com> wrote:
>>
>>>  >>> import os
>>>  >>> foo = os.system('whoami')
>>> kevin
>>>  >>> print foo
>>> 0
>>>  >>>
>>> The standard output of the system command 'whoami' is my login name. Yet
>>> the value of the 'foo' object is '0,' not 'kevin.' How can I get the
>>> value of 'kevin' associated with foo?
>>> --
>>> Kevin Walzer
>>> Code by Kevinhttp://www.codebykevin.com
>> Just an FYI, the os.system, commands, and os.popen* stuff is
>> deprecated in Python 2.4+. The subprocess module is supposed to
>> replace them all.
>>
>> See the docs for more info:http://docs.python.org/lib/module-subprocess.html
>>
>> I think the equivalent is subprocess.Popen with the communicate()
>> method:
>>
>> http://docs.python.org/lib/node532.html
>>
>> HTH
>>
>> Mike
> 
> Something like this should work,
> 
>>>> from subprocess import Popen, PIPE
>>>> me = Popen('whoami', stdout=PIPE, shell=True).stdout.read()
> 
> but if I was in a hurry to find out who I was I would be tempted still
> to use the deprecated "os.popen('whoami').read()".

I assume Asun added the above line. I agree with whoever wrote it. SLT

> --
> http://mail.python.org/mailman/listinfo/python-list
> 
==========================

Can we take a moment and look at what is happening here?

Python developers are creating an unwanted item!

Let's take a good look:

1) import os                                                          9
2) name=os.popen('whoami').read()                                    30

3) from subprocess import Popen, PIPE                                34
4) me = Popen('whoami', stdout=PIPE, shell=True).stdout.read()       59

While lines 1 and 3 are typically done once per module, line 3 would 
seem to imply the need for making specific requests for sub-process and 
associated and (required) other pieces.  Lots of combinations to 
remember, fumble, and have to re-research to do the simple.

Stats point up something too:
  30/9  = 3.333...
  59/30 = 1.966...

without any other factors such as normally additional lines of code for 
the more verbose 'better' package it still will take at least twice as 
long to code the same thing. Add Murphy's Law and the typos go through 
the roof. Expect (after all is said and done) for the same process to 
take 3 times as much clock time to complete the same project using the 
padded up new and improved vs the concise.

This is not intuitive and it is not necessary and it most certainly is 
not wanted. Not by the programmer, not by the client and not by the one 
paying the paycheck.  If 1&2 have a security hole - address it directly. 
Do not add more confusion to help cover greater holes.  Or to pad your 
pockets because you are bored.

Somebody had to say it.  Besides, as a trouble shooter I used to get 
paid to locate and fire people that padded it up to their employers. The 
things of which individuals can justify to themselves is truly amazing.

I still prefer assembly. It's all right there, right up front. No 
compiler anomalies (accidental or intentional) to deal with.


Man the shelters Honey; major incoming expected momentarily. :)



Steve
norseman at hughes.net