This is the mail archive of the
mailing list for the Cygwin project.
Re: behaviour of "for (( exp1; exp2; exp3 )); do COMMANDS; done"
At 03:17 2003-05-28, Sam Edge wrote:
Stuart Brady <email@example.com> wrote in
in gmane.os.cygwin on Tue, 27 May 2003 13:07:18 +0100:
> On Tue, May 27, 2003 at 12:42:21PM +0100, Sam Edge wrote:
> > Make sure that if your script uses Bash-specific features, it starts
> > with #!/bin/bash and not with #!/bin/sh. That way it'll work anywhere.
> You've made the assumption that bash is always in /bin. I've seen it
> in /bin, /usr/bin, /usr/local/bin, /usr/contrib/bin, and /opt/bash/bin.
> ~/bin would be another likely place for it.
I just _knew_ I shouldn't have said "anywhere." ;-)
Unfortunately this is a general weakness in the "#!/xxxx" syntax.
(OT) Does anyone know if any of the common shells, when they see
"#!/bin/xxxx" at the front of a script, try a $PATH search for an
"xxxx" executable if they can't find "/bin/xxxx"? This would seem like
a good idea to me.
The interpretation of #! lines is in the kernel (or, hereabout,
Cygwin1.dll, a kernel by any other name), just as the kernel would how
to handle a binary executable by examining its header.
However, shells usually fall back to interpreting script if the kernel
reports particular errors on the exec(2) system call (ENOEXEC, i.e.).
When this happens, the shell knows that the file exists, that the
permissions allow execution but the kernel could not execute the file
because its format was not suitable. Then the shell will try to
interpret the script as one of its own. (That, by the way, causes some
odd errors when foreign executables are brought to Cygwin and executed.
Cygwin1.dll and / or Windows cannot execute these so the shell starts
interpreting a binary file as commands. Shell syntax errors ensue.)
So the shells could be modified to do what you suggest, but if there
are any that do it now, I don't know of them, but I really only know
much about BASH these days.
I seem to recall some discussion way back when as Berkeley Unix
introduced this feature about PATH searching for #! executions being a
possible security hole. To my knowledge, no Unix does this, but again,
I claim no extensive knowledge of the current state of affairs.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html