> 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 <[email protected]> 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 > _______________________________________________ x2go-dev mailing list [email protected] http://lists.x2go.org/listinfo/x2go-dev
