Comments on: Avoid hard-coding the path to the interpreter in your scripts http://gabrito.com/post/avoid-hard-coding-the-path-to-the-interpreter-in-your-scripts Anecdotes on Java, Ruby, Sysadmin, SEO, Design, and Management Tue, 06 Jan 2009 07:37:22 +0000 http://wordpress.org/?v=2.7 hourly 1 By: Todd Huss http://gabrito.com/post/avoid-hard-coding-the-path-to-the-interpreter-in-your-scripts/comment-page-1#comment-885 Todd Huss Fri, 19 May 2006 21:19:19 +0000 http://gabrito.com/post/avoid-hard-coding-the-path-to-the-interpreter-in-your-scripts#comment-885 William: you are correct that /bin/sh is "the most portable" way to write but I was speaking more generally about using more feature rich interpreters which can be found all over the system. Kurin: On our FreeBSD 4 systems at work it's in /usr/bin but I didn't install the systems so it could have been a mistake. Regardless the point is really that it varies from system to system. UmberGryphon: Once you take in all the user written perl, python, and ruby scripts that run under non-priveleged accounts on production system they well outweight the volume of /bin/sh scripts being run by root. If you're a sysadmin this tip doesn't really apply, hence the caveat, but if you're a programmer at an ISV then scripts running under non-priveleged accounts are pretty much your world and that's where the advice applies. William: you are correct that /bin/sh is “the most portable” way to write but I was speaking more generally about using more feature rich interpreters which can be found all over the system.

Kurin: On our FreeBSD 4 systems at work it’s in /usr/bin but I didn’t install the systems so it could have been a mistake. Regardless the point is really that it varies from system to system.

UmberGryphon: Once you take in all the user written perl, python, and ruby scripts that run under non-priveleged accounts on production system they well outweight the volume of /bin/sh scripts being run by root. If you’re a sysadmin this tip doesn’t really apply, hence the caveat, but if you’re a programmer at an ISV then scripts running under non-priveleged accounts are pretty much your world and that’s where the advice applies.

]]> By: UmberGryphon http://gabrito.com/post/avoid-hard-coding-the-path-to-the-interpreter-in-your-scripts/comment-page-1#comment-883 UmberGryphon Fri, 19 May 2006 20:51:24 +0000 http://gabrito.com/post/avoid-hard-coding-the-path-to-the-interpreter-in-your-scripts#comment-883 "The only caveat is that you DO NOT want to do this for critical security scripts because it opens you up to path based exploits." I would extend this to say "The only caveat is that you DO NOT want to do this for any script that root or any user that is in a critical group might ever run." And what does that leave, exactly? Things going wrong with differing paths to bash/perl/ruby/etc. are a problem, but things going wrong with path based exploits are several orders of magnitude worse. “The only caveat is that you DO NOT want to do this for critical security scripts because it opens you up to path based exploits.”

I would extend this to say “The only caveat is that you DO NOT want to do this for any script that root or any user that is in a critical group might ever run.” And what does that leave, exactly?

Things going wrong with differing paths to bash/perl/ruby/etc. are a problem, but things going wrong with path based exploits are several orders of magnitude worse.

]]> By: Kurin http://gabrito.com/post/avoid-hard-coding-the-path-to-the-interpreter-in-your-scripts/comment-page-1#comment-881 Kurin Fri, 19 May 2006 18:54:37 +0000 http://gabrito.com/post/avoid-hard-coding-the-path-to-the-interpreter-in-your-scripts#comment-881 On FreeBSD it's never /usr/bin/bash unless your admin is doing something wrong (like trying to get a script to run that's hardcoded to /usr/bin/bash). It's /usr/local/bin/bash, if it's there at all, which it isn't by default. On FreeBSD it’s never /usr/bin/bash unless your admin is doing something wrong (like trying to get a script to run that’s hardcoded to /usr/bin/bash). It’s /usr/local/bin/bash, if it’s there at all, which it isn’t by default.

]]> By: William http://gabrito.com/post/avoid-hard-coding-the-path-to-the-interpreter-in-your-scripts/comment-page-1#comment-879 William Fri, 19 May 2006 17:35:52 +0000 http://gabrito.com/post/avoid-hard-coding-the-path-to-the-interpreter-in-your-scripts#comment-879 There is no way you can reasonably assert that the path to 'env' is any more stable than the path to bash or bourne shell on a Linux system. I'll fully agree with you on the issue with regard to python, perl, ruby, tcl, but for shell scripts /bin/sh is *the* way to ensure portability. There is no way you can reasonably assert that the path to ‘env’ is any more stable than the path to bash or bourne shell on a Linux system. I’ll fully agree with you on the issue with regard to python, perl, ruby, tcl, but for shell scripts /bin/sh is *the* way to ensure portability.

]]>