in reply to replicating the command 'unset LIBPATH' in perl

system('unset LIBPATH'); doesn't work since unset is a shell command, not a program.

system(q{sh -c 'unset LIBPATH'}); would run the shell command, but it would uselessly change the environment of a shell that exits immediately afterwards.

You want to change the current process's environment. delete $ENV{LIBPATH}; is the way to go. If it doesn't work, maybe because it's being done too late. Try putting it in a BEGIN {} block as near the top of your script as you can.

Replies are listed 'Best First'.
Re^2: replicating the command 'unset LIBPATH' in perl
by viffer (Beadle) on May 18, 2010 at 05:03 UTC
    Thanks for pointing out that unset is a shell command. I come from a mainframe background (please don't laugh) and will readilly admit to getting thoroughly confused between the various shells etc. I had tried the 
    delete $ENV{LIBPATH}

    [download]
    and it's right near the top of script.

    The weird thing is, that whilst it does replicate the unset command on going into the called routine, unlike the unset command it still causes a 'Total Environment allocation failure'.

    I realize this is now getting off of perl per se and more into shell commands - but I beg your indulgence, does 'unset LIBPATH' do anything other than delete the path?

    I did a comparison of env before and after issuing the command, and aside of the LIBPATH no longer being present, the only other difference was addition of the phrase "SHLVL=1".

    Appreciate your time in responding.

[reply]
[d/l]

      I had tried the delete $ENV{LIBPATH} and it's right near the top of script.

      You missed the part about using BEGIN. The idea is to execute it before any use statements are executed, and you'll need BEGIN for that. 

      BEGIN { delete $ENV{LIBPATH} }

      [download]
[reply]
[d/l]
[select]
        Again thanks. I have put it in a BEGIN statement - and again, whilst it does appear to unset the libpath, it doesn't enable me to connect to the database. The *only* command that seems to work is running unset LIBPATH prior to running the script.

        It would seem the super user account has the db2profile as default environment.

        It runs both applications which require db2inst1 profile (db2 v8) and db2inst2 profile (db2 v9).

        The thought is now to consider setting db2profile env before app start and not having db2profile in the super user profile - although the person charged with doing that seems overly reticent (without giving his reasons) to do it.

        Cheers for your help

[reply]

In Section Seekers of Perl Wisdom