Need a cross-platform way to execute binary

[techtonik]

Hello, everyb.

Does anybody know simple cross-platform method of probing if
executable binary is available and launching it.


Problem no.1: test if executable file is available
I'll take windows platform as the most relevant in this case.
os.access() doesn't handle env PATHEXT and can't detect if a given
path would be executable or not. Here "executable" means file that
could be be launched by system() (if there are any other ways - I'd be
happy to know them)

Suppose I have "ufo2exe" executable two directories up.

True

However... False

But...

---- ufo2map 1.0 ----
0


Problem no.2: launch executable file
The same windows platform again. All python commands are using forward
slashes for paths, but system doesn't handle this situation (it could
at least try to convert immediate forward slashes to backwards)

os.access() thinks this file is executable, but os.system() fails ...'..' is not recognized as an internal or external command,
operable program or batch file.
1

the contrary - access() fails to tell this path can be launched, but
file Is executable, ...---- ufo2map 1.0 ----
0


Is there any workaround in Python or I have to stick with platforms-
specific quirks?
I'm using Python 2.4.2

Thanks!.

 

[Gabriel Genellina]

Hello, everyb.

Does anybody know simple cross-platform method of probing if
executable binary is available and launching it.


Problem no.1: test if executable file is available
I'll take windows platform as the most relevant in this case.
os.access() doesn't handle env PATHEXT and can't detect if a given
path would be executable or not. Here "executable" means file that
could be be launched by system() (if there are any other ways - I'd be
happy to know them)

Suppose I have "ufo2exe" executable two directories up.
False

That's right - such file does not exist. On Windows, in general, X_OK is
the same as F_OK: for any existing file, whatever name or extension,
returns True. Permissions are managed thru ACL and this simple function
does NOT consider them.

But...
---- ufo2map 1.0 ----
0

(Beware of single \ on normal strings!)
Use win32api.FindExecutable; should return the full path to ufo2map.exe.
"foo.txt" would return notepad.exe (or whatever you have associated to
text files). That is exactly what would be launched by os.system("foo.txt")

Problem no.2: launch executable file
The same windows platform again. All python commands are using forward
slashes for paths, but system doesn't handle this situation (it could
at least try to convert immediate forward slashes to backwards)

Use os.path.normpath on the filename. (If you got it from FindExecutable
above, that would not be needed)

os.access() thinks this file is executable, but os.system() fails ...
'..' is not recognized as an internal or external command,
operable program or batch file.
1

the contrary - access() fails to tell this path can be launched, but
file Is executable, ...
False

Same as above - such file does not exist.

---- ufo2map 1.0 ----
0

Is there any workaround in Python or I have to stick with platforms-
specific quirks?
I'm using Python 2.4.2

I think you will have to treat each platform differently. Just for
starting, the concept of "executable" is not the same across platforms.
But you could make some generic functions (with different implementations
on different platforms).

 

[techtonik]

That's right - such file does not exist. On Windows, in general, X_OK is
the same as F_OK: for any existing file, whatever name or extension,
returns True. Permissions are managed thru ACL and this simple function
does NOT consider them.

It shouldn't matter if the file exists or not. Quoting http://
docs.python.org/lib/os-file-dir.html:
"
X_OK
Value to include in the mode parameter of access() to determine
if path can be executed.
"

See - there is no "file" notation as only "path" is tested and "path"
is pretty executable. I think this should be clarified in os.access()
documentation to make the whole business less confusing if not
implemented in interpreter itself. After all the purpose of cross-
platform language is to free developer from writing platform-specific
code.

(Beware of single \ on normal strings!)
Use win32api.FindExecutable; should return the full path to ufo2map.exe.
"foo.txt" would return notepad.exe (or whatever you have associated to
text files). That is exactly what would be launched by os.system("foo.txt")

Why isn't it possible to integrate the functionality in os.access() -
IIUC Python interpreter still uses Windows API itself on this
platform.

Use os.path.normpath on the filename. (If you got it from FindExecutable
above, that would not be needed)



Same as above - such file does not exist.

Same as above - access() tests path, not file, so the argument is not
valid.

I think you will have to treat each platform differently. Just for
starting, the concept of "executable" is not the same across platforms.
But you could make some generic functions (with different implementations
on different platforms).

I would prefer to know as little about underlying platforms as
possible.
It would only be a big plus for Python.

 

[Gabriel Genellina]

On Feb 10, 12:03 pm, "Gabriel Genellina" <[email protected]>

This is a very specific definition of "executable". os.access does not use
that definition.

It shouldn't matter if the file exists or not. Quoting http://
docs.python.org/lib/os-file-dir.html:
"
X_OK
Value to include in the mode parameter of access() to determine
if path can be executed.
"

See - there is no "file" notation as only "path" is tested and "path"
is pretty executable.

It appears that your argument is: os.system("../../ufo2map") launches a
new process, so "../../ufo2map" must be executable. But
os.system("foo.txt") also works, so "foo.txt" is also executable?
Please define "executable" first. The definition may be so restrictive as
to only include PE files (all others require a wrapping process) or so
broad as to include almost anything known to the system.

I think this should be clarified in os.access()
documentation to make the whole business less confusing if not
implemented in interpreter itself. After all the purpose of cross-
platform language is to free developer from writing platform-specific
code.

os.access documentation is rather clear - it's just a wrapper around the
access() system call, and I think it should not be changed. It is the
underlying OS which gives the answer, not Python.

On the other hand, an utility library exposing FindExecutable,
ShellExecute, associations and other shell goodies might be useful. Maybe
you could do some research, whether such thing exists, and help improve it
or design a good interfase?

I would prefer to know as little about underlying platforms as
possible.
It would only be a big plus for Python.

Sure, but someone has to write it. I can't think of a good abstraction
right now, perhaps you have some ideas?