The argument for the target executable are passed as a 
string to popen. The problem is that with filenames which 
contains spaces, the argument breaking routine will fail 
and create two arguments for one filename. 
 
It would be more convenient if one could pass the 
argument to popen as a list of string. 
 
 

Logged In: YES 
user_id=80475

Does it work for you if the filename is quoted:  "thrill 
seeker.txt" ?

Logged In: YES 
user_id=139865

Yes, it works.  This is also the same behaviour as
os.system.  os.popen2 allows one to pass either a quoted
string or a sequence of strings (pfremy's suggested
behaviour).  It would be nice to have consistent
functionality, and using a sequence would be easier when
providing a list of files to be operated on.  I am willing
to provide a patch if this is the desired functionality.

Logged In: YES 
user_id=233844

I was trying to use python as a shell replacement for simple 
scripts, but I was disapppointed by the poor level of support of 
python for those things. 
 
In my case, the list of files was pulled from a command and 
passed to another one. 
 
I have some suggestions on how to improve python shell 
scripting capability. Right now, as soon as you want to do 
something a little bit complicated, like feeding a program (let's 
say grep) from the output of another program and checking the 
output and the exit status is quite complicated. 
 
For such an interface to be good, it has to provide _very_ easy 
way to: 
- read stdout from a command 
- provide stdin to a command 
- read exit status of a command. 
- pipe a command into another one 
 
Let's say I want to run the equivalent of 
find . -name '*.cpp' | grep -i toto 
 
My suggested interface to run a simple command would be as 
following: 
cmd( "find", ".", "-name", "*.cpp")  
 
This defines a command to be run. To be versatile, this would 
have to accept although the following format: 
 
cmd( [ "find", ".", "-name", "*.cpp" ] ) 
cmd( "find", [  ".", "-name", "*.cpp" ] ) 
which are slightly different ways of spawning a command. I think 
all these three ways have a usage pattern. 
 
To actually execute the command, you woud do: 
cmd( "find", ".", "-name", "*.cpp" ).go() 
 
This create an object which has  
 
 
 
To run it, you just apply the go() method: 
 
cmd( "find", ".", "*.cpp" ).go() 
 
This could return a tuple (stdout, stderr, return_code) 
 
Now, if you want to pipe a command into another one, we can 
either override the operator | or write it manually. My initial 
command would become: 
cmd( "find", ".", "-name", "*.cpp" ).pipe().cmd( "grep", "-i", "toto" 
) 
 
I dislike using a syntax like cmd().pipe( cmd ) because piping 
multiple commands would required parenthesis nesting which 
does not look nice. The goal is to reach the simplicity of shell 
scripting. 
 
To execute the previous command, one would simple again use 
the go() method: 
 
(stdout, stderr, ret_status) = cmd( "find", ".", "-name", "*.cpp" 
).pipe().cmd( "grep", "-i", "toto" ).go() 
 
Here for my suggestion. It might be more appropriate to post it 
to a mailing list, to get more feedback ? 
 
I am sorry, I am very busy now and won't have time to 
implement this myself. 
 
 
 
 

Logged In: YES 
user_id=344921

popen5 (http://www.lysator.liu.se/~astrand/popen5/) uses a
sequence argument instead of a string, and has no problems
with whitespace. Also, it supports connecting several
subprocesses together (feeding the output from one command
into another). 

Logged In: YES 
user_id=752496

Please, could you verify if this problem persists in Python 2.3.4
or 2.4?

If yes, in which version? Can you provide a test case?

If the problem is solved, from which version?

Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".

Thank you! 

.    Facundo

Logged In: YES 
user_id=752496

Think that this should be closed with "Won't fix" specially
now that we have the subprocess module.

Logged In: YES 
user_id=80475

The proposed change would not be eligible for backporting as
it is a new feature.  And since Py2.4 and later already have
a preferred solution (in the form of the subprocess
modules), will close this feature request as being
out-of-date (or least, no longer necessary).

Feel free to re-open if the sub-process module does not
fully meet your needs.

Logged In: YES 
user_id=233844

I am ok with closing the bug as WONTFIX but I think that:
- the documentation to os.popen and the module popen should
inform the user about this limitation
- the documentatino to os.popen and the module popen should
point the user to the new subprocess module

Not everybody reads the What's new and people might still be
using popen when subprocess does a better job.