> I'm having trouble using one of the example python submit scripts
> you sent me. The script uses os.popen() to run a command and read back
> its stdout results, but it seems os.popen() is loosing all the command's output.
>
> You even sent me a tiny simple script to narrow it down:
>
> import os,sys
> fp = os.popen("netstat -n", "r")
> while 1:
> line = fp.readline()
> if not line: break
> print "WORKING ON: " + line,
> raw_input("Done! ")
>
> ..and I'm having the same problems with that too!
>
> The script works fine when I:
>
> o Run it from the DOS command line, whether the script is on a local drive
> or network drive.
>
> o If I open a file browser and click on it using a folder browser,
> it works fine /only/ if it's on a local drive.
>
> But the os.popen() command returns NOTHING, no errors or anything
> if the script is on the server and I double click on it from a folder browser.
>
> What's weird is if I drag+drop the file from that browser into DOS,
> and run it, it works *fine*.
>
> Know what the issue is, and jeez, what the heck?? Is python busted?
Strange issue; we played with this in teamviewer at your office.
And yes, I could replicate at my office too, both with Windows8
and with Windows XP.
As an aside, we found replacing os.popen() with subprocess.Popen()
solved it, but it bugged me because I /know/ os.popen() is /not/
that broken.
Finally figured it out after some prodding with it here.
Short answer is to add this one line to fix to the script
anywhere before the os.popen() command is called:
os.chdir("c:/")
Seems the issue is when you click on a program from a Microsoft Windows
folder browser, that directory becomes the "current working directory"
(cwd) for the program.
And if that directory happens to be a UNC path to a server,
the cwd becomes that UNC path.
That shouldn't be a problem, except DOS doesn't like it when
the cwd is a UNC path (it whines about not supporting UNCs,
even though it clearly does)
Since os.popen() runs the child process in a DOS shell,
DOS /is/ involved in the operation.
Now THAT shouldn't be a problem either, because even though DOS
whines about a UNC cwd, the command /still/ runs OK. You can
prove that by using os.system() in the script, which shows the
UNC error, followed by the command's output.
But for some reason this UNC warning trips up os.popen(), causing
it to *fail silently.* Probably not an issue with python, so much
as the C library call python is using, probably popen(3).
So by using os.chdir() to use a local path (with a drive letter),
this makes DOS happy, and by extension, os.popen() works.
As further proof of this: I found if you comment out the above fix
and open *two folder browsers* to view the same script, the difference
being:
1) Open one browser with a UNC style path, e.g. \\your\server\somedir
2) Open the other browser with a *drive letter* path, e.g. z:\somedir
..when you double click the python script from the UNC browser,
the os.popen() command misbehaves.
Do the same with the "drive letter" browser, and it works fine.
Luckily the os.chdir("c:/") is a simple workaround, as we don't want
to dissuade people from using UNC's in browsers.
If you find similar problems in the python submit scripts,
I'd suggest using logic like this in __main__ to work around:
________________________________________________________________________ SNIP
if __name__ == "__main__":
# ADD THE FOLLOWING 2 LINES
if Rush.IsWindows() and not os.environ.has_key("RUSH_TMPDIR"):
os.chdir("c:/")
________________________________________________________________________ SNIP
That bit about RUSH_TMPDIR ensures when the script runs in render mode,
it doesn't mess up the cwd directory that rush has set for it.
I'll make sure something like this is done by default for the
submit scripts in the next release of 103.05.
|