in perl i can do this:
...
if (open (MYPIPE, "*some_system_command* |"))
{
...
*do_something*
...
while ($answer = <MYPIPE>)
{
print $answer;
}
...
*do_something_more*
...
}
else
{
...
*do_something_else*
...
}
...
but i do not know how to do it in python, because "if *command*:" gives
syntax error.
moreover, if i use
...
import os
...
try:
MYPIPE = os.popen("*some_system_command*, "r")
...
*do_something*
...
for answer in MYPIPE:
print answer,
MYPIPE.close()
...
*do_something_more*
...
except:
...
*do_something_else*
...
...
it doesn't work, since "*do_something*" and *do_something_more* are
always executed (it seems like
MYPIPE = os.popen("*some_system_command*", "r")
does not raise any exception even if *some_system_command* does not
exist/work...
any help?
thanks a lot
max
(snip)
> it doesn't work, since "*do_something*" and *do_something_more* are
> always executed (it seems like
>
> MYPIPE = os.popen("*some_system_command*", "r")
>
> does not raise any exception even if *some_system_command* does not
> exist/work...
>
> any help?
http://www.python.org/doc/2.4.1/lib/os-newstreams.html#os-newstreams
"""
The exit status of the command (encoded in the format specified for
wait()) is available as the return value of the close() method of the
file object, except that when the exit status is zero (termination
without errors), None is returned.
"""
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'on...@xiludom.gro'.split('@')])"
stdin, stdout, stderr = os.popen3(cmd)
stdin.close()
results = stdout.readlines()
stdout.close()
errors = stderr.readlines()
stderr.close()
if errors:
raise Exception(''.join(errors))
Maybe this will get you going in a better direction?
but i need to check the success/failure of the external command *before*
closing the file!
yeah thanks!
i translated as:
....
import os
....
CMD_STDIN, CMD_STDOUT, CMD_STDERR = \
os.popen3("*some_system_command*", "r")
if not CMD_STDERR.readlines():
...
*do_something*
...
for answer in CMD_STDOUT:
print answer,
...
*do_something_more*
...
else:
...
*do_something_else*
...
CMD_STDIN.close()
CMD_STDOUT.close()
CMD_STDERR.close()
....
bye
max
but... i see it doesn't work for some commands, like "man python" (it
gets stuck on the "if" line)...
how come?
You can't, unless you have a more intimite knowledge of the command
involved. If you know, for instance, that any output on stderr means
an error, you can check for just that. Without knowledge of the
command and it's output, the only thing you can check on is the exit
code.
Sybren
--
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?
Frank Zappa
> in perl i can do this:
...
> but i do not know how to do it in python, because "if *command*:" gives
> syntax error.
>
> moreover, if i use
...
> it doesn't work, since "*do_something*" and *do_something_more* are
> always executed (it seems like
>
> MYPIPE = os.popen("*some_system_command*", "r")
>
> does not raise any exception even if *some_system_command* does not
> exist/work...
Just to address this last point -- if you're running 2.4,
you can get this through the subprocess module. With its
popen equivalent, something like
subprocess.Popen(cmd, stdout=subprocess.PIPE).stdout
will raise an exception if the command is not found. The
command in this case would specified as an argv list, not
a shell command.
The basic problem is that you have to fork first, then
exec, and by the time the forked interpreter finds out
that the exec didn't work, its parent has gone on to
do the I/O it's expecting. I think subprocess gets
around that, on UNIX, with a trick involving an extra
pipe, that would work only on UNIX.
Donn Cave, do...@u.washington.edu
.readlines() won't return until it hits end-of-file, but the "man"
command waits for user input to scroll the content, like the "more" or
"less" commands let you view "pages" of information on a terminal.
bye
max
>i> .readlines() won't return until it hits end-of-file, but the "man"
>i> command waits for user input to scroll the content, like the "more" or
>i> "less" commands let you view "pages" of information on a terminal.
man shouldn't wait for user input if its output is a pipe. Try man man|cat.
--
Piet van Oostrum <pi...@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4]
Private email: pi...@vanoostrum.org