Hello,

Is there a way to find if a file is a binary executable file or an ASCII
executable file in unix? especially, if I have a file with
permission of --x--x--x.

Thanks,

Peter

[ Post a follow-up to this message ]

peter wrote:
quote:

> Hello,
>
> Is there a way to find if a file is a binary executable file or an ASCII
> executable file in unix? especially, if I have a file with
>   permission of --x--x--x.


If in a shell you could start with man file
Tobias

[ Post a follow-up to this message ]

In article <zu4Nb.9619$QP.4822@newssvr27.news.prodigy.com>,
peter <one2001boy@yahoo.com> wrote:
quote:

> Hello,
>
> Is there a way to find if a file is a binary executable file or an ASCII
> executable file in unix? especially, if I have a file with
>   permission of --x--x--x.


If you don't have read permission, there's no way to tell what's in it.

Note that most Unix implementations can't run execute-only scripts; the
interpreter has to be able to read the file.  So something with those
permissions would normally have to be a binary executable.  I think
Solaris is an exception to this; it makes use of /dev/fd to provide a
way for the interpreter to read the file (it uses the same trick to
implement setuid scripts without the symlink security hole).

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA

[ Post a follow-up to this message ]

On Wed, 14 Jan 2004 05:31:11 +0000, peter wrote:
quote:

> Is there a way to find if a file is a binary executable file or an ASCII
> executable file in unix? especially, if I have a file with
>   permission of --x--x--x.


This is non-trivial for the general case. An acceptable solution may be to
look at the first two bytes of the file. If  they are "#!" then it's a
script of some sort, otherwise assume it's a binary. Of course this simple
test fails for any number of cases. For example, a shell script may not
begin with the "#!" signature. If the file begins with a ":" some shells
may assume it's a Bourne shell script. There are other variations on that
theme but in my experience they're rare.

[ Post a follow-up to this message ]

Barry Margolin wrote:
quote:

> In article <zu4Nb.9619$QP.4822@newssvr27.news.prodigy.com>,
>  peter <one2001boy@yahoo.com> wrote:
>
> 
>
>
> If you don't have read permission, there's no way to tell what's in it.
>
> Note that most Unix implementations can't run execute-only scripts; the
> interpreter has to be able to read the file.  So something with those
> permissions would normally have to be a binary executable.  I think
> Solaris is an exception to this; it makes use of /dev/fd to provide a
> way for the interpreter to read the file (it uses the same trick to
> implement setuid scripts without the symlink security hole).
>


Thanks for your help. Barry. Unix shell are unable
to run the unix shell scripts with permission of --x--x--x, but the
binary file with permission --x--x--x can be executed. not sure how the
unix shell can tell the differences.

Peter

[ Post a follow-up to this message ]

Kurtis D. Rader wrote:
quote:

> On Wed, 14 Jan 2004 05:31:11 +0000, peter wrote:
>
> 
>
>
> This is non-trivial for the general case. An acceptable solution may be to
> look at the first two bytes of the file. If  they are "#!" then it's a
> script of some sort, otherwise assume it's a binary. Of course this simple
> test fails for any number of cases. For example, a shell script may not
> begin with the "#!" signature. If the file begins with a ":" some shells
> may assume it's a Bourne shell script. There are other variations on that
> theme but in my experience they're rare.


for the file permission --x--x--x, you are unable to read the first two
bytes. typically, I assume such a file was sent to system() to run it in
a unix shell, but if the file is a shell script and not binary
application, how unix shell can know it in advance and gives an error
message such as "permission denied".

Thanks,

peter

[ Post a follow-up to this message ]

[This followup was posted to comp.unix.programmer]

In article <zu4Nb.9619$QP.4822@newssvr27.news.prodigy.com>,
one2001boy@yahoo.com says...
quote:

> Hello,
>
> Is there a way to find if a file is a binary executable file or an ASCII
> executable file in unix? especially, if I have a file with
>   permission of --x--x--x.
>
> Thanks,
>
> Peter


You could use the command "file"

file foo.sh

[ Post a follow-up to this message ]

peter wrote:
quote:

> Thanks for your help. Barry. Unix shell are unable
> to run the unix shell scripts with permission of --x--x--x, but the
> binary file with permission --x--x--x can be executed. not sure how the
> unix shell can tell the differences.


That's because you have it backward. The invoking shell simply runs
exec() on the file without knowing or caring what's in it. The kernel
(which can do whatever it wants) then decides whether to map it directly
as a process or hand it to an interpreter. In the event it goes to an
interpreter and the interpreter can't open it, that program (which may
be a shell or anything else but is not the original, invoking shell)
will fail.

MB

[ Post a follow-up to this message ]

>[This followup was posted to comp.unix.programmer]
quote:

>
>In article <zu4Nb.9619$QP.4822@newssvr27.news.prodigy.com>,
>one2001boy@yahoo.com says... 
>
>You could use the command "file"
>
>    file foo.sh
>

if you had the read bit set ...

[ Post a follow-up to this message ]

On Wed, 14 Jan 2004 07:20:00 +0000, peter wrote:
quote:

> for the file permission --x--x--x, you are unable to read the first two
> bytes.


You're correct. I should have stated explicitly that I was responding to
the more typical case where you do have read access.
quote:

> typically, I assume such a file was sent to system() to run it in a unix
> shell, but if the file is a shell script and not binary application, how
> unix shell can know it in advance and gives an error message such as
> "permission denied".


Shells as a rule do not use system(), they use exec() (or variant such as
execve()). The kernel will open the file if the user credentials allow it
to do so. It will then examine the contents to determine whether it is a
program in a binary format (e.g., COFF or ELF) that it can execute
directly or whether it needs to spawn a "shell" process to read and
interpret the contents of the file. If the user is not allowed to execute
the file it will return EACCES or EPERM. It can return many other errors
as well. It's the caller's responsibility to emit an appropriate error
message.

Some shells will attempt to open and read the file as an optimization. If
they recognize the file as a script they can interpret they may do so
directly rather than calling upon the fork() and exec() functions to spawn
the appropriate interpreter.

[ Post a follow-up to this message ]