Re: Script Header

From: Alexander Mueller (postmaster_at_127.0.0.1)
Date: 12/28/04 

Date: Tue, 28 Dec 2004 19:14:47 GMT

Bruce Barnett wrote:
>
> Yes.
> do a
> od -b executable | head
>
> On a shell script, I get
>
> 0000000 043 041 ..............
>
> The first number is the byte count, and the next two are octal values.
>
>
> while on an executable, I get
>
> 0000000 177 105
>
> On old Unix systems (not on this Linux system), there was a man page on
> a.out that described the binary formats.
> The proper binary code depends on the hardware.
>
>
> You can TRY to execute a garbage file.
> The OS will complain
>
> filename: Exec format error. Binary file not executable.
>
> It's a little tricker when you deal with a data file. A *.txt file
> isn't executable. The OS has to know what program is used to process
> this file. Mac, Unix and WIndows have different mechanisms. So when
> you tell it to process a text file, it has to figure out how to do
> this. This is when extensions are useful. Unix also has the "file"
> command to try to guess the file type. But this can be fooled.

Thanks Bruce. According to this, I would assume the execution process
works in the following way.

  - The user attempts to execute a file

  - The shell will check whether this file has the executable flag set,
if not it will fail

  - Otherwise it will pass the name to the exec() function

  - Now the system tries to determine whether the file is a script or a
binary exectuable, based upon the first two bytes "magic code"

  - If these "magic code" consists of the two ascii values 35 and 33
("#!") it is reconised as script and the exec() function tries to
determine the target interpreter by parsing the first line

  - Otherwise, if the "magic code" represents a (support) binary
executable, the file itself will be executed by the particular loader.

So far I would have understood it. Although I have to admit that I do
not consider this solution as a rather dirty workaround for a sole
script convenience, but this is another story.

However what makes me wonder is, if I change the script header to
something different (eg: "@!/bin/bash"), I will get an error message
telling me that my CURRENT shell cant execute this file. But where does
my current shell suddenly come in? Who tells it to actually execute this
file? Is the shell actually already parsing the file before it hands it
off to exec() or is exec() doing a callback to the current shell upon an
unknown "magic code"?

I am aware that this might be already a bit off topic for a shell group,
but I dont know which other group would be most appropriate. So please
do a follow-up if necessary.

Thanks again,
Alexander

Relevant Pages

  • Re: detect shell script language
    ... In the 'old' days, when a user typed in a command, the interactive shell would immediately pass it off to 'exec' to execute. ... So, on return from exec with an error status, the shell would fork a copy of itself to try and run the script. ... As a result of the above, it was hard to tell whether the script was a Bourne shell or C shell, so the convention was introduced of using the Bourne shell no op command, as the first line in a Bourne shell script. ...
    (Debian-User)
  • Re: shell scripting
    ... and am assuming an sh-compatible shell here.... ... command 1 options arguments ... To run the script, do: ... then you need to use the full path to execute it: ...
    (comp.unix.questions)
  • Re: shell scripting
    ... and am assuming an sh-compatible shell here.... ... command 1 options arguments ... To run the script, do: ... then you need to use the full path to execute it: ...
    (comp.unix.shell)
  • Re: Executing other TCL - Scripts in the background
    ... > regularly when I execute it in normal executable Unix - Scripts. ... % exec ls NONEXT ... error message from the VTK script. ... Reaffirming my suspicion that it's the environment the VTK script is ...
    (comp.lang.tcl)
  • Re: newbie question: cant get script to execute
    ... I saved this in a script "process.bsh". ... The typical name for a shell script it .sh, and this is not a shell ... > I chmod to 777 and still get "cannot execute". ... the error message is distinct and far ...
    (comp.lang.perl.misc)