5 ms·
Please don't start your shell scripts with #!/bin/sh. If a script foobar needs to be interpreted with sh, just run it with '/bin/sh foobar', instead of ./foobar
by anatoly 17y ago
Please don't start your shell scripts with #!/bin/sh. If a script foobar needs to be interpreted with sh, just run it with '/bin/sh foobar', instead of ./foobar.
Please don't put #include <stdlib.h> in your C source files. By doing this you remove my ability to compile your files in an environment where the standard library is not present. Instead, whenever you need to compile a file that uses stdlib.h functionality, simply use a small wrapper file that includes stdlib.h and then includes your source file, and compile that.
- flooha 17y ago"Please don't start your shell scripts with #!/bin/sh...run it with '/bin/sh foobar', instead of ./foobar." Are you serious?
- adamc 17y agoHe's making an analogy to the article.
- flooha 17y agoThat's what I was hoping...I guess I prefer my sarcasm a little more heavy handed. lol
- masklinn 17y agoYeah but his analogy is wrong in that /bin/sh is usually a link (or a copy) of the user's shell. So the user can easily configure which shell is loaded and how using /bin/sh (though /usr/bin/env sh would probably be even better). What Ryan's gripping against here is that the people requiring rubygems usually don't care for rubygems itself. They just want to require a library which (on their machine) happens to be managed via rubygems. And this management is not the sole strategy. Somebody else could be using another utility, or even no utility at all if they handle their $LOAD_PATH manually (which Ryan apparently does). And in these cases, requiring rubygems breaks their platform: they might not want or care for rubygems. In any case, it's usually not needed so why require it? And that's Ryan's point: by requiring rubygems when it's not needed (which is most of the time) in your library, you're forcing people to use rubygems whether they like (or need) it or not. Furthremore, his analogy is also wrong because even with a /bin/sh shebang *it's trivial for me to overload it by calling `./mysupershell yourscript`. With `require rubygems` there's no such recourse (apart from `require` hackery or other such crap).
- tptacek 17y agoThe /bin/sh link thing is a Linuxism --- in fact, I think it's a Debianism. On FreeBSD, Solaris, and OS X, /bin/sh is either always Bourne or always Bourne-Again. Also, the link that is there is always to a Bourne shell variant. It's not like your system will run fine with ksh as /bin/sh.
- papercrane 17y agoActually your system should work just fine with ksh as /bin/sh. KornShell is a superset of the Bourne shell. http://www.kornshell.com/doc/faq.html http://www.kornshell.com/doc/faq.html
- tptacek 17y agoOK ksh a bad example.
- silentbicycle 17y agoWell, seriously, don't start your scripts with #!/bin/bash if you don't require any of bash's extra scripting functionality. (If you have to ask, you don't.) Bash isn't standard, sh is. It makes porting things other Unixes (e.g. the BSDs) easier. Not every Unix is Linux.
- smanek 17y agoIncidentally, I've seen some people argue it's more portable to use '#!/usr/bin/env sh' than '#!/bin/sh'. Most every machine I've been on has both /bin/sh and /usr/bin/env, so it's a bit of a non-issue: but does anyone know what the 'correct' shebang for a sh script is?
- masklinn 17y agoThe latter, because it simplifies using alternate sh if you need to e.g. create separate execution environments, à la virtualenv in python. In fact that's a good example, though it's in python: if you use `#!/usr/bin/python` as your shebang your script will break under virtualenv, whereas if you use `#!/usr/bin/env python` it will work perfectly. Now /bin/sh is probably a POSIX requirement so it'll always be there and you can always override the shebang with an explicit shell call (or by temporarily rebinding /bin/sh though that one requires root access), but going through env doesn't cost you (as a programmer) more and it simplifies the job of the users (if they need to sandbox your script in some way)
- smanek 17y agoThanks, that makes sense. I suppose I'll use an env shebang from now.
- silentbicycle 17y agoI use /usr/bin/env for most things (Python and Lua, for example), but still use /bin/sh for the bourne shell, because that's part of the standard.
- tptacek 17y ago
- masklinn 17y agoAnalogy failures: * Configuring /bin/sh to point to my shell of choice is trivial (and common) * Overriding the shebang is even more trivial, if I don't like sh, I can call `./mysupershell foobar` Meanwhile, if I don't want gems on my machine and manage my $LOAD_PATH manually or through other means (which seems to be Ryan's case) but you decided that your library was going to require rubygems dammit, I have the choices between * Installing rubygems (and duplicating my $LOAD_PATH handling efforts) anyway because you decided I was to have rubygems on my machine whether or not I liked it * Adding an empty rubygems.rb to my $LOAD_PATH (yeah, kludge) * Hacking Kernel#require to ignore gems request (yeah, horrible hack)
- tptacek 17y agoIf you're going to be in the tiny tiny minority of Ruby devs that insists on not installing rubygems, having a stubbed "rubygems.rb" in your load path is not an unreasonable request --- particularly compared to the request that everybody else uses some contorted command line to execute their script to accomodate you.
- extension 17y agoIt's unreasonable if you want to have both rubygems and some other package system available at the same time, as is most often the case. Having to use the contorted command line is the rare case, as you almost always invoke ruby scripts through the rubygems generated wrapper or some other isolated script intended specifically for command line use, which takes care of rubygems itself.
- deleted 17y ago[deleted]