On Tue, 14 Mar 2000, Simon Budig <[EMAIL PROTECTED]> wrote:
> Raphael Quinet ([EMAIL PROTECTED]) wrote:
> > I think that the only way to guard against users having a broken path
> > is to hardcode the location of the perl executable in the scripts.
> > Actually, this should also be done for python because using "env" will
> > create exactly the same problems.
> Using "env" is much more portable than always using "/usr/bin/python".
> Determining the location of the binary at compile time is a good
> compromise IMHO. So where is our autoconf/automake guru? :-)

The advantage of "env" is that you can copy a script from one machine
to another and it will work as long as the user has set her path
correctly.  The disadvantage is that the user will get very strange
results if he has an older version of the interpreter in her path.

The advantage of hardcoding the path is that you can be sure that the
scripts will always work on the machine on which they were installed,
regardless of what the user has in her path.  The disadvantage is that
you cannot simply copy the script to another machine and expect it to
work if the two machines are set up differently.

On a multi-user system, I would certainly prefer the second solution.
But if it is important for you to be able to copy some files from one
machine to another without re-configuring and re-installing the
software, then the first solution is better.  It all depends on the
usage scenario.

> > Just to give you an example, there are several versions of Perl in my
> > path on one of the systems I use at work:
> > 
> > $ /usr/bin/perl -v
> >   This is perl, version 5.003 with EMBED
> > $ /opt/local/bin/perl --version
> >   This is perl, version 5.004_04 built for sun4-solaris
> > $ /Local/bin/perl --version
> >   This is perl, version 5.005_03 built for sun4-solaris
> Ouch!
> > There are also some older versions of Perl available, but fortunately
> > they have been renamed (e.g. perl4, oldperl) so that they are not used
> > by default.
> /me wants to say "please fix the version chaos on this machine" but
> I understand, that there are Systems with lots of perl installations
> where the Gimp-Admin is != Perl-Admin...

It is not only a matter of persons, it could also be a matter of
security policy.  Some companies will only install software packages
in "system" directories after they have passed several audits.  This
leads to a situation in which the system directories contain some old
but relatively safe programs and the other directories such as
/usr/local or /opt/local contain newer programs.  I do not consider
the system described above as being "broken" or suffering from a
"version chaos": you only have to take into account the fact that
different packages are installed in different places for different

Then it is up to the users to decide how they configure their path.
You cannot force anyone to use all the newest tools if they do not
really need them, so many users have "/usr/bin" and "/bin" first in
their path.  They are happy with that and all the tools they use
regularly do work fine.  But if one of the tools that is not installed
in /usr/bin (e.g. a Perl-Fu script) depends on another tool that is
available in several directories, then it is necessary to be careful.
One solution is to write a wrapper around the Gimp which will reset
the path before invoking the application.  But this will not work if
the scripts can be invoked directly, so another solution is to
hardcode the paths in the scripts themselves.


Reply via email to