• 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).

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