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,
----------------------------------------------------------------------------
Tim Daneliuk tu****@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

[John McMonagle]

Tim Daneliuk wrote:

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)

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

[Gabriel Genellina]

At Thursday 14/12/2006 19:21, John McMonagle wrote:

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)

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 Golden wrote:

[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 Daneliuk tu****@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

[Tim Roberts]

Tim Daneliuk <tu****@tundraware.comwrote:

>
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.
--
Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.

[Gabriel Genellina]

On 16 dic, 04:47, Tim Roberts <[e-mail]:

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.

--
Gabriel Genellina

[Tim Roberts]

"Gabriel Genellina" <ga******@yahoo.com.arwrote:

>On 16 dic, 04:47, Tim Roberts <[e-mail]:

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.
--
Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.

[Roger Upole]

Gabriel Genellina wrote:

On 16 dic, 04:47, Tim Roberts <[e-mail]:

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.

--
Gabriel Genellina

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

Roger


----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Tim Daneliuk]

Roger Upole wrote:

Gabriel Genellina wrote:

>On 16 dic, 04:47, Tim Roberts <[e-mail]:

>>> 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.

--
Gabriel Genellina

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?
--
----------------------------------------------------------------------------
Tim Daneliuk tu****@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

[Roger Upole]

Tim Daneliuk wrote:

Roger Upole wrote:

>Gabriel Genellina wrote:

>>On 16 dic, 04:47, Tim Roberts <[e-mail]:
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.

--
Gabriel Genellina

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

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Gabriel Genellina]

On 17 dic, 19:21, "Roger Upole" <[e-mail]:

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".

--
Gabriel Genellina

[Tim Daneliuk]

Gabriel Genellina wrote:

On 17 dic, 19:21, "Roger Upole" <[e-mail]:

>>>> 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...

--
----------------------------------------------------------------------------
Tim Daneliuk tu****@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

[Gabriel Genellina]

At Monday 18/12/2006 13:41, Tim Daneliuk wrote:

>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]

Gabriel Genellina wrote:

At Monday 18/12/2006 13:41, Tim Daneliuk wrote:

>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

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...

--
----------------------------------------------------------------------------
Tim Daneliuk tu****@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

[Sebastian 'lunar' Wiesner]

Gabriel Genellina <ga******@yahoo.com.arschrieb

On 17 dic, 19:21, "Roger Upole" <[e-mail]:

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

--
Freedom is always the freedom of dissenters.
(Rosa Luxemburg)

[Sebastian 'lunar' Wiesner]

Tim Roberts <ti**@probo.comschrieb

"Gabriel Genellina" <ga******@yahoo.com.arwrote:

>>On 16 dic, 04:47, Tim Roberts <[e-mail]:

> 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...

--
Freedom is always the freedom of dissenters.
(Rosa Luxemburg)

[Fredrik Lundh]

Sebastian 'lunar' Wiesner wrote:

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]

Fredrik Lundh <fr*****@pythonware.comschrieb

Sebastian 'lunar' Wiesner wrote:

>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

???
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

--
Freedom is always the freedom of dissenters.
(Rosa Luxemburg)

[Marc 'BlackJack' Rintsch]

In <em*************@news.t-online.com>, Sebastian 'lunar' Wiesner wrote:

Gabriel Genellina <ga******@yahoo.com.arschrieb

>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.

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....nfmt_misc.html

Ciao,
Marc 'BlackJack' Rintsch

[Sebastian 'lunar' Wiesner]

Marc 'BlackJack' Rintsch <bj****@gmx.netschrieb

In <em*************@news.t-online.com>, Sebastian 'lunar' Wiesner
wrote:

>Gabriel Genellina <ga******@yahoo.com.arschrieb

>>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.

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.

Yes, I know...
But ELF is actually the most common linker format on Linux systems.
a.out is a legacy format, that is afaik not used by any modern
distribution. Concerning COFF I'm not sure, if there is really a COFF
loader in the kernel. At least I did not find any information about
such a loader in the kernel configuration. It just lists elf, a.out and
binfmt_misc.

But basically you're right. One could even write a loader for JPEG
files.
But as long as such an loader is not part of a standard linux
distribution, nothing bad happens when you try to execute a JPEG file,
and that's what I wanted to point out.

Sebastian

--
Freedom is always the freedom of dissenters.
(Rosa Luxemburg)

[Fredrik Lundh]

Sebastian 'lunar' Wiesner wrote:

>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...

no, I'm showing that a local file marked as executable overrides a
shared one, even if the local file isn't actually an executable.

So what are trying to proof?

that you're wrong when you claim that the contents of the file matters
when using the usual Unix conventions to check if a file is executable.

maybe you should read Tim's post and the post he replied to again?

</F>

[Fredrik Lundh]

Paul Arthur wrote:

>no, I'm showing that a local file marked as executable overrides a
shared one, even if the local file isn't actually an executable.

Only if you have your system set up badly. The current directory should
not be in the search path, and it especially shouldn't have higher
priority than the regular bin locations.

and the award for completely missing the context of this subthread goes
to...

</F>

[Sebastian 'lunar' Wiesner]

Fredrik Lundh <fr*****@pythonware.comschrieb

Paul Arthur wrote:

>>no, I'm showing that a local file marked as executable overrides a
shared one, even if the local file isn't actually an executable.

Only if you have your system set up badly. The current directory
should not be in the search path, and it especially shouldn't have
higher priority than the regular bin locations.

and the award for completely missing the context of this subthread
goes to...

Nevertheless his comment was absolutely correct...

--
Freedom is always the freedom of dissenters.
(Rosa Luxemburg)

[Fredrik Lundh]

Sebastian 'lunar' Wiesner wrote:

>>>no, I'm showing that a local file marked as executable overrides a
shared one, even if the local file isn't actually an executable.

Only if you have your system set up badly. The current directory
should not be in the search path, and it especially shouldn't have
higher priority than the regular bin locations.

and the award for completely missing the context of this subthread
goes to...

Nevertheless his comment was absolutely correct...

nope. a Unix system uses the same flag to determine if a file is
executable no matter how I've set up my path.

</F>

[Sebastian 'lunar' Wiesner]

Fredrik Lundh <fr*****@pythonware.comschrieb

Sebastian 'lunar' Wiesner wrote:

>>>>no, I'm showing that a local file marked as executable overrides a
shared one, even if the local file isn't actually an executable.
>>>
Only if you have your system set up badly. The current directory
should not be in the search path, and it especially shouldn't have
higher priority than the regular bin locations.
>>
and the award for completely missing the context of this subthread
goes to...

Nevertheless his comment was absolutely correct...

nope. a Unix system uses the same flag to determine if a file is
executable no matter how I've set up my path.

Paul didn't even mention the word "executable". He was referring to
completely different thing: The fact, that whether a local executable
overrides a shared on, is matter of how you set your PATH. The local
file would be executable, whether it is in the PATH or not...

--
Freedom is always the freedom of dissenters.
(Rosa Luxemburg)

[Sebastian 'lunar' Wiesner]

Fredrik Lundh <fr*****@pythonware.comschrieb

Sebastian 'lunar' Wiesner wrote:

>>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...

no, I'm showing that a local file marked as executable overrides a
shared one, even if the local file isn't actually an executable.

Well, that doesn't tell us anything about, whether a file executable or
not.
But anyway: you admit, that the local file "ls" is __not__ actually
executable, although it has the x-bit set?

>So what are trying to proof?

that you're wrong when you claim that the contents of the file matters
when using the usual Unix conventions to check if a file is
executable.

Let me ask you a question:

[lunar@nargond]-[13:09:52] >~/test
--cat test.sh
#!/bin/bash

if [ "$1" ]; then
echo "Hello $1"
else
echo "Hello world"
fi

[lunar@nargond]-[13:09:54] >~/test
--ll test.sh
-rw-r--r-- 1 lunar lunar 76 2006-12-21 13:09 test.sh

Is test.sh now executable or not?

Bye
lunar

--
Freedom is always the freedom of dissenters.
(Rosa Luxemburg)

[Fredrik Lundh]

Sebastian 'lunar' Wiesner wrote:

>>>>>no, I'm showing that a local file marked as executable overrides a
>shared one, even if the local file isn't actually an executable.
>
Only if you have your system set up badly. The current directory
should not be in the search path, and it especially shouldn't have
higher priority than the regular bin locations.

and the award for completely missing the context of this subthread
goes to...

Nevertheless his comment was absolutely correct...

nope. a Unix system uses the same flag to determine if a file is
executable no matter how I've set up my path.

Paul didn't even mention the word "executable". He was referring to
completely different thing: The fact, that whether a local executable
overrides a shared on, is matter of how you set your PATH. The local
file would be executable, whether it is in the PATH or not...

are you trying to win some kind of award?

</F>

[Tim Roberts]

Sebastian 'lunar' Wiesner <ba***********@gmx.netwrote:

>
Fredrik Lundh <fr*****@pythonware.comschrieb

>Sebastian 'lunar' Wiesner wrote:

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

...
Well, that doesn't tell us anything about, whether a file executable or
not.
But anyway: you admit, that the local file "ls" is __not__ actually
executable, although it has the x-bit set?

Sebastian, you really have missed the point of this thread. The original
question was "how can I find out if a file is executable". The answer
involved calling stat. On a Linux system, using stat, the definition of
"executable" is "has the x mode bit set". On a Windows system, using stat,
the definition is "has an extension that is in PATHEXT". Nothing more,
nothing less. In both cases, the contents of the file are irrelevant.

Now, when you, as a human being, try answer the question "is this file
executable", you would use more sophisticated criteria that looked at the
first bytes of the file, but that's not the question here.
--
Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.