X2Go Bug report logs - #1133
Inconsistent Perl used by server or its agent on connect

Toggle useless messages

Message #5 received at submit@bugs.x2go.org (full text, mbox, reply):

From: Ted Toal <twtoal@ucdavis.edu>

To: submit@bugs.x2go.org

Subject: Inconsistent Perl used by server or its agent on connect

Date: Tue, 10 Jan 2017 13:15:18 -0800

Package: NXAGENT
Version: 3.5.0

My .bash_profile defines Perl environment variables for Active Perl, and adds the Active Perl bin directory to the start of the path. This causes an x2go session to fail with the message:
Connection failed. /usr/bin/perl: symbol lookup error: /share/carvajal-archive/PACKAGES/local/ActivePerl-5.24/lib/auto/Sys/Hostname/Hostname.so: undefined symbol: Perl_xs_handshake
NXAGENT is user /usr/bin/perl and ignoring the Perl bin directory at the start of the path, but it is nevertheless using the Perl environment variables and so is looking in the wrong place for the Perl library.

Message #10 received at 1133@bugs.x2go.org (full text, mbox, reply):

From: Stefan Baur <X2Go-ML-1@baur-itcs.de>

To: Ted Toal <twtoal@ucdavis.edu>, 1133@bugs.x2go.org, control@bugs.x2go.org

Subject: Re: [X2Go-Dev] Bug#1133: Inconsistent Perl used by server or its agent on connect

Date: Tue, 10 Jan 2017 23:35:19 +0100

[Message part 1 (text/plain, inline)]

Control: close -1
Control: tag -1 not-a-bug

Am 10.01.2017 um 22:15 schrieb Ted Toal:
> Package: NXAGENT
> Version: 3.5.0
> 
> My .bash_profile defines Perl environment variables for Active Perl, and adds the Active Perl bin directory to the start of the path. This causes an x2go session to fail with the message:
> Connection failed. /usr/bin/perl: symbol lookup error: /share/carvajal-archive/PACKAGES/local/ActivePerl-5.24/lib/auto/Sys/Hostname/Hostname.so: undefined symbol: Perl_xs_handshake
> NXAGENT is user /usr/bin/perl and ignoring the Perl bin directory at the start of the path, but it is nevertheless using the Perl environment variables and so is looking in the wrong place for the Perl library.

I'd say this isn't a bug, but actually expected behavior.
If you need different values for variables depending on which software
you run, you either need to prefix them manually each time you call that
software, or write a wrapper script, or use if/then clauses in your
.bash_profile.  The latter is what you seem to have decided to do, and
ran into problems with, judging from your bug report #1134, thus closing
this one.

-Stefan


-- 
BAUR-ITCS UG (haftungsbeschränkt)
Geschäftsführer: Stefan Baur
Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364
Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243

[signature.asc (application/pgp-signature, attachment)]

Message #21 received at 1133@bugs.x2go.org (full text, mbox, reply):

From: Ted Toal <twtoal@ucdavis.edu>

To: Stefan Baur <X2Go-ML-1@baur-itcs.de>

Cc: 1133@bugs.x2go.org, control@bugs.x2go.org

Subject: Re: [X2Go-Dev] Bug#1133: Inconsistent Perl used by server or its agent on connect

Date: Tue, 10 Jan 2017 14:48:22 -0800

I disagree.  Perl behavior is to look at env. var. PERL5LIB to find its library.  This should be set to match the Perl that is being invoked, which is normally done by placing that Perl’s bin directory on the path.  Since I did place it on the path, there are only two possibilities for why x2go ran /usr/bin/perl: either it hard-coded the path to Perl, in which case it should first set PERL5LIB (or maybe there is a Perl command line arg to specify the library folder), OR x2go ignored my changes to PATH when it ran perl (in which case it should also ignore PERL5LIB).

- Ted




> On Jan 10, 2017, at 2:35 PM, Stefan Baur <X2Go-ML-1@baur-itcs.de> wrote:
> 
> Control: close -1
> Control: tag -1 not-a-bug
> 
> Am 10.01.2017 um 22:15 schrieb Ted Toal:
>> Package: NXAGENT
>> Version: 3.5.0
>> 
>> My .bash_profile defines Perl environment variables for Active Perl, and adds the Active Perl bin directory to the start of the path. This causes an x2go session to fail with the message:
>> Connection failed. /usr/bin/perl: symbol lookup error: /share/carvajal-archive/PACKAGES/local/ActivePerl-5.24/lib/auto/Sys/Hostname/Hostname.so: undefined symbol: Perl_xs_handshake
>> NXAGENT is user /usr/bin/perl and ignoring the Perl bin directory at the start of the path, but it is nevertheless using the Perl environment variables and so is looking in the wrong place for the Perl library.
> 
> I'd say this isn't a bug, but actually expected behavior.
> If you need different values for variables depending on which software
> you run, you either need to prefix them manually each time you call that
> software, or write a wrapper script, or use if/then clauses in your
> .bash_profile.  The latter is what you seem to have decided to do, and
> ran into problems with, judging from your bug report #1134, thus closing
> this one.
> 
> -Stefan
> 
> 
> -- 
> BAUR-ITCS UG (haftungsbeschränkt)
> Geschäftsführer: Stefan Baur
> Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364
> Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
> 

Message #26 received at 1133@bugs.x2go.org (full text, mbox, reply):

From: Stefan Baur <X2Go-ML-1@baur-itcs.de>

To: 1133@bugs.x2go.org

Subject: Re: [X2Go-Dev] Bug#1133: Inconsistent Perl used by server or its agent on connect

Date: Wed, 11 Jan 2017 00:42:20 +0100

[Message part 1 (text/plain, inline)]

Ted,

let's examine a few things here:

You're saying that nxagent is doing things in Perl, and not the right
things.  When examining the contents of the nxagent package, all I'm
seeing wrt/ executables are bash scripts and compiled binaries, but
nothing written in Perl.
So the nxagent package can't be at fault.

We *do* have scripts that are written in Perl, and that might throw the
error you quoted.  Those are e.g. in the package with the name
x2goserver (and I wouldn't be surprised to find more of them in other
packages that have names beginning with x2go*).

grep '^#!.*perl*' /usr/bin/x2go* returns a list of scripts that all have
#!/usr/bin/perl as shebang, so yes, it's probably safe to say that the
use of /usr/bin/perl as the Perl interpreter for our scripts is hardcoded.

But again, that's not a bug, but how scripting works on Linux/Unix.
First line with shebang tells the shell which interpreter to use, so you
don't have to prefix the script name with the name of the interpreter
each time.

And of course, if you set a variable with a name matching one that "a"
Perl interpreter (be it ActivePerl or the system standard shipped with
your distribution) looks for, it will use it.

Your statement that the version of Perl being used depends on which one
comes first in the path might be true on Windows; on Unix, it will only
be true for when you type "perl" without a path in an interactive shell,
or for when call it from within, say, a bash script without preceding it
with a path.
Once you chmod +x a Perl script and call it by its name, without
prefacing the name and full path to the interpreter, the shebang line
will be used to determine the interpreter.

So, if you need to set PERL5LIB for your ActivePerl installation, it
should be unset (by adding a suitable if/then clause) when your .bashrc
/ .bash_profile are read and parsed by an X2Go task.
It's kind of weird that, according to your other bug report, you have
exactly 0 indication that you're running from within an X2Go session.
I can see how that makes it difficult to script around it ;-) - but
let's track that in the other bug report.

Kind Regards,
Stefan Baur

Am 10.01.2017 um 23:48 schrieb Ted Toal:
> I disagree.  Perl behavior is to look at env. var. PERL5LIB to find its library.  This should be set to match the Perl that is being invoked, which is normally done by placing that Perl’s bin directory on the path.  Since I did place it on the path, there are only two possibilities for why x2go ran /usr/bin/perl: either it hard-coded the path to Perl, in which case it should first set PERL5LIB (or maybe there is a Perl command line arg to specify the library folder), OR x2go ignored my changes to PATH when it ran perl (in which case it should also ignore PERL5LIB).
> 
> - Ted
> 
> 
> 
> 
>> On Jan 10, 2017, at 2:35 PM, Stefan Baur <X2Go-ML-1@baur-itcs.de> wrote:
>>
>> Control: close -1
>> Control: tag -1 not-a-bug
>>
>> Am 10.01.2017 um 22:15 schrieb Ted Toal:
>>> Package: NXAGENT
>>> Version: 3.5.0
>>>
>>> My .bash_profile defines Perl environment variables for Active Perl, and adds the Active Perl bin directory to the start of the path. This causes an x2go session to fail with the message:
>>> Connection failed. /usr/bin/perl: symbol lookup error: /share/carvajal-archive/PACKAGES/local/ActivePerl-5.24/lib/auto/Sys/Hostname/Hostname.so: undefined symbol: Perl_xs_handshake
>>> NXAGENT is user /usr/bin/perl and ignoring the Perl bin directory at the start of the path, but it is nevertheless using the Perl environment variables and so is looking in the wrong place for the Perl library.
>>
>> I'd say this isn't a bug, but actually expected behavior.
>> If you need different values for variables depending on which software
>> you run, you either need to prefix them manually each time you call that
>> software, or write a wrapper script, or use if/then clauses in your
>> .bash_profile.  The latter is what you seem to have decided to do, and
>> ran into problems with, judging from your bug report #1134, thus closing
>> this one.
>>
>> -Stefan
>>
>>
>> -- 
>> BAUR-ITCS UG (haftungsbeschränkt)
>> Geschäftsführer: Stefan Baur
>> Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364
>> Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
>>
> 


-- 
BAUR-ITCS UG (haftungsbeschränkt)
Geschäftsführer: Stefan Baur
Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364
Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243

[signature.asc (application/pgp-signature, attachment)]

Message #31 received at 1133@bugs.x2go.org (full text, mbox, reply):

From: Ted Toal <twtoal@ucdavis.edu>

To: Stefan Baur <X2Go-ML-1@baur-itcs.de>, 1133@bugs.x2go.org

Subject: Re: [X2Go-Dev] Bug#1133: Bug#1133: Inconsistent Perl used by server or its agent on connect

Date: Tue, 10 Jan 2017 17:48:06 -0800

perl has the -l option for specifying the PERL5LIB path.  That option can, and I think should, be used on the shebang of the x2go perl scripts:

#!/usr/bin/perl -l /usr/lib/perl5

or something like that.  I know the shebang line allows args.

Ted




> On Jan 10, 2017, at 3:42 PM, Stefan Baur <X2Go-ML-1@baur-itcs.de> wrote:
> 
> Ted,
> 
> let's examine a few things here:
> 
> You're saying that nxagent is doing things in Perl, and not the right
> things.  When examining the contents of the nxagent package, all I'm
> seeing wrt/ executables are bash scripts and compiled binaries, but
> nothing written in Perl.
> So the nxagent package can't be at fault.
> 
> We *do* have scripts that are written in Perl, and that might throw the
> error you quoted.  Those are e.g. in the package with the name
> x2goserver (and I wouldn't be surprised to find more of them in other
> packages that have names beginning with x2go*).
> 
> grep '^#!.*perl*' /usr/bin/x2go* returns a list of scripts that all have
> #!/usr/bin/perl as shebang, so yes, it's probably safe to say that the
> use of /usr/bin/perl as the Perl interpreter for our scripts is hardcoded.
> 
> But again, that's not a bug, but how scripting works on Linux/Unix.
> First line with shebang tells the shell which interpreter to use, so you
> don't have to prefix the script name with the name of the interpreter
> each time.
> 
> And of course, if you set a variable with a name matching one that "a"
> Perl interpreter (be it ActivePerl or the system standard shipped with
> your distribution) looks for, it will use it.
> 
> Your statement that the version of Perl being used depends on which one
> comes first in the path might be true on Windows; on Unix, it will only
> be true for when you type "perl" without a path in an interactive shell,
> or for when call it from within, say, a bash script without preceding it
> with a path.
> Once you chmod +x a Perl script and call it by its name, without
> prefacing the name and full path to the interpreter, the shebang line
> will be used to determine the interpreter.
> 
> So, if you need to set PERL5LIB for your ActivePerl installation, it
> should be unset (by adding a suitable if/then clause) when your .bashrc
> / .bash_profile are read and parsed by an X2Go task.
> It's kind of weird that, according to your other bug report, you have
> exactly 0 indication that you're running from within an X2Go session.
> I can see how that makes it difficult to script around it ;-) - but
> let's track that in the other bug report.
> 
> Kind Regards,
> Stefan Baur
> 
> Am 10.01.2017 um 23:48 schrieb Ted Toal:
>> I disagree.  Perl behavior is to look at env. var. PERL5LIB to find its library.  This should be set to match the Perl that is being invoked, which is normally done by placing that Perl’s bin directory on the path.  Since I did place it on the path, there are only two possibilities for why x2go ran /usr/bin/perl: either it hard-coded the path to Perl, in which case it should first set PERL5LIB (or maybe there is a Perl command line arg to specify the library folder), OR x2go ignored my changes to PATH when it ran perl (in which case it should also ignore PERL5LIB).
>> 
>> - Ted
>> 
>> 
>> 
>> 
>>> On Jan 10, 2017, at 2:35 PM, Stefan Baur <X2Go-ML-1@baur-itcs.de> wrote:
>>> 
>>> Control: close -1
>>> Control: tag -1 not-a-bug
>>> 
>>> Am 10.01.2017 um 22:15 schrieb Ted Toal:
>>>> Package: NXAGENT
>>>> Version: 3.5.0
>>>> 
>>>> My .bash_profile defines Perl environment variables for Active Perl, and adds the Active Perl bin directory to the start of the path. This causes an x2go session to fail with the message:
>>>> Connection failed. /usr/bin/perl: symbol lookup error: /share/carvajal-archive/PACKAGES/local/ActivePerl-5.24/lib/auto/Sys/Hostname/Hostname.so: undefined symbol: Perl_xs_handshake
>>>> NXAGENT is user /usr/bin/perl and ignoring the Perl bin directory at the start of the path, but it is nevertheless using the Perl environment variables and so is looking in the wrong place for the Perl library.
>>> 
>>> I'd say this isn't a bug, but actually expected behavior.
>>> If you need different values for variables depending on which software
>>> you run, you either need to prefix them manually each time you call that
>>> software, or write a wrapper script, or use if/then clauses in your
>>> .bash_profile.  The latter is what you seem to have decided to do, and
>>> ran into problems with, judging from your bug report #1134, thus closing
>>> this one.
>>> 
>>> -Stefan
>>> 
>>> 
>>> -- 
>>> BAUR-ITCS UG (haftungsbeschränkt)
>>> Geschäftsführer: Stefan Baur
>>> Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364
>>> Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
>>> 
>> 
> 
> 
> -- 
> BAUR-ITCS UG (haftungsbeschränkt)
> Geschäftsführer: Stefan Baur
> Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364
> Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
> 
> _______________________________________________
> x2go-dev mailing list
> x2go-dev@lists.x2go.org
> http://lists.x2go.org/listinfo/x2go-dev

Message #36 received at 1133@bugs.x2go.org (full text, mbox, reply):

From: Mihai Moldovan <ionic@ionic.de>

To: Ted Toal <twtoal@ucdavis.edu>, 1133@bugs.x2go.org

Subject: Re: [X2Go-Dev] Inconsistent Perl used by server or its agent on connect

Date: Wed, 11 Jan 2017 09:58:09 +0100

[Message part 1 (text/plain, inline)]

Control: reassign -1 x2goserver 4.0.1.20

On 11.01.2017 02:48 AM, Ted Toal wrote:
> perl has the -l option for specifying the PERL5LIB path.  That option can, and I think should, be used on the shebang of the x2go perl scripts:
> 
> #!/usr/bin/perl -l /usr/lib/perl5
> 
> or something like that.  I know the shebang line allows args.

If you explicitly break your setup by defining random variables in shell startup
scripts, you'll have to handle the outcome.

Following the same line of original reasoning, users COULD potentially replace
/usr/bin/perl with /bin/false. It's unreasonable to expect stuff to check
whether /usr/bin/perl actually is a Perl interpreter.


In your case, the proper workaround would be to change the perl hashbangs to
"#!/usr/bin/env perl" instead, so that the first matching perl binary in $PATH
is used. I won't change that in x2goserver, though, as we have literally no idea
what users do to their PATH variable (and shouldn't assume.) Note, that this may
still not work, as I vaguely remember at least X2Go Client to export a sane PATH
value before executing any command remotely, though.

If anything, we could explicitly unset PERL5LIB in the client application for
additional sanitation. Would that make sense?



Mihai

[signature.asc (application/pgp-signature, attachment)]

Message #47 received at 1133@bugs.x2go.org (full text, mbox, reply):

From: Stefan Baur <X2Go-ML-1@baur-itcs.de>

To: Ted Toal <twtoal@ucdavis.edu>, 1133@bugs.x2go.org

Subject: Re: [X2Go-Dev] Bug#1133: Bug#1133: Inconsistent Perl used by server or its agent on connect

Date: Wed, 11 Jan 2017 10:05:46 +0100

[Message part 1 (text/plain, inline)]

Control: close -1
thanks

[re-sent as the original message went to Ted's personal mailbox only]

Am 11.01.2017 um 02:48 schrieb Ted Toal:
> > perl has the -l option for specifying the PERL5LIB path.  That
option can, and I think should, be used on the shebang of the x2go perl
scripts:
> >
> > #!/usr/bin/perl -l /usr/lib/perl5
> >
> > or something like that.  I know the shebang line allows args.

Ted,

while we agree that options *can* be used on the shebang line, I
disagree that they should be used in our scripts for specifying
something that *is the default*.
You would, indeed, change the shebang to "#!/usr/bin/perl -T" if you
wanted to run the script in taint mode, which is a non-default setting.

Also, the parameter to set the library path is not -l (lower-case L),
but -I (upper-case i).  I would suggest using a font that displays them
differently, it makes coding a lot easier.

Why explicitly setting the PERL5LIB path in the shebang line is a bad
idea can be shown like this:

First, run
perl -e 'print "@INC\n";'
to display the default.

On my system, this returns:
/etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.20.2
/usr/local/share/perl/5.20.2 /usr/lib/x86_64-linux-gnu/perl5/5.20
/usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.20
/usr/share/perl/5.20 /usr/local/lib/site_perl .

Next, run
perl -I /foo -e 'print "@INC\n";'
which corresponds to setting -I /foo on the shebang line.

On my system, this returns:
/foo /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.20.2
/usr/local/share/perl/5.20.2 /usr/lib/x86_64-linux-gnu/perl5/5.20
/usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.20
/usr/share/perl/5.20 /usr/local/lib/site_perl .

Notice how the search path is extended, not replaced, by /foo ending up
at the beginning.

Now let's see what happens when combining -I *and* a set PERL5LIB variable:
PERL5LIB=/bar perl -I /foo -e 'print "@INC\n";'

This results in:
/foo /bar /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.20.2
/usr/local/share/perl/5.20.2 /usr/lib/x86_64-linux-gnu/perl5/5.20
/usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.20
/usr/share/perl/5.20 /usr/local/lib/site_perl .

You can see that /foo and /bar are added to the search path, with the
value of -I taking precedence, as in being listed and thus searched
first, over PERL5LIB.

And this is exactly NOT what a user expects, even though it would solve
your percieved problem:

Standard Unix practice is that when an environment variable is set, it
should take precedence over any default, and a command line option set
should take precedence over any environment variable.

Adding -I /path/to/libs at the shebang line would break what is expected
behavior.

No one keeps you from running a search and replace on all X2Go-related
scripts after installing them, though ...

However, I would strongly recommend against that and suggest un-setting
PERL5LIB in .bashrc when an X2Go-related bash invocation is detected,
instead.

Why this doesn't work for you the way it does for us is what we're
tracking in Bug #1134, so again, closing this bug.

Kind Regards,
Stefan Baur
-- 
BAUR-ITCS UG (haftungsbeschränkt)
Geschäftsführer: Stefan Baur
Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364
Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243

[signature.asc (application/pgp-signature, attachment)]

Message #52 received at 1133@bugs.x2go.org (full text, mbox, reply):

From: Ted Toal <twtoal@ucdavis.edu>

To: Stefan Baur <X2Go-ML-1@baur-itcs.de>

Cc: 1133@bugs.x2go.org

Subject: Re: [X2Go-Dev] Bug#1133: Bug#1133: Inconsistent Perl used by server or its agent on connect

Date: Wed, 11 Jan 2017 09:41:35 -0800

Sorry for the mixup about lower case l and capital I.  I don’t know that using a different font would have helped in this case.  I had the wrong one specified and you found it and used it despite the font.  Btw, the web site where I found the option (perlmaven.com) also used a font that didn’t distinguish it, which is how it propagated to me.

Perhaps that option on the shebang is not the best way to handle this.  But you are wrong to think that people should not or will not be setting PERL5LIB in their .bashrc.  It is normal practice among Perl users, and in fact I would guess that the majority of Perl users do so.  And that breaks x2go.  x2go should never assume that the environment variables used by a program it is invoking, especially /usr/lib/perl, will be set the way it wants them set, after .bashrc has run.

ted



> On Jan 11, 2017, at 1:05 AM, Stefan Baur <X2Go-ML-1@baur-itcs.de> wrote:
> 
> Control: close -1
> thanks
> 
> [re-sent as the original message went to Ted's personal mailbox only]
> 
> Am 11.01.2017 um 02:48 schrieb Ted Toal:
>>> perl has the -l option for specifying the PERL5LIB path.  That
> option can, and I think should, be used on the shebang of the x2go perl
> scripts:
>>> 
>>> #!/usr/bin/perl -l /usr/lib/perl5
>>> 
>>> or something like that.  I know the shebang line allows args.
> 
> Ted,
> 
> while we agree that options *can* be used on the shebang line, I
> disagree that they should be used in our scripts for specifying
> something that *is the default*.
> You would, indeed, change the shebang to "#!/usr/bin/perl -T" if you
> wanted to run the script in taint mode, which is a non-default setting.
> 
> Also, the parameter to set the library path is not -l (lower-case L),
> but -I (upper-case i).  I would suggest using a font that displays them
> differently, it makes coding a lot easier.
> 
> Why explicitly setting the PERL5LIB path in the shebang line is a bad
> idea can be shown like this:
> 
> First, run
> perl -e 'print "@INC\n";'
> to display the default.
> 
> On my system, this returns:
> /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.20.2
> /usr/local/share/perl/5.20.2 /usr/lib/x86_64-linux-gnu/perl5/5.20
> /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.20
> /usr/share/perl/5.20 /usr/local/lib/site_perl .
> 
> Next, run
> perl -I /foo -e 'print "@INC\n";'
> which corresponds to setting -I /foo on the shebang line.
> 
> On my system, this returns:
> /foo /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.20.2
> /usr/local/share/perl/5.20.2 /usr/lib/x86_64-linux-gnu/perl5/5.20
> /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.20
> /usr/share/perl/5.20 /usr/local/lib/site_perl .
> 
> Notice how the search path is extended, not replaced, by /foo ending up
> at the beginning.
> 
> Now let's see what happens when combining -I *and* a set PERL5LIB variable:
> PERL5LIB=/bar perl -I /foo -e 'print "@INC\n";'
> 
> This results in:
> /foo /bar /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.20.2
> /usr/local/share/perl/5.20.2 /usr/lib/x86_64-linux-gnu/perl5/5.20
> /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.20
> /usr/share/perl/5.20 /usr/local/lib/site_perl .
> 
> You can see that /foo and /bar are added to the search path, with the
> value of -I taking precedence, as in being listed and thus searched
> first, over PERL5LIB.
> 
> And this is exactly NOT what a user expects, even though it would solve
> your percieved problem:
> 
> Standard Unix practice is that when an environment variable is set, it
> should take precedence over any default, and a command line option set
> should take precedence over any environment variable.
> 
> Adding -I /path/to/libs at the shebang line would break what is expected
> behavior.
> 
> No one keeps you from running a search and replace on all X2Go-related
> scripts after installing them, though ...
> 
> However, I would strongly recommend against that and suggest un-setting
> PERL5LIB in .bashrc when an X2Go-related bash invocation is detected,
> instead.
> 
> Why this doesn't work for you the way it does for us is what we're
> tracking in Bug #1134, so again, closing this bug.
> 
> Kind Regards,
> Stefan Baur
> -- 
> BAUR-ITCS UG (haftungsbeschränkt)
> Geschäftsführer: Stefan Baur
> Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364
> Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
> 
> 

Message #57 received at 1133@bugs.x2go.org (full text, mbox, reply):

From: Ted Toal <twtoal@ucdavis.edu>

To: Mihai Moldovan <ionic@ionic.de>

Cc: 1133@bugs.x2go.org

Subject: Re: [X2Go-Dev] Inconsistent Perl used by server or its agent on connect

Date: Wed, 11 Jan 2017 09:52:10 -0800

> If you explicitly break your setup by defining random variables in shell startup
> scripts, you'll have to handle the outcome.
> 

I did not break perl, I replaced perl with a different perl, which involved adding a PATH and changing Perl env. vars.  In a sense, the real problem is that Perl finds its libraries in a stupid way.  But given that it is this way, I don’t know what the best way to deal with this situation is.  Fixing it with ‘if’ statements in .bashrc is a lousy solution, an annoyance to a lot of people.
> 
> If anything, we could explicitly unset PERL5LIB in the client application for
> additional sanitation. Would that make sense?

Yes it would.  But then I don’t know if Perl will still find the libraries it needs.  It might, because it may have the default library paths hard-coded.  I seem to remember reading that Perl puts some paths in place when it is compiled.  Maybe the Active Perl I use was not compiled correctly to get the correct default paths, and if it had been maybe I wouldn’t need to set PERL5LIB.

ted

> 
> 
> Mihai


> On Jan 11, 2017, at 12:58 AM, Mihai Moldovan <ionic@ionic.de> wrote:
> 
> Control: reassign -1 x2goserver 4.0.1.20
> 
> On 11.01.2017 02:48 AM, Ted Toal wrote:
>> perl has the -l option for specifying the PERL5LIB path.  That option can, and I think should, be used on the shebang of the x2go perl scripts:
>> 
>> #!/usr/bin/perl -l /usr/lib/perl5
>> 
>> or something like that.  I know the shebang line allows args.
> 
> If you explicitly break your setup by defining random variables in shell startup
> scripts, you'll have to handle the outcome.
> 
> Following the same line of original reasoning, users COULD potentially replace
> /usr/bin/perl with /bin/false. It's unreasonable to expect stuff to check
> whether /usr/bin/perl actually is a Perl interpreter.
> 
> 
> In your case, the proper workaround would be to change the perl hashbangs to
> "#!/usr/bin/env perl" instead, so that the first matching perl binary in $PATH
> is used. I won't change that in x2goserver, though, as we have literally no idea
> what users do to their PATH variable (and shouldn't assume.) Note, that this may
> still not work, as I vaguely remember at least X2Go Client to export a sane PATH
> value before executing any command remotely, though.
> 
> If anything, we could explicitly unset PERL5LIB in the client application for
> additional sanitation. Would that make sense?
> 
> 
> 
> Mihai
> 

Send a report that this bug log contains spam.