|
Home > Archive > Unix Programming > January 2004 > how to tell if a file is inary file or ascii file?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
how to tell if a file is inary file or ascii file?
|
|
|
| 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
| |
| Tobias Oed 2004-01-23, 5:35 pm |
| 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
| |
| Barry Margolin 2004-01-23, 5:35 pm |
| 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
| |
| Kurtis D. Rader 2004-01-23, 5:35 pm |
| 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.
| |
|
| 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
| |
|
| 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
| |
| Web Surfer 2004-01-23, 5:35 pm |
| [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
| |
| Mohun Biswas 2004-01-23, 5:35 pm |
| 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
| |
|
| >[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 ...
| |
| Kurtis D. Rader 2004-01-23, 5:35 pm |
| 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.
| |
| Ralf Fassel 2004-01-23, 5:36 pm |
| * "Kurtis D. Rader" <krader@skepticism.us>
| 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.
Which shell are you referring to? Many (most?) of my shell scripts
rely on the fact that everything done in the script has no effect to
the shell where I typed the command (i.e. change directories, altering
the environment etc). So I would be very surprised if the command
line shell was affected by the scripts I invoke.
R'
| |
| Barry Margolin 2004-01-23, 5:36 pm |
| In article <ygabrp4jluz.fsf@ozelot.akutech-local.de>,
Ralf Fassel <ralfixx@gmx.de> wrote:
quote:
> * "Kurtis D. Rader" <krader@skepticism.us>
> | 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.
>
> Which shell are you referring to? Many (most?) of my shell scripts
> rely on the fact that everything done in the script has no effect to
> the shell where I typed the command (i.e. change directories, altering
> the environment etc). So I would be very surprised if the command
> line shell was affected by the scripts I invoke.
This was the way that shell scripts were first implemented; recognizing
"#!" in the kernel was a later modification to the OS. What actually
happens is that the shell forks and calls exec(); if exec() returns with
an error that indicates that the file wasn't in a format that it
understands (which originally was just binary executables, but now
includes files beginning with "#!"), the shell tries to interpret it
itself. It's still in the forked child process, so the original shell
process is not affected by it.
The shell may also do some special recognition of the file format. In
particular, csh looks for "!" as the first character and will exec
/bin/sh to execute it. ! is the Bourne Shell no-op command, and this
was used in the pre-#! days as a way for csh users to execute Bourne
scripts (this "!" is what eventually evolved into the shebang).
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
| |
| Mohun Biswas 2004-01-23, 5:36 pm |
| Barry Margolin wrote:quote:
> The shell may also do some special recognition of the file format. In
> particular, csh looks for "!" as the first character and will exec
> /bin/sh to execute it. ! is the Bourne Shell no-op command, and this
> was used in the pre-#! days as a way for csh users to execute Bourne
> scripts (this "!" is what eventually evolved into the shebang).
Nice exposition, but I think you meant ':' instead of '!':
% !
!: not found
-MB
| |
| Barry Margolin 2004-01-23, 5:36 pm |
| In article <WVWNb.80617$8H.116458@attbi_s03>,
Mohun Biswas <m.biswas@invalid.addr> wrote:
quote:
> Barry Margolin wrote:
>
> Nice exposition, but I think you meant ':' instead of '!':
Yes. I knew when I was writing that post that something didn't seem
quite right. 
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
|
|
|
|
|