Proper usr/bin/env ruby shebang

This will not work for platforms that put env in /bin or don't have /usr
mounted.

Paul

···

On Thu, Feb 01, 2007 at 08:35:08AM +0900, gga wrote:

What will work across platforms and OSes is this:

#! /usr/bin/env ruby

Paul Brannan wrote:

···

On Thu, Feb 01, 2007 at 08:35:08AM +0900, gga wrote:

What will work across platforms and OSes is this:

#! /usr/bin/env ruby

This will not work for platforms that put env in /bin or don't have /usr
mounted.

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

- Will

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

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.

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.

(ie, I helped them install ruby into /opt/local/bin using macports,
but they didn't update their settings for PATH)

···

On 2/1/07, Paul Brannan <pbrannan@atdesk.com> wrote:

On Thu, Feb 01, 2007 at 08:35:08AM +0900, gga wrote:
> What will work across platforms and OSes is this:
>
> #! /usr/bin/env ruby

This will not work for platforms that put env in /bin or don't have /usr
mounted.

--
Garance Alistair Drosehn = drosihn@gmail.com
Senior Systems Programmer
Rensselaer Polytechnic Institute; Troy, NY; USA

> > What will work across platforms and OSes is this:

> > #! /usr/bin/env ruby

> This will not work for platforms that put env in /bin or don't have /usr
> mounted.

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

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:
http://www.highend3d.com/downloads/tools/os_utils/epath-3183.html
http://rubyforge.org/projects/ggenv/ ( a simpler library )

···

On 1 feb, 19:51, "Garance A Drosehn" <dros...@gmail.com> wrote:

On 2/1/07, Paul Brannan <pbran...@atdesk.com> wrote:
> On Thu, Feb 01, 2007 at 08:35:08AM +0900, gga wrote:

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

···

On 1 feb, 19:22, Will Parsons <oud...@nodomain.invalid> wrote:

Paul Brannan wrote:
> On Thu, Feb 01, 2007 at 08:35:08AM +0900, gga wrote:
>> What will work across platforms and OSes is this:

>> #! /usr/bin/env ruby

> This will not work for platforms that put env in /bin or don't have /usr
> mounted.

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

- Will