Need Simple Way To Determine If File Is Executable

[Tim Daneliuk]

I have a program wherein I want one behavior when a file is set as executable
and a different behavior if it is not. Is there a simple way to determine
whether a given named file is executable that does not resort to all the
lowlevel ugliness of os.stat() AND that is portable across Win32 and *nix?

Thanks,

 

[John McMonagle]

I have a program wherein I want one behavior when a file is set as executable
and a different behavior if it is not. Is there a simple way to determine
whether a given named file is executable that does not resort to all the
lowlevel ugliness of os.stat() AND that is portable across Win32 and *nix?

os.access(pathToFile, os.X_OK)

 

[Gabriel Genellina]

os.access(pathToFile, os.X_OK)

That won't work on Windows.

You have to define what do you mean by "a file is set as executable"
on Windows.
a.exe is executable and nobody would discuss that. I can supress the
extension and type simply: a, on the command line, and get a.exe
executed. Same for a.com
What about a.bat? cmd.exe is executed and runs the batch file. I can
even omit the extension. Is a.bat executable then?
What about a.py? Another process starts and handles the file
(python.exe). Is a.py executable then?
I can type a.mdb on the command prompt and launch an Access
application. Is a.mdb executable then?
If I type a.doc on the command prompt, Word is executed and opens
that file. Is a.doc executable then?

The answer may be so narrow to just consider .exe .com and a few
more, or so broad to consider all things that os.startfile can handle
without error.


--
Gabriel Genellina
Softlab SRL

__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar

 

[Tim Golden]

[Tim Daneliuk]

I have a program wherein I want one behavior when a file is
set as executable and a different behavior if it is not. Is
there a simple way to determine whether a given named file is
executable that does not resort to all the lowlevel ugliness
of os.stat() AND that is portable across Win32 and *nix?

I'm fairly certain the answer is no. What follows is a
relatively low-level and certainly not portable discussion.

The last couple of times this question came up on the list
I looked into the implementation and experimented a bit
but in short I would say that os.stat / os.access were
near enough useless for determining executablility under
Windows. That's not down to Python as such; it's simply
passing back what the crt offers.

Of course that raises the slightly wider issue of: should
the Python libs do more than simply call the underlying
crt especially when that's known to give, perhaps misleading
results? But I'm in no position to answer that.

I suggest that for Windows, you either use the PATHEXT
env var and determine whether a given file ends with
one of its components. Or -- and this depends on your
definition of executable under Windows -- use the
FindExecutable win32 API call (exposed in the win32api
module of pywin32 and available via ctypes) which will
return the "executable" for anything which has an
association defined. So the "executable" for a Word
doc is the winword.exe program. The "executable" for
an .exe is itself.

TJG

 

[Tim Daneliuk]

[Tim Daneliuk]

I have a program wherein I want one behavior when a file is
set as executable and a different behavior if it is not. Is
there a simple way to determine whether a given named file is
executable that does not resort to all the lowlevel ugliness
of os.stat() AND that is portable across Win32 and *nix?

I'm fairly certain the answer is no. What follows is a
relatively low-level and certainly not portable discussion.

The last couple of times this question came up on the list
I looked into the implementation and experimented a bit
but in short I would say that os.stat / os.access were
near enough useless for determining executablility under
Windows. That's not down to Python as such; it's simply
passing back what the crt offers.

Of course that raises the slightly wider issue of: should
the Python libs do more than simply call the underlying
crt especially when that's known to give, perhaps misleading
results? But I'm in no position to answer that.

I suggest that for Windows, you either use the PATHEXT
env var and determine whether a given file ends with
one of its components. Or -- and this depends on your
definition of executable under Windows -- use the
FindExecutable win32 API call (exposed in the win32api
module of pywin32 and available via ctypes) which will
return the "executable" for anything which has an
association defined. So the "executable" for a Word
doc is the winword.exe program. The "executable" for
an .exe is itself.

TJG

This seems to work, at least approximately:

os.stat(selected)[ST_MODE] & (S_IXUSR|S_IXGRP|S_IXOTH

It probably does not catch every single instance of something
that could be considered "executable" because this is a sort
of fluid thing in Windows (as you point out).

 

[Tim Roberts]

This seems to work, at least approximately:

os.stat(selected)[ST_MODE] & (S_IXUSR|S_IXGRP|S_IXOTH

It probably does not catch every single instance of something
that could be considered "executable" because this is a sort
of fluid thing in Windows (as you point out).

This will tell you that "x.exe" is executable, even if "x.exe" contains
nothing but zeros.

On the other hand, I'm not convinced that any other solution is better.

 

[Gabriel Genellina]

os.stat(selected)[ST_MODE] & (S_IXUSR|S_IXGRP|S_IXOTH

This will tell you that "x.exe" is executable, even if "x.exe" contains
nothing but zeros.

Isn't the same with any other recipe, portable or not? Unless the OS
actually tries to load and examine the file contents, which the OS's
I'm aware of, don't do.

 

[Tim Roberts]

os.stat(selected)[ST_MODE] & (S_IXUSR|S_IXGRP|S_IXOTH

This will tell you that "x.exe" is executable, even if "x.exe" contains
nothing but zeros.

Isn't the same with any other recipe, portable or not? Unless the OS
actually tries to load and examine the file contents, which the OS's
I'm aware of, don't do.

Yes, of course, you're right. I was about to delve into a philosophical
discussion about the difference in handling this between Linux and Windows,
but they're both just conventions. One is based on an arbitrary flag, one
is based on a file extension. Contents are irrelevant.

 

[Roger Upole]

os.stat(selected)[ST_MODE] & (S_IXUSR|S_IXGRP|S_IXOTH

This will tell you that "x.exe" is executable, even if "x.exe" contains
nothing but zeros.

Isn't the same with any other recipe, portable or not? Unless the OS
actually tries to load and examine the file contents, which the OS's
I'm aware of, don't do.

On windows, you can use win32file.GetBinaryType to check if a file is actually
a binary executable.

Roger

 

[Tim Daneliuk]

os.stat(selected)[ST_MODE] & (S_IXUSR|S_IXGRP|S_IXOTH
This will tell you that "x.exe" is executable, even if "x.exe" contains
nothing but zeros.

Isn't the same with any other recipe, portable or not? Unless the OS
actually tries to load and examine the file contents, which the OS's
I'm aware of, don't do.

On windows, you can use win32file.GetBinaryType to check if a file is actually
a binary executable.

Roger

Yabut ... what about things like batch files? Does it return them
as executable as well?

 

[Roger Upole]

os.stat(selected)[ST_MODE] & (S_IXUSR|S_IXGRP|S_IXOTH
This will tell you that "x.exe" is executable, even if "x.exe" contains
nothing but zeros.
Isn't the same with any other recipe, portable or not? Unless the OS
actually tries to load and examine the file contents, which the OS's
I'm aware of, don't do.

On windows, you can use win32file.GetBinaryType to check if a file is actually
a binary executable.

Roger

Yabut ... what about things like batch files? Does it return them
as executable as well?

No, it's strictly for binary executables.

Roger

 

[Gabriel Genellina]

os.stat(selected)[ST_MODE] & (S_IXUSR|S_IXGRP|S_IXOTH
This will tell you that "x.exe" is executable, even if "x.exe" contains
nothing but zeros.

Isn't the same with any other recipe, portable or not? Unless the OS
actually tries to load and examine the file contents, which the OS's
I'm aware of, don't do.

On windows, you can use win32file.GetBinaryType to check if a file is actually
a binary executable.

A similar function exists on Linux too. But even if a file has the
right file format, if it does not have the execute bit set, won't run.
And you could set that bit on a JPG image too - and nothing good would
happen, I presume. So one must determine first what means "the file is
executable".

 

[Tim Daneliuk]

os.stat(selected)[ST_MODE] & (S_IXUSR|S_IXGRP|S_IXOTH
This will tell you that "x.exe" is executable, even if "x.exe" contains
nothing but zeros.
Isn't the same with any other recipe, portable or not? Unless the OS
actually tries to load and examine the file contents, which the OS's
I'm aware of, don't do.

On windows, you can use win32file.GetBinaryType to check if a file is actually
a binary executable.

A similar function exists on Linux too. But even if a file has the
right file format, if it does not have the execute bit set, won't run.
And you could set that bit on a JPG image too - and nothing good would
happen, I presume. So one must determine first what means "the file is
executable".

Well... sure, but that isn't the point. Here is the problem I was
trying to solve:

I wrote and maintain the 'twander' cross-platform file browser:

http://www.tundraware.com/Software/twander/

I was working on a new release and wanted to add file associations
to it. That is, if the user selected a file and double clicked or
pressed Enter, I wanted the following behavior (in the following
steps, "type" means nothing more than "a file whose name ends with
a particular string"):

1) If an association for that file type exists, run the associated program.

2) If an association for that file type does not exist:

a) If the file is not "executable", see if there is a "default"
association defined and run that program if there is.

b) If the file *is* "executable", run it.


So ... all I really needed to know is whether or not the OS thinks the
file is executable. Obvious - and this is true on most any system -
you can create the situation where the file appear executable from
the OS's point of view, but it is not actually. But this is a pathology
that no application should really be expected to cope with...

 

[Gabriel Genellina]

I was working on a new release and wanted to add file associations
to it. That is, if the user selected a file and double clicked or
pressed Enter, I wanted the following behavior (in the following
steps, "type" means nothing more than "a file whose name ends with
a particular string"):

1) If an association for that file type exists, run the associated program.

2) If an association for that file type does not exist:

a) If the file is not "executable", see if there is a "default"
association defined and run that program if there is.

b) If the file *is* "executable", run it.

This is what os.startfile does. The underlying Win32 functions would
be ShellExecute, FindExecutable & their variants.
Will you maintain your own registry for associations?


--
Gabriel Genellina
Softlab SRL

__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar

 

[Tim Daneliuk]

This is what os.startfile does. The underlying Win32 functions would be

And on Windows, that's exactly what I use.

ShellExecute, FindExecutable & their variants.
Will you maintain your own registry for associations?

Yes, because I want common configuration syntax and runtime
semantics across FreeBSD, Linux, Windows, et al. The only
semantic difference is that, on Windows, if my own association
is not found, then the Windows association will apply. This
cannot be done in the *nix environment - at least not easily -
because there is no common association repository across the
various window managers, nor is there a startfile() type
call in the POSIX world.


This is implemented already and largely works as planned.
There are a few subtleties I want to work into the next
release, but things work as expected today...

 

[Sebastian 'lunar' Wiesner]

os.stat(selected)[ST_MODE] & (S_IXUSR|S_IXGRP|S_IXOTH

This will tell you that "x.exe" is executable, even if "x.exe"
contains
nothing but zeros.

Isn't the same with any other recipe, portable or not? Unless the
OS actually tries to load and examine the file contents, which the
OS's I'm aware of, don't do.

On windows, you can use win32file.GetBinaryType to check if a file is
actually a binary executable.

A similar function exists on Linux too. But even if a file has the
right file format, if it does not have the execute bit set, won't run.
And you could set that bit on a JPG image too - and nothing good would
happen, I presume.

Really? I don't think so. Afaik on Linux executable binary files need an
ELF header.

[lunar@nargond]-[10:15:43] >> ~/Bilder
--> chmod a+x VM-Background.png

[lunar@nargond]-[10:15:46] >> ~/Bilder
--> ./VM-Background.png
bash: ./VM-Background.png: cannot execute binary file

As you can see, binary files without such a header are not executed...

Bye
lunar

 

[Sebastian 'lunar' Wiesner]

os.stat(selected)[ST_MODE] & (S_IXUSR|S_IXGRP|S_IXOTH

This will tell you that "x.exe" is executable, even if "x.exe"
contains
nothing but zeros.

Isn't the same with any other recipe, portable or not? Unless the OS
actually tries to load and examine the file contents, which the OS's
I'm aware of, don't do.

Yes, of course, you're right. I was about to delve into a
philosophical discussion about the difference in handling this between
Linux and Windows, but they're both just conventions. One is based on
an arbitrary flag, one is based on a file extension. Contents are
irrelevant.

No, they aren't! Try this:

[lunar@nargond]-[10:24:44] >> ~/test
--> dd if=/dev/zero of=test.sh count=1
1+0 records in
1+0 records out
512 bytes (512 B) copied, 6.5e-05 seconds, 7.9 MB/s

[lunar@nargond]-[10:24:46] >> ~/test
--> chmod a+x test.sh

[lunar@nargond]-[10:24:55] >> ~/test
--> ./test.sh
bash: ./test.sh: cannot execute binary file

A file containing only zeros isn't executed...

 

[Fredrik Lundh]

No, they aren't! Try this:

you're confusing the shell's "is this file executable" check with the
loader's "can I execute this file" check:

$ export PATH=.:$PATH
$ dd if=/dev/zero of=ls count=1
1+0 records in
1+0 records out
$ ls -l ls
-rw-rw-r-- 1 slab slab 512 Dec 20 03:33 ls
$ chmod a+x ls
$ ls
-bash: ./ls: cannot execute binary file

</F>

 

[Sebastian 'lunar' Wiesner]

you're confusing the shell's "is this file executable" check with the
loader's "can I execute this file" check:

$ export PATH=.:$PATH
$ dd if=/dev/zero of=ls count=1
1+0 records in
1+0 records out
$ ls -l ls
-rw-rw-r-- 1 slab slab 512 Dec 20 03:33 ls
$ chmod a+x ls
$ ls
-bash: ./ls: cannot execute binary file

???
Am I blind or is there really no difference between you shell example an
mine?
As far as I can see, you are doing exactly the same thing as I did...
So what are trying to proof?

Sebastian

 

[Marc 'BlackJack' Rintsch]

Really? I don't think so. Afaik on Linux executable binary files need an
ELF header.

There are other executable loaders for `a.out` and `COFF` in the kernel,
and with the `binfmt_misc` module you can make anything with a "magic"
header executable, including Python scripts/bytecode and even JPEG images.

http://www.tat.physik.uni-tuebingen.de/~rguenth/linux/binfmt_misc.html

Ciao,
Marc 'BlackJack' Rintsch