spaces in the shebang interpreter path
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-redhat-linux-gnu'
-DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE -O2 -g
-pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic
uname output: Linux ws2.schwarz.lokal 2.6.21.7-3.fc8xen #1 SMP Fri Mar 28
20:16:21 CET 2008 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu
Bash Version: 3.2
Patch Level: 33
Release Status: release
Description:
I'm not able to specify an interpreter in a shebang line if the path
to this interpreter contains spaces. 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.
e.g.
The directory "/home/fs/foo bar" contains the executable bin/python
Now I have this python script
---
#!/home/fs/foo bar/bin/python
print 'foo bar'
---
The shebang above obviously can't work because bash tries to find the
executable named 'foo' and pass 'bar/bin/python' as a parameter.
Therefore I tried to escape the path like in other bash scripts
('#!/home/fs/foo\ bar/bin/python') but this doesn't work either.
Quotes (#!"/home/fs/foo bar/bin/python") don't cut it.
IMHO bash should support every valid unix path for shebang lines.
fs
smime.p7s
Description: S/MIME Cryptographic Signature
Re: spaces in the shebang interpreter path
Felix Schwarz <[EMAIL PROTECTED]> wrote: > 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
Re: spaces in the shebang interpreter path
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 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."
Re: spaces in the shebang interpreter path
On Sun, May 11, 2008 at 12:37:12PM -0600, Bob Proulx wrote: > 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
Re: spaces in the shebang interpreter path
Hi Bob, hi Paul, thanks for your detailed explanations. So I agree that this is not a bash bug ;-) Maybe in ten years we will see a Un*x release which will allow the use of spaces in the shebang line *dreaming*. thanks again fs smime.p7s Description: S/MIME Cryptographic Signature
