peschkaj has asked for the wisdom of the Perl Monks concerning the following question:

I'm trying to write a script to setup environment variables depending on which environment the user wants to be in. However, it dies at the final line of code with this: 
Can't exec ". /opt/lnpsite/nm02/scripts/setup_env": No such file or di
+rectory at ./opSet.pl line 27, <STDIN> line 1.
Cannot execute . /opt/lnpsite/nm02/scripts/setup_env: No such file or 
+directory

[download]

I'm not entirely sure why the code is dropping out there because I was able to copy and paste the "non-existant" directory and run it from the command line.

Anyway, here is the code. I cannot seem to figure out why it is not running.

#!/opt/perl5/bin/perl -w

use strict;

my @instances; my $i = 1;
my $selection = 0;

opendir OPHOME, "/opt/lnpsite" or die "Can't open /opt/lnpsite: $!\n";
my @files = sort(readdir(OPHOME));

foreach(@files){
    if (m/(op|nm)\d{2}$/) {
        push(@instances, $_);
    }
}
print "\nAvailable Instances";
print "\n===================\n";
foreach(@instances) {
    print "  $i. ",$_,"\n"; $i++;
}
print "\nSelect an instance and press enter: ";

$selection = <STDIN>; chomp($selection);
$selection = $selection - 1;
my $conn = ". /opt/lnpsite/" . $instances[$selection] . "/scripts/setu
+p_env";
print "$conn\n";
exec $conn $instances[$selection] or die "Cannot execute $conn: $!\n";

[download]

Replies are listed 'Best First'.
Re: Unexpected die
by sauoq (Abbot) on Aug 08, 2002 at 19:34 UTC
    This code is broken in a couple of ways. First, I understand you are trying to source the file (with the shell builtin ".") in order to set the environment. You are, for some unknown reason, trying to do that by running $instances[$selection] and telling it that it's name is $conn. (At least I suspect so given the lack of a comma between your arguments to exec.)

    That won't work.

    Even if it did, it would fail to work in the way you want. The exec would replace the perl process with a shell that runs that source command. In that shell, the environment would be like you want. But that shell would be a child of the invoking shell and although children can inherit an environment from their parent (if the parent exports) it doesn't work the other way around.

    You'd need perl to exec a new login shell and specify an initialization file for it. That would get you closer to what you want but the shell that invoked perl in the first place would still be there underneath everything. So, your users would have to exit both shells. That is unless you ran this script as the login shell.

    Good luck! 

    -sauoq
"My two cents aren't worth a dime.";
[reply]
[d/l]
[select]
      What I was attempting to do is exec $conn and pass $instance$selection as the parameter. Typically the script is run thus: . /opt/lnpsite/nm01/scripts/setup_env nm01

      The intention was to get the perl to run during .profile and allow the user to establish the current environment variables via setup_env (whilst detecting for cron, which is in another post). I thought, perhaps mistakenly, that exec() would drop out of the perl script and execute the command provided.

      Thank you for the input thus far. I hope I do not have to concede to a co-worker who insists that this can be done with C or a k-shell.
[reply]
[d/l]
        Having thought a little more about this (and pondering the other replies)... how about this (untested):
        • have .profile execute a perl script of your own design
        • the perl script presents choices, requests a response, checks that the response is valid
        • based on the response, create a copy of (or symlink to) the selected setup_env file in the user's home directory , e.g. as $HOME/.chosen_setup_env
        • after the perl program exits, .profile goes on to source $HOME/.chosen_setup_env

        The point is that, as far as .profile is concerned, the environment settings are always provided by the same file that it finds in each person's $HOME; you just need the perl script to allow people to control what that file contains (or what it points to) at login time.

        This might have a nice side effect: folks who want to use the same environment file as last time could just reply to the perl script with an empty line (just hit <return>). The perl script only needs to create a new one when the user specifies a particular choice (or when the user doesn't have a .chosen_env yet).

[reply]
        What I was attempting to do is exec $conn and pass $instance[$selection] as the parameter. [edited for readability]

        Well, you'd need quotes around the whole thing then:

        exec "$conn $instance[$selection]"

        But it still won't do what you want. The real issue is how the shell uses subprocesses. The actual login shell is executing the .profile, so you could write your menuing code directly into it for the affect you want.

        When you spawn perl (or even another shell script,) however, it's a completely different process with its own environment. When you call exec with a single string argument like that, it starts a subshell. You can source a file in that subshell using the shell builtin "." but the results of it won't make it back into the parent (login) shell.

        A way around it, if you really feel you must use perl, might be to have perl print the appropriate shell commands and then, in the .profile, you might exec the output that perl gives you. One way or the other though, you've got to either get the login shell to set the environment for you or you have to replace the login shell with another shell that sets the environment appropriately. Both of those options amount to the same thing.

        Update: The reply by graff below shows another way of getting the shell to use perl's output to set its own environment. It's a fine solution. 

        -sauoq
"My two cents aren't worth a dime.";
[reply]
[d/l]
[select]
Re: Unexpected die
by DamnDirtyApe (Curate) on Aug 08, 2002 at 19:10 UTC

    You have a space following the dot in your $conn string, which I strongly suspect is contributing to breaking your code.


    _______________
    DamnDirtyApe 
    Those who know that they are profound strive for clarity. Those who
would like to seem profound to the crowd strive for obscurity.
            --Friedrich Nietzsche
[reply]
[d/l]
      Actually, it appears that "/opt/..." is intended to be an absolute path for job that is being passed to "exec", in which case, based on looking at the error reports, the initial dot should probably not be there at all -- the exec call seems to be treating "<dot><space>/opt/..." as an actual path name, which obviously cannot exist.

      update: Also, I think sauoq is quite right: if the "setup_env" file being exec'd is just going to exit after making its various environment settings, those settings will disappear when it exits, having no effect on the shell that ran this perl script.

      Your only recourse for switching environment settings is to know which setup_env file you want, and source (or dot) that file directly at the prompt of your current interactive shell.

      Presumably, you can write a shell script that lists a set of choices, accepts input from the keyboard, and sources the chosen file. If the user sources this shell script, and answers the prompt correctly, the intended environment settings will take effect in the current interactive shell: 

      $ cat s1.sh
export FOO=BAR

$ cat s2.sh
export FOO=BAZ

$ cat test.sh
ls s?.sh
echo -n which one :
read j
source $j

$ source test.sh
s1.sh  s2.sh
which one :s1.sh

$ echo $FOO
BAR

$ source test.sh
s1.sh  s2.sh
which one :s2.sh

# echo $FOO
BAZ

      [download]

      Sorry, but I don't see any other way to do it (shell just ain't like perl).

      ANOTHER update: I take that back. There is a way to do it. See another reply of mine, further down in this thread.

[reply]
[d/l]

Back to Seekers of Perl Wisdom