Raphael Quinet (quinet@xxxxxxxxxx) wrote:
> > Are there really multiple different executables named "perl" (not "perl4" or
> > so!) in your path? So when you work in your shell you always execute
> > version 4 of perl, when you invoke "perl"?
>
> I suppose that Marc meant that the person running a Perl-Fu script
> might not the the person who has configured and installed it. It is
> likely that the one who configures the Gimp has set his path correctly
> (in order to be able to run configure without errors) but it can
> happen that another user has a broken path, with old tools listed
> first. In that case, the user would get a different version of perl
> than the one that Gimp was configured with.
I see the point. So it is probably really the best to hardcode the
path to perl at ./configure-time. Though I dont like situations as in
your example. This is a perfect way to create great confusion among the
users... ("But it works for me! Why?")
> 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? :-)
> 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...
Bye,
Simon
--
Simon.Budig@xxxxxxxxxxx http://www.home.unix-ag.org/simon/
