os.system question

>>import oskevin0The 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 Kevin
http://www.codebykevin.com

re: os.system question

On Wed, 06 Aug 2008 21:07:40 -0400, Kevin Walzer wrote:

That's because os.system captures the return code of the system call,
which is 0 in this case because whoami succeeded. Meanwhile whoami
printed its result to standard output, as normal.

What you want is os.popen('whoami', 'r').read()

Also look at the popen2 module.



--
Steven

re: os.system question

os.system() simply executes the command in a subshell, and returns the
command's exit status which in your case is '0'. If you need to capture the
stdout, stderr, etc. stuff, subprocess module is preferred which offers more
powerful functionalities over os.system().

Nessus

"Kevin Walzer" <kw@codebykevin.comwrote in message
news:1c5bf$489a4add$4275d90a$15022@FUSE.NET...

re: os.system question

On Aug 7, 6:07*am, Kevin Walzer <k...@codebykevin.comwrote:Why dont you try commands module instead....

In [28]: import commands

In [29]: dir(commands)
Out[29]:
['__all__',
'__builtins__',
'__doc__',
'__file__',
'__name__',
'getoutput',
'getstatus',
'getstatusoutput',
'mk2arg',
'mkarg']

In [30]: (a,b) = commands.getstatusoutput('whoami')

In [31]: print a
0

In [32]: print b
luma35

re: os.system question

SamG wrote:
Thank you! That was just what I needed.



--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

re: os.system question

In your case you could also use the os.environ dictionary:

import os
print os.environ['USER']

re: os.system question

On Aug 6, 8:07*pm, Kevin Walzer <k...@codebykevin.comwrote: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

re: os.system question

Kevin Walzer wrote:Hi Kevin, check out popen. It should let you do what you want.

import os
name=os.popen('whoami').read()

re: os.system question

On Aug 8, 6:07 am, Mike Driscoll <kyoso...@gmail.comwrote:Something like this should work,
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()".

re: os.system question

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

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@hughes.net

re: os.system question

On Tue, 12 Aug 2008 14:42:28 -0700, norseman wrote:
....Please tell me more, I am very interested in this assembly of which you
speak. How would you write a program in assembly that does the same as
the above code, and will run on any major platform? I would love to see
the code. I expect it will be much shorter and more intuitive than the
Python code you dislike, leading to fewer errors and less padding of the
programmer's pockets at the expense of their employers.



--
Steven

re: os.system question

On Mon, 11 Aug 2008 19:28:13 -0700, Asun Friere wrote:
Is it really deprecated? Since when? I'm using Python 2.5 and it doesn't
raise any warnings or mention anything in the doc string.

The current documentation does say:

"The subprocess module provides more powerful facilities for spawning new
processes and retrieving their results; using that module is preferable
to using this function."

http://docs.python.org/lib/os-newstr...#os-newstreams


but that's not the same as deprecating os.popen.



--
Steven

re: os.system question

Dnia 12 Aug 2008 22:58:22 GMT, Steven D'Aprano napisa³(a):
I think that the deprecation warnings were added in Python 2.6.

--
Regards,
Wojtek Walczak,
http://www.stud.umk.pl/~wojtekwa/

re: os.system question

On Aug 13, 8:58 am, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com.auwrote:I should perhaps have put 'deprecated' in quotation marks? Note the
post I was responding to and my own stated preference. Though I
admit, I have been trying out Popen just recently.
Current documentation also states:

"[The subprocess] module intends to replace several other, older
modules and functions, such as: ... [inter alia] ... os.system,
os.popen*, commands.*"

http://docs.python.org/lib/module-subprocess.html

Which is also not exactly the same thing as deprecating os.popen, but
it does sound somehwat more ominous. One hopes the subprocess module
is not successful in realising its intentions.

I note 3.0 runs os.popen without complaint (and had thought to mention
that in my previous). Right now I'm wondering whether I should
install the beta 2.6 to see whether Wotjek is pulling our leg or
not. :)

re: os.system question

Dnia Tue, 12 Aug 2008 23:38:56 -0700 (PDT), Asun Friere napisa³(a):
:) Checked it to make sure.

Python 2.6b2 (r26b2:65082, Aug 13 2008, 01:12:28)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
Type "help", "copyright", "credits" or "license" for more information.__main__:1: DeprecationWarning: The popen2 module is deprecated. Use the subprocess module.gminick
gminick
__main__:1: DeprecationWarning: os.popen2 is deprecated. Use the subprocess module.
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
IOError: [Errno 9] Bad file descriptorThe strange thing is that os.popen2 prints the deprecation warning
only when it's called inappropriately. Got to investigate it further.

os.popen won't return any deprecation warning in Py2.6beta2 probably
because it is defined in Lib/platform.py and not in Lib/os.py and
I guess that somebody has forgotten to add the warnings in there.

--
Regards,
Wojtek Walczak,
http://www.stud.umk.pl/~wojtekwa/

re: os.system question

On Aug 13, 1:38*am, Asun Friere <afri...@yahoo.co.ukwrote:That was the wording I was referring to. Now that I re-read it, I
guess it doesn't say "deprecated" per se, but it seemed to imply it.
And I think one of the Python luminaries said as much (Holden or
Lundh) in one of their old posts last year.

Mike

re: os.system question

Mike Driscoll wrote:
not talking for the 3.X developers here, but os.popen is a binding to
the POSIX popen function, so I'm not sure it makes that much sense to
actually deprecate it.

the os.popen[234], popen2, and commands stuff are different -- they're a
a series of attempts to provide more functionality by building on
lower-level primitives, something that the subprocess module does a lot
better.

</F>

re: os.system question

On Aug 13, 3:03*pm, Fredrik Lundh <fred...@pythonware.comwrote:Interesting. Good to know. Thanks for the clarification.

Mike

re: os.system question

Dnia Wed, 13 Aug 2008 22:03:49 +0200, Fredrik Lundh napisa³(a):
This makes sense. My idea that some developer had forgotten to add
the deprecation warning for os.popen() goes to the bin.


--
Regards,
Wojtek Walczak,
http://www.stud.umk.pl/~wojtekwa/

re: os.system question

Fredrik Lundh wrote:
I think the 'commands' module is nice--it's very handy in parsing output
from a 'fire-and-forget' system call. I'd hate to see it removed entirely.

I'm also skeptical of the value of subprocess, at least as a complete
replacement for os.popen (the original version): it currently provides
no way to set a 'non-blocking' mode. I make heavy use of this kind of
call in my code:

self.file = os.popen('do stuff here'), 'r', os.O_NONBLOCK)

Having this kind of capability built into the language strikes me as
important. If subprocess lacks it, and one has to go to the ActiveState
cookbook to implement similar functionality, then it's hard for me to
embrace it as a replacement.

N.B: I develop on a Unix-like system (Darwin/MacOS), so others
understand where I'm coming from.

--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

re: os.system question

Kevin Walzer wrote:
Eh, what? The third argument to os.popen is the buffer size to use for
the file object, while O_NONBLOCK is an integer flag that you can use
with os.open (no "p" in there), fcntl, etc. to work with fifos and
special devices.

(O_NONBLOCK happens to be 2048 on at least some Unix machines, so
chances are that your snippet simply opens the stream with a 2k buffer
instead of the 4k default.)

To control the buffer size for subprocess, use the bufsize argument to
Popen.

</F>