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