5 ms·

# - the Unix truth

36 points by jluxenberg 16y ago

randallsquared 16y ago
Interesting that he uses a space after the #!. I don't think I've ever done so.
- guns 16y ago
  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.
  - sprout 16y ago
    I actually took a weeklong shell course through work where the instructor said not to put whitespace in there. However, I've never read of any systems that have a problem with whitespace, so I suppose it's just as well to include it.
  - randallsquared 16y ago
    Yeah, that's what prompted me to even notice, since I was assuming it was just spaced out to make it clearer.
justintnt 16y ago
'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.
- hysterix 16y ago
  Yeah I had a good laugh because it explains (at least some) of the times I've seen my shell behave like this.
- InclinedPlane 16y ago
  A similar problem is accidentally dumping binary data to the terminal screen (via an incautious grep, for example), as various bytes get rendered as their corresponding control characters. This is even worse on windows (or at least used to be, I think Win 7 fixed this) where ^G is hard-wired to the system speaker which is fairly difficult to mute effectively.
  - varjag 16y ago
    That's a bit more innocent though, since reset(1) usually helps.
- bradleyland 16y ago
  Even more terrifying. During my early days of Unix usage, I accidentally (through tab completion and incompetence) executed `source ~/.bash_history`. The outcome was not good.
philh 16y ago
>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 problems especially if you use `env` to handle paths. But I don't think I've ever run afoul of this.
- kree10 16y ago
  I miss the old FreeBSD parameter behavior when I could have shebang lines like: #!/usr/local/bin/sudo -u someuser /bin/sh
- JoachimSchipper 16y ago
  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
  - philh 16y ago
    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't work, because it looks for a program named "sed -f".
    - JoachimSchipper 16y ago
      I was agreeing with you, and providing a simple testcase to show that you were, indeed, right (because I agreed that the behaviour is somewhat surprising). Sorry if that wasn't clear.
kree10 16y ago
There is at last one more case: binfmt_misc on Linux, which gives you Windows-style run-based-on-file-extension. I 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-extensions-override-shebang-lines-on-linux http://serverfault.com/questions/82296/when-do-file-extensio...
ableal 16y ago
> Many Unix systems will consider a `\r' in a DOS-type line-ending (`\r\n') part of the interpreter arguments. (HP-UX, Solaris, UnixWare ignore trailing `\r'. AIX, BSD/OS, FreeBSD, Linux, OpenBSD, Tru64 do not.) "/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.

# - the Unix truth

36 points by jluxenberg 16y ago

randallsquared 16y ago

Interesting that he uses a space after the #!. I don't think I've ever done so.

guns 16y ago
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.
- sprout 16y ago
  I actually took a weeklong shell course through work where the instructor said not to put whitespace in there. However, I've never read of any systems that have a problem with whitespace, so I suppose it's just as well to include it.
- randallsquared 16y ago
  Yeah, that's what prompted me to even notice, since I was assuming it was just spaced out to make it clearer.

justintnt 16y ago

'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.

hysterix 16y ago
Yeah I had a good laugh because it explains (at least some) of the times I've seen my shell behave like this.
InclinedPlane 16y ago
A similar problem is accidentally dumping binary data to the terminal screen (via an incautious grep, for example), as various bytes get rendered as their corresponding control characters. This is even worse on windows (or at least used to be, I think Win 7 fixed this) where ^G is hard-wired to the system speaker which is fairly difficult to mute effectively.
- varjag 16y ago
  That's a bit more innocent though, since reset(1) usually helps.
bradleyland 16y ago
Even more terrifying. During my early days of Unix usage, I accidentally (through tab completion and incompetence) executed `source ~/.bash_history`. The outcome was not good.

philh 16y ago

>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 problems especially if you use `env` to handle paths. But I don't think I've ever run afoul of this.

kree10 16y ago
I miss the old FreeBSD parameter behavior when I could have shebang lines like: #!/usr/local/bin/sudo -u someuser /bin/sh
JoachimSchipper 16y ago
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
- philh 16y ago
  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't work, because it looks for a program named "sed -f".
  - JoachimSchipper 16y ago
    I was agreeing with you, and providing a simple testcase to show that you were, indeed, right (because I agreed that the behaviour is somewhat surprising). Sorry if that wasn't clear.

kree10 16y ago

There is at last one more case: binfmt_misc on Linux, which gives you Windows-style run-based-on-file-extension. I 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-extensions-override-shebang-lines-on-linux http://serverfault.com/questions/82296/when-do-file-extensio...

ableal 16y ago

> Many Unix systems will consider a `\r' in a DOS-type line-ending (`\r\n') part of the interpreter arguments. (HP-UX, Solaris, UnixWare ignore trailing `\r'. AIX, BSD/OS, FreeBSD, Linux, OpenBSD, Tru64 do not.) "/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.