in reply to Unexpected die

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.";

Replies are listed 'Best First'.
Re: Re: Unexpected die
by peschkaj (Pilgrim) on Aug 09, 2002 at 02:41 UTC
    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]

In Section Seekers of Perl Wisdom