On 1 feb, 19:51, “Garance A Drosehn” [email protected] wrote:
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):
Erco's Homepage: Unix Tools (epath)
or if you want ruby code:
epath - Free OS Utils Applications Downloads
http://rubyforge.org/projects/ggenv/ ( a simpler library )