Best way to set environment variables in calling s

Question

I'm writing a utility that needs to be able to set and use context. I'd like it to use environment variables in the shell so that it can remember what context it's currently in between invocations. Ideally, I'd like to set this environment variable from within the utility itself. Something like:

mytool set-context <context>
mytool do-stuff # Aware of <context>

I'd like this to behave like:

export MYTOOL_CONTEXT=<context>
mytool do-stuff # Aware of <context>

Now, it's not actually possible for a program to set environment variables in the environment of the calling shell (covered on SO here). However, that's the sort of behavior I want, and I'm looking for an approximation or workaround.

Some ideas I had in mind:

• Output the proper string, and expect the user to set the variable (assuming that the variable isn't simply set to <context>, but instead to some string derived from it). That would look something like export MYTOOL_CONTEXT=$(mytool get-context-var <context>).
• Output the full command for setting it. That would look something like $(mytool set-context <context>), where the output of the command is actually executed (and the output would be something like export MYTOOL_CONTEXT=<context>).
• Save to a temporary file whose name is based on the PID of the shell. This would work in most cases, but removing the file wouldn't happen automatically, so it would probably just lie around until reboot (ie, possibly forever on many machines).

Any other ideas? Thanks!

Note: The above examples use BASH syntax, but there are equivalents in most shells.

Answer 1

Before clarification

The POSIX shells (bash, ksh, etc) and the Bourne shell allow you to set environment variables on a command line for one command only:

MYTOOL_CONTEXT=<context> mytool do-stuff

This sets MYTOOL_CONTEXT as an environment variable for that invocation of mytool (only). Incidentally, most shells accept an option -k (which is not standardized by POSIX) that means all arguments that look like VAR=value are treated as environment variables, even when they appear after the command name. This is a curiosity with rather limited practical value, which is why it is not standardized.

The POSIX env command is designed to allow you to control the environment of an invoked command, though it is commonly used without any arguments to list the current environment. So, alternatively, you might use:

env MYTOOL_CONTEXT=<context> mytool do-stuff

The advantage of env is that you can do things like unset every environment variable before setting the ones specified in the command line (so you get total control over the environment).

After clarification

If the intention is to set the environment for subsequent use, then the . command is the one to use. You can create a file, context, which contains commands to be executed to set the environment. Then you can use:

. context

and the contents of the file will executed in the context of the current shell, so you can set environment variables, etc. Bash provides a synonym, source, for the . command. It was inspired by the C shell which does not provide the . command but does provide source as an equivalent. The file named as an argument to the . command will be searched for on $PATH but does not need to be executable (readable is sufficient). If you provide extra arguments, they become the positional parameters ($1, etc) for the duration of the . command. Note too that any variables or functions created by the dotted file remain in effect when the file is finished (unlike variables in a normal script which vanish when the script completes). If you aren't going to pollute the user's name space, you have to be careful.