proper usr/bin/env ruby shebang

[gga]

Well, on many of my systems, if /usr is not mounted, then 'ruby' itself
is also not available!

I have a bigger concern with using /usr/bin/env for this. The
/usr/bin/env trick will only work if ruby *IS* in the PATH of the
person who is running the ruby script, and if that version of ruby is
the version expected by the script. On many systems that is a safe
assumption, but it isn't always true.

It should be.

Consider something like MacOS 10, for instance, where Apple
ships one version of ruby in /usr/bin, but many people will install a
newer version in /opt/local/bin. I've had some scripts fail because
the user running them didn't have /opt/local/bin in their PATH.

More the reason to use /usr/bin/env. That way, you are not hard-
coding the script to a specific version of ruby.
If you had done the opposite and had used #! /usr/bin/ruby (or
whatever location macs put ruby by default ), your users would have
never been able to use a different version of ruby without having to
manually change the path to ruby in all scripts or type "ruby" itself.
If your users have path issues, your likely problem is not /usr/bin/
env but a bad system-wide .bashrc or .tcshrc configuration file that
is not adding the path automatically (a sysadmin issue) or some lack
of knowledge on the user's part who probably overrode what the
sysadmin did by setting path improperly. If it is a sysadmin issue,
talk to your sysadmin (and probably, start shopping for a new
sysadmin . If it is a user issue, as it is more likely, teach him
how to change variables without overriding system-wide configurations
(ie. PATH=stuff:$PATH instead of just PATH=stuff).
Another way this happens is when a user wants to use an unpopular (or
an incompatible) shell within the company (say, zsh in a place where
tcsh is the default) and as such he does not inherit the settings the
sysadmin sets up for him. A good way around this (I have found over
the years) is to eventually handle all environment path changes with a
custom script (usually written in perl or ruby) rather than by using
the shell's built-in commands (setenv/export/etc). The ruby script is
the one in charge of detecting the shell the user is using and spits
out the correct setenv commands for it (this output is evaled thru an
alias).
See for example (this only handle output for a single shell, thou):
http://seriss.com/people/erco/unixtools/ (epath)
or if you want ruby code:
http://www.highend3d.com/downloads/tools/os_utils/epath-3183.html
http://rubyforge.org/projects/ggenv/ ( a simpler library )

 

[gga]

Some platforms don't even have an env. I regularly work on one.

- Will

env in bin is definitively non-standard unix, so that platform is
likely to end with a sudo ln -s /bin/env /usr/bin almost immediately.
I was not aware of any unix platform without env. What platform are
you on btw? Obviously windows does not have env, but you solve issues
there with file associations or by using some unix environment (like
cygwin, etc).

 

[Daniel DeLorme]

Do not rely on /usr/bin/env, it may not exist.

Also, /usr/bin/env relies on the $PATH env variable,
so if you try to run this as a cron job it will fail
because $PATH is not set.

Daniel

 

[gga]

Also, /usr/bin/env relies on the $PATH env variable,
so if you try to run this as a cron job it will fail
because $PATH is not set.

Daniel

Again, that's probably bad sysadmin or user error in setting up cron.

grep PATH /etc/crontab

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

If you run your own cron jobs as a normal user, you should create your
own similar crontab file. You can do so with:

crontab /etc/crontab
crontab -e # to edit it

(Depending on your linux flavor, your user cron file will be stored
in /var/spool/cron/crontabs/<user> (Unix/Slackware/*BSD),
/var/spool/cron/<user> (RedHat) or /var/cron/tabs/<user> (SuSE).