Date: Fri, 7 Feb 2003 23:42:19 GMT
From: abc AT anchorageinternet DOT org
Message-Id: <200302072342.h17NgJsB001895@en26.groggy.anc.acsalaska.net>
X-Authentication-Warning: en26.groggy.anc.acsalaska.net: abc set sender to abc AT anchorageinternet DOT org using -f
Subject: Re: Report a Bug (#! bash bug)
X-Mailer: Umail v2.9.2
To: <djgpp AT delorie DOT com>
Reply-To: djgpp AT delorie DOT com

> > i respectfully disagree with you in practical terms, in
> > terms of compatibility, and in terms of the bash man page.
> >
> > it is not compatible with RH Linux/FreeBSD, whether using
> > bash, or standard sh.  and it is breaking many things for me.
> >
> > it doesn't make much sense for it to be as it is in DJGPP.
> > of course you should be able to pass a script an option.
> > who would argue with that ...
> >
> > BASH(1): If the program is a file beginning with #!, the  remainder
> >        of  the  first  line specifies an interpreter for the pro-
> >        gram.  The shell executes  the  specified  interpreter  on
> >        operating  systems that do not handle this executable for-
> >        mat themselves.  The arguments to the interpreter[1] consist
> >        of  a  single  optional argument[2] following the interpreter
> >        name on the first line of the  program,  followed  by  the
> >        name of the program[3], followed by the command arguments[4],
> >        if any.
> >
> >   1           2            3               4
> > #!INTERPRETER OPTIONAL-ARG NAME-OF-PROGRAM OPTIONAL-COMMAND-ARGUMENTS
> >   ----------- ------------ --------------- --------------------------
> > thus, what i am doing is within bash guidelines and should work
> > and should be acceptable practice.  if you still disagree, i would
> > like to see the standards you reference - to enlighten myself.
> > i admit i may be wrong, but i don't see it yet.  i do not
> > know of any references that demand "single argument" treatment.
> >
> > thank you for your work, it's greatly valued!
> >
> > > >      /path/to/sh/script option:  /path/to/sh/script option:  no such
> > > >      file or directory (ENOENT)
> > >
> > > This is correct.  According to the standards, the text after the
> > > #!/bin/bash is NOT parsed, but treated as a single argument.