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
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, 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 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
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: [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
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: Bug#6916: [gimp-bug] Wrong PERL Path in ./plug-ins/perl/pxgettext
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. A fix will be in cvs soon (as soon as I am through my mail :() I hope it's ok for po/update.sh to depend on a configured tree? Mitch: maybe this fixes your coredump-problem as well? -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
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/
