Running a Python script from WinBatch (interesting PATH issue)

[snowsnowsnow]

Found something interesting today.

I have a Python script - call it FOO.PY - that I want to run from a WB script.  FOO.PY is located in a directory that is in my PATH - say, C:\bin.  If I run FOO.PY directly from the CMD prompt, it works as expected (.PY is correctly "associated" with python.exe).

But, when I run it in WB, like:

Code (winbatch) Select Expand

RunWait("foo.py","")


it runs Python, but Python says "File not found: foo.py".

The obvious fix, which works fine, is to change it to:

Code (winbatch) Select Expand

RunWait(FileLocate("foo.py"),"")


FileLocate() does the PATH search, so you end up passing the full pathname to Python.

But I'm kind of curious as to why this happens.  Which part of the puzzle dropped the ball?

Note: I'd imagine that another workaround would be to run it via "CMD /C" - which would get the shell, er, I mean, Command Interpreter, involved, but I'm curious why it doesn't work as expected.  Note that I prefer the FileLocate() fix over the "CMD /C" fix, for a variety of reasons.

[td]

Because doesn't work the way you think it should does not necessarily mean that a ball was dropped. 

When you pass the WIL Run functions the name of a data file instead of the name of an executable file, the WIL Run functions do the standard Windows file association lookup and pass whatever you provide to the associated executable file as a parameter when they start the executable's process.   What gets passed to the executable is determined by you and how the executable handles that information is determined by the creators of the executable.

[snowsnowsnow]

That makes sense.  Thanks.

[snowsnowsnow]

I should add that (ISTM) you are saying that it is up to the program (python.exe in this case) to do the PATH search - that is, to figure out that FOO.PY is really C:\bin\FOO.PY.

However, against this is the fact that some piece of the puzzle has already done the PATH search at that point - it knows where FOO.PY is - so, it *could* do the right thing and act as if the user had passed the full pathname in.

To see this, I tested doing:

Code (winbatch) Select Expand

RunWait("noTThere.py","")

And that generates a "WinExec" failure (As opposed to a "We ran Python, but Python failed to find the script" type error).

All in all, it seems to be working as designed, but not as expected (if you see what I mean...)

[td]

WinBatch finds the Python executable because there is a standard mechanism built into Windows by Microsoft for locating executables associated with file extensions.  However, there is no such mechanism for how the file is accessed or even used by the executable.  WinBatch is not going to guess for you.

To put it another way,  I have 33 instances of the file named whphost.js on my workstation.  If I don't specify a path as part of the file name or preset the CWD to the folder containing one of the files (the app I am using looks in the CWD), which one do I mean?