Re: spaces in the shebang interpreter path
Paul Jarc
> I'm not able to specify an interpreter in a shebang line if the path
> to this interpreter contains spaces.
It's actually the kernel that interprets that line, not bash. The
historical behavior is that space separates the interpreter from an
optional argument, and there is no escape mechanism, so there's no way
to specify an interpreter with a space in the path. It's unlikely
that this would ever change, since that would break existing scripts
that rely on thecurrent behavior.
paul
Bob Proulx
> I'm not able to specify an interpreter in a shebang line if the path
> to this interpreter contains spaces.
That is correct. It is part of the implementation of the Berkeley #!
exec(2) hack and as such is now simply the way things are and have
been for many years.
Here is a now somewhat dated explanation of this from decades ago:
http://www.faqs.org/faqs/unix-faq/faq/part3/section-16.html
Here is a pointer to the current online standards documentation:
http://www.opengroup.org/onlinepubs/009695399/functions/exec.html
I think the HP-UX man page does the best job of describing this:
http://www.informatik.uni-frankfurt.de/doc/man/hpux/exec.2.html
HP-UX Release 9.0: August 1992
The initial line of a script file must begin with #! as the
first two bytes, followed by zero or more spaces, followed by
interpreter or interpreter argument. One or more spaces or tabs
must separate interpreter and argument. The first line should
end with either a new-line or null character.
#! interpreter
#! interpreter argument
> I'm not quite sure if this is considered a bug or if its
> just there for backwards compatibility but at least quoting
> etc. does not work for me.
The "#! interpreter argument" is what is known as the Berkeley exec
hack. As described in the first faq referenced above it was a simple
way to enable script interpreters and doesn't handle non-traditional
filenames. This has been in existence for so many years (decades!)
that this is unlikely to change now.
> IMHO bash should support every valid unix path for shebang lines.
This is part of the exec(2) kernel system call interface and is not
part of bash. Bash doesn't have anything to do with the "#!" line.
The # is a comment character and bash sees that line as a comment.
Bob
Patient asks: "Doctor, doctor, it hurts when I use spaces in filenames."
Doctor responds: "... then don't use spaces in filenames."
Stephane Chazelas
> Felix Schwarz wrote:
> > I'm not able to specify an interpreter in a shebang line if the path
> > to this interpreter contains spaces.
>
> That is correct. It is part of the implementation of the Berkeley #!
> exec(2) hack and as such is now simply the way things are and have
> been for many years.
>
> Here is a now somewhat dated explanation of this from decades ago:
>
> http://www.faqs.org/faqs/unix-faq/faq/part3/section-16.html
A lot has been said including one thing and its contrary about
the she-bang and its history. Sven Mascheck has done a lot of
research on the subject and made the results available here:
http://www.in-ulm.de/~mascheck/various/shebang/
Among very interesting things, he says that that section of the
Unix FAQ is not totally correct.
--
Stéphane
Stephane Chazelas
It should also be noted that the #! mechanism is not standard.
Read: not supported by either of the POSIX or Unix standard.
On POSIX systems, you can still use scripts, but either they are
considered as POSIX sh scripts (when they are called via
execvp/execlp(3) or sh(1) (and thus system(3)/popen(3))
env/awk/ex/vi... and all the standard utilities that can
execute commands) or you have to explicitely call the
interpreter (awk -f /path/the/file for instance).
Now, depending on the syntax of your interpreter, you could use
some trick to have your file interpreted by the proper
interpreter within those POSIX constraints.
For instance for awk, you could do thinks like:
"exec" "awk" "-f" "$0" "$@" && 0
<rest-of-your-awk-script-assuming-your-script-doesn't-have-only-BEGIN-statements>
--
Stéphane