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