Interesting that he uses a space after the #!. I don't think I've ever done so.
From the article: It is rumored that some systems only recognize an executable script when it starts with the four bytes `#! /', probably because the GNU autoconf manual says so, but it seems impossible to find confirmation for this rumor.
# - the Unix truth
11–17 of 17 posts
Re: # - the Unix truth
#12I had a run-in with it on a shared host with some PHP cron jobs (don't ask). The hosting company changed the handler for *.php and everything broke until I renamed the files. The whole story:
http://serverfault.com/questions/82296/when-do-file-extensio...
Re: # - the Unix truth
#13>If there is such nonblank text then for [most unices] this group consists of precisely one argument, as in the example above where argi consists of the single argument "-a -b". Interesting. This seems pretty unintuitive, I would expect the "-a", "-b" behaviour. (I recognise that this would be more complicated to implement and make it impossible to pass an argument with spaces.) It seems like it could easily cause pr…
Try the following files:
#!/usr/bin/sed -f
s/a/b/g
s/c/d/g
#!/usr/bin/sed -e 's/a/b/g' -f
s/c/d/gRe: # - the Unix truth
#14"/bin/sh^M: bad interpreter: No such file or directory" is what Linux gives nowadays after a shell script is edited in Windows' Notepad. I have an idea it used to be more cryptic.
Probably a common failure point, if people use small local scripts in their work-flow, and happen to tweak one in a Windows machine.
Re: # - the Unix truth
#15>If there is such nonblank text then for [most unices] this group consists of precisely one argument, as in the example above where argi consists of the single argument "-a -b". Interesting. This seems pretty unintuitive, I would expect the "-a", "-b" behaviour. (I recognise that this would be more complicated to implement and make it impossible to pass an argument with spaces.) It seems like it could easily cause pr…
It does work this way, though. Try the following files: #!/usr/bin/sed -f s/a/b/g s/c/d/g #!/usr/bin/sed -e 's/a/b/g' -f s/c/d/g
Removing the quotes gives "-e expression #1, char 10: unknown option to `s'", because "s/a/b/g -f" is not a valid sed command.
And to illustrate my point about env, sed for me is in /bin. But "#!/usr/bin/env sed -f" doesn't work, because it looks for a program named "sed -f".
Re: # - the Unix truth
#16'This usually leads to screenfuls of error messages and users praying that in this megabyte of binary garbage no valid shell commands occur' hit a nerve.
Re: # - the Unix truth
#17Earlier quoted context omitted.
It does work this way, though. Try the following files: #!/usr/bin/sed -f s/a/b/g s/c/d/g #!/usr/bin/sed -e 's/a/b/g' -f s/c/d/g
It's not clear to me what point you're trying to make, but the second one gives an error: "-e expression #1, char 2: unknown command: `''", because it's getting a single argument containing a quote. Removing the quotes gives "-e expression #1, char 10: unknown option to `s'", because "s/a/b/g -f" is not a valid sed command. And to illustrate my point about env, sed for me is in /bin. But "#!/usr/bin/env sed -f" doesn…