On Tue, 14 Mar 2000, Simon Budig <Simon.Budig@xxxxxxxxxxx> wrote: > Raphael Quinet (quinet@xxxxxxxxxx) 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 purposes. 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. -Raphael
