Issue466451
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2001-09-30 00:34 by bquinlan, last changed 2022-04-10 16:04 by admin. This issue is now closed.
Files | ||||
---|---|---|---|---|
File name | Uploaded | Description | Edit | |
popen.patch | bquinlan, 2001-09-30 00:34 | Patch for popen on Windows | ||
popen2.patch | bquinlan, 2001-10-05 07:54 | Force usage of cmd.exe or COMMAND.COM |
Messages (13) | |||
---|---|---|---|
msg37741 - (view) | Author: Brian Quinlan (bquinlan) * | Date: 2001-09-30 00:34 | |
In a Windows version of Python, try the following: os.popen('"<path-of-exe" "path-of-arg"'>.read() cmd.exe will misinterpret the command string because it strips the first and last quote in the command string (cmd.exe /? for details). This patch does a few things: 1. it encloses the command string sent to cmd.exe in quotes and uses the /S switch 2. if the shell is not command.com or cmd.exe, it passes the -c switch to the shell (this makes popen work if the user's shell is bash, sh, etc.) 3. changes the variables s1, s2 and s3 to cmdPath, completeCmd and cmdArgs |
|||
msg37742 - (view) | Author: Guido van Rossum (gvanrossum) * | Date: 2001-09-30 18:46 | |
Logged In: YES user_id=6380 Tim, whaddayathink? Or is this for Mark? |
|||
msg37743 - (view) | Author: Brian Quinlan (bquinlan) * | Date: 2001-09-30 20:11 | |
Logged In: YES user_id=108973 Mark understands the issue; I've already talked to him about this. Another thing that I should have noted is that this patch does NOT ensure backwards compatibility. Any scripts that manually quote their command strings, to work around this problem, will break. |
|||
msg37744 - (view) | Author: Tim Peters (tim.peters) * | Date: 2001-10-01 22:36 | |
Logged In: YES user_id=31435 Assigned to MarkH for further pondering. I like giving vrbls useful names The rest seems highly dubious: + Catering to non-MS shells ("-c" vs "/C") is a fine idea, but what about 4DOS or 4NT, or other non-MS shells that also expect /C? It looks like this patch will kill people using them. - It's not backwards compatible regardless of shell (as Brian pointed out). - It's surprising to anyone who has read the cmd docs and expects cmd.exe to work as documented (by MS). - Since it's unique to Python's popen, a command string that works for popen() may break if passed to os.system() instead, and vice versa, and maybe for os.startfile() too. Other things bug me, but I'll stop there <wink>. The MS shells are a godawful mess, and it would really be nice to supply a rational x-platform "virtual shell" syntax (as Tcl does for its "exec" cmd). Short of that, I'm not sure a collection of inconsistent and undocumented hacks is actually progress; as is, Python's behavior is at least predictable from reading the MS docs and/or playing with C programs under MSVC. |
|||
msg37745 - (view) | Author: Brian Quinlan (bquinlan) * | Date: 2001-10-02 00:43 | |
Logged In: YES user_id=108973 Tim, I don't disagree with your first point; without specific knowledge of each shell, you really have to guess what the correct shell arguments format is. There are two ways that we can work around that: 1. remove those two lines of code in my patch that do the special case 2. special case bash and sh (at least bash please) and use /C for the other cases I disagree with everything else :-) The command: bash "ls" "/usr/bin" will NOT work on UNIX. Just like typing: cmd /c "copy" "c:\..." "c:\..." won't work. So the UNIX popen implementation must be doing the moral equivalent of quoting the entire command string. So the current behavior is suprising and inconsistent accross platforms. I don't think that we can do anything with regards to backwards compatibility but I think that the cost/benifit favours fixing the problem i.e. accepting my patch :-) |
|||
msg37746 - (view) | Author: Tim Peters (tim.peters) * | Date: 2001-10-02 02:12 | |
Logged In: YES user_id=31435 Special-casing bash instead (+ other shells known to need it) to use -c would be fine. I *expect* os.system and os.popen to work differently across platforms, because both depend crucially on the platform shell spawned to crack the cmdline. Tcl's "exec" (which I mentioned before) has the only good solution to this I'm aware of, via getting the platform shells out of the equation entirely (even on Unix). Python does nothing of the sort, and the more undocumented tricks are stuffed into it, the more baffling it gets when things go wrong (as they often will, and especially on Windows). I didn't understand the point to noting that bash "ls" "/usr/bin" won't work on Unix. Neither will bash ls /usr/bin The quotes are irrelevant here, yes? Python isn't adding quotes to things, or deleting them, anyway. Note that if you write your own copy.bat, command /c "copy" "whatever1" "whatever2" does work fine on Win9x (command.com). It doesn't work with the Windows copy solely because copy is a command.com builtin -- and you can't hide arbitrary platform crap like that from users either. |
|||
msg37747 - (view) | Author: Brian Quinlan (bquinlan) * | Date: 2001-10-02 02:51 | |
Logged In: YES user_id=108973 Sorry, I was sloppy about my point (I missed the -c switch). Here is dump from my UNIX box: [93:~] brian% sh -c "ls" "/usr" Desktop Documents Movies Pictures Sites bash-2.05 Dev Library Music Public Wolf MP Test setiathome [93:~] brian% sh -c ""ls" "/usr"" bin lib local share include libexec sbin standalone [93:~] brian% python [...] >>> import os >>> os.popen("ls /usr").read() 'bin\ninclude\nlib\nlibexec\nlocal\nsbin\nshare\nstandalone\ n' You will notice that the results from Python are inline with the quoted invocation of sh -c. And "man popen" on my box says that "This command is passed to /bin/sh using the - c flag;..." so presumably popen is quoting the arguments (Windows _popen doesn't though, I checked). And I didn't change the COMMAND.COM behavior - I think that it is a special case that is too broken to fix and will, with any luck, will die soon. |
|||
msg37748 - (view) | Author: Brian Quinlan (bquinlan) * | Date: 2001-10-03 05:48 | |
Logged In: YES user_id=108973 How about this as an alternate implementation: if we are running on a Windows version that should have cmd.exe, we just execute that and ignore COMSPEC? Notice how popen on UNIX runs sh, not your prefered shell. |
|||
msg37749 - (view) | Author: Guido van Rossum (gvanrossum) * | Date: 2001-10-03 11:55 | |
Logged In: YES user_id=6380 +1 |
|||
msg37750 - (view) | Author: Brian Quinlan (bquinlan) * | Date: 2001-10-05 07:53 | |
Logged In: YES user_id=108973 OK, here is a version of popen for Windows that always uses cmd.exe on WinNT and always uses COMMAND.COM on Win9x. I have tested the W9x code path on my W2K box but not on a real W9x box. |
|||
msg37751 - (view) | Author: Tim Peters (tim.peters) * | Date: 2001-10-05 18:40 | |
Logged In: YES user_id=31435 Back to Mark -- still want his take on this. My take: Guido also seems attracted to the Unixish purity of insisting on a specific shell, but because the MS shells suck I am not. People pay good money to get replacement shells (line 4NT) on Windows, and we're going to break their Python code if we don't respect COMSPEC, as MS system () and _popen() respect it (and as Python *has* respected it so far). The difference between Unix and Windows is that /bin/sh is adequate to all tasks, just a little feature-starved compared to some of the alternatives. But the std Windows shells are inadequate, and MS goes out of its way to let users plug in alternatives. In the absence of Python supplying its own adequate shell (as Tcl does), so it goes. |
|||
msg37752 - (view) | Author: Brian Quinlan (bquinlan) * | Date: 2001-10-05 20:02 | |
Logged In: YES user_id=108973 What's wrong with cmd.exe? The only thing that bothers me about it is that you can't quote built-in commands. In any case, what you want depends on your usage scenario: 1. If you control COMSPEC or only care that it works on systems where COMSPEC points to a MS-compatible shell (or a few shells that we special-case) then you want patch #1 2. If you want your script to behave consistanty accross platforms and Windows installations then patch #2 is the one that you want 3. If you've already quoted the entire command string in all of your popen calls then you don't want either patch BTW, system annoys me too and I'll probably investigate a fix: >>> os.system('"ls" "c:\\"') 'ls" "c:\' is not recognized as an internal or external command, operable program or batch file. >>> C:\>"ls" "c:\" [correct results] Anyway, I'll leave it to the smart people to decide which way is best. If you end up going with #2 then I'll resubmit my patch such that MS shell compatibility is assumed by default and other shells are special-cased. |
|||
msg37753 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2003-10-05 08:53 | |
Logged In: YES user_id=21627 I'm rejecting the patch, for the following reasons: 1. It is outdated (i.e. it doesn't apply cleanly) 2. It does not work for me on XP: Even if I put double-quotes around the string and use /s, I still don't get the program invoked. bquinlan, if you are still interested in this change, please produce a new patch, and test it on various systems. It appears that there is still the desire to use COMSPEC, so you should probably check whether COMPSPEC has cmd.exe as a substring before passing /s. |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-10 16:04:29 | admin | set | github: 35251 |
2001-09-30 00:34:05 | bquinlan | create |