Re: Change the executing of a 0-byte file to be an error...

From: Ceri Davies (ceri_at_submonkey.net)
Date: 06/10/05

  • Next message: Roman Neuhauser: "Re: Bug in #! processing - "pear broken on current"" 
    Date: Fri, 10 Jun 2005 12:11:03 +0100
To: Garance A Drosihn <drosih@rpi.edu>

    On Fri, Jun 10, 2005 at 01:33:02AM -0400, Garance A Drosihn wrote:
    > A few months ago, I had a system panic happen right in the middle of
    > a 'installworld'. Right now I don't care about the panic itself
    > (IIRC, it was a hardware problem), but there was one unexpected
    > side-effect which caused me more trouble than the original panic.
    > And all that trouble boils down to the following:
    >
    > If a file is empty and executable, that empty file can be
    > executed without generating any error.
    >
    > The panic caused a few files in /usr/bin to end up as zero-byte
    > executable files, but I didn't realize that. I ended up doing
    > another buildworld, I think it was, and ended up digging myself
    > into a deeper and deeper hole. The problem included things like
    > makefile rules calling:
    >
    > somecmd | sort -blah | domore
    >
    > where the 'sort' command had turned into one of those zero-byte
    > executable files. The basic result was that the more I tried to
    > rebuild parts of the world, the more screwed up the system became.
    > By the time I was done, I had to do a clean install from CD-ROM
    > to get it back to working order.
    >
    > Can anyone think of a real-world problem that would come up if the
    > system was changed so that executing a 0-byte file would cause an
    > error? I read through a few likely pages in SUSv3, and it looked
    > like the behavior for executing an 0-byte file is not explicitly
    > defined. Of course, it might be that I was simply looking in the
    > wrong part of the standard.
    >
    > It does seem like empty files are also executed without error on a
    > few other OS's I tried, but I don't understand why that behavior
    > would be desirable.

    Are you sure? It seems to be a function of the shell more than
    anything; the transcript below does exactly the same on both FreeBSD
    4-STABLE and Solaris 8:

    $ sh
    $ PS1='sh$ '
    sh$ touch empty ; chmod +x empty
    sh$ ./empty
    sh$ echo $?
    0
    sh$ PS1='zsh$ ' zsh
    zsh$ zsh
    zsh$ ./empty
    zsh: exec format error: ./empty
    zsh$

    Ceri 

    -- 
Only two things are infinite, the universe and human stupidity, and I'm
not sure about the former.			  -- Einstein (attrib.)

  • Next message: Roman Neuhauser: "Re: Bug in #! processing - "pear broken on current""

    Relevant Pages

    • Re: Re-post: Yet another problem with "no current record"
      ... The Else block won't exeucte if the If block is executing. ... query directly from the Database window. ... I have a form with 4 unbound text boxes and a button. ... to empty out the form of rows so the user can start over. ...
      (microsoft.public.access.formscoding)
    • Re: zcat group of files in reverse order?
      ... a confusing error from zcat) ... or if you have zsh: ... If the directory is empty, you'll get the correct error from ...
      (comp.unix.shell)
    • Re: ASP "IF" Problem
      ... I do have a response.write Post_comment line and the result is empty Also ... statement is not executing correctly, ... so knew I did have values to compare in IF statement. ... >> trying to compare a number to a string. ...
      (microsoft.public.frontpage.client)
    • Re: Would a car have veered in this situation? Sharply?
      ... In article, Fod ... executing a manouvre. ... With the speed differential he would have observed a long piece of empty ...
      (uk.transport)
    • Re: [bash] the <<<$DATA issue
      ... Except for the case when file is empty. ... zsh), stores "xxx" followed by a NL character into a temporary ... # doesn't contain NUL bytes (except for zsh that supports NUL ...
      (comp.unix.shell)