Re: [gimp-devel] Re: Bug#6916: [gimp-bug] Wrong PERL Path in ./plug-ins/perl/pxgettext
On Tue, Mar 14, 2000 at 07:09:16PM +0100, Simon Budig [EMAIL PROTECTED] wrote: 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? :-) That's not the problem. Is it done that way. On the other hand, I was told that people would like to call pxgettext (a.k.a. update.sh) in an unconfigured tree, which I do no longer support. We can't have both :( -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: [gimp-devel] Re: Bug#6916: [gimp-bug] Wrong PERL Path in ./plug-ins/perl/pxgettext
On Tue, Mar 14, 2000 at 06:12:39PM +0100, Simon Budig [EMAIL PROTECTED] wrote: This might work for python, but it will not work for perl. It will find the first perl in your path (which is often perl4), not the perl gimp was configured with. Are there really multiple different executables named "perl" (not "perl4" or so!) in your path? No, (at leats not since 1998 ;) So when you work in your shell you always execute version 4 of perl, when you invoke "perl"? That's what PATH is for. At my universities hp-ux machines, /usr/bin/perl is invariably perl4.036 (fixed), at the irix machines, it's perl5.003, at... If gimp would only run on linux (as would be the case if it were a gnome app ;-), I wouldn't argue... Especially since it's fixed by using the correct path in cvs anyhow. python has no such problems _yet_, since it's a very young language. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: [gimp-devel] Re: Bug#6916: [gimp-bug] Wrong PERL Path in ./plug-ins/perl/pxgettext
Marc Lehmann ([EMAIL PROTECTED]) wrote: On Mon, Mar 06, 2000 at 04:16:04PM +0100, Simon Budig [EMAIL PROTECTED] wrote: There is a better way. This might work for python, but it will not work for perl. It will find the first perl in your path (which is often perl4), not the perl gimp was configured with. 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"? Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Re: Bug#6916: [gimp-bug] Wrong PERL Path in ./plug-ins/perl/pxgettext
On Tue, 14 Mar 2000, Simon Budig [EMAIL PROTECTED] wrote: Marc Lehmann ([EMAIL PROTECTED]) wrote: This might work for python, but it will not work for perl. It will find the first perl in your path (which is often perl4), not the perl gimp was configured with. 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 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. 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 built under solaris at Nov 10 1996 13:23:19 + suidperl security patch ... $ /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 ... 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. When I configure the Gimp, I always have /Local/bin first in my path. But this is not the case for all users: some of them have /usr/bin or /opt/local/bin first, so they will have problems if they try to execute the Perl-Fu scripts with perl 5.003 or 5.004. This problem can be solved by hardcoding the path to the perl executable in all scripts during the configure step. -Raphael
Re: [gimp-devel] Re: Bug#6916: [gimp-bug] Wrong PERL Path in ./plug-ins/perl/pxgettext
Raphael Quinet ([EMAIL PROTECTED]) 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
--
[EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: Bug#6916: [gimp-bug] Wrong PERL Path in ./plug-ins/perl/pxgettext
[EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote: -- Problem description: Path to PERL do not have to be: #!/usr/bin/perl it's somewhere else at my system... -- How to repeat: Try to compile with PERL installed somewhere else... -- Other comments: Should be set in ./configure correctly... There is a better way. If the scripts start with #!/usr/bin/env perl env will search for perl in the path and start it. From the env info-page: The first remaining argument specifies the program name to invoke; it is searched for according to the `PATH' environment variable. Any remaining arguments are passed as arguments to that program. I submitted a similiar bug-report for pyton to the list, but noone cared to apply it. I do not have CVS-write access so I cant fix it. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
