To load environment variables you've put into a file, you can use the source command. e.g.
See current path:
> echo $PATH
/bin:/usr/bin:/usr/local/bin:/sbin:/usr/sbin
File with custom environment settings..
> cat exports
export PATH="/home/me/bfin2012:$PATH"
export ...
Load custom environment
> source exports
Confirm changes.
> env | grep '^PATH'
PATH=/home/me/bin2012:/bin:/usr/bin:/usr/local/bin:/sbin:/usr/sbin
The environment is a list of strings of the form var=value (by convention) that is passed as the 3rd argument to the execve() system call.
That list is put somewhere on the stack of the process when it starts to execute the new command just like for the list of arguments (another list of strings passed as the second argument to execve()).
In programs using the libc (most), an initialisation code called before the main() function is invoked, makes those environment strings available as the environ array.
The libc also provides with putenv and setenv functions that can modify (a copy of) that list that the program received. That maintained, modified copy will then be passed to the next command executed by the process or any of its children via the execvp()/execl()/system()/popen()... functions of the libc (which themselves end up calling the execve() system call).
Now while when you build up a list of strings that you pass manually to the execve() system call, you may pass strings like foo (without a = character) or =bar (with an empty variable name), setenv won't let you do that (setenv("", "bar", 1) is rejected).
setenv("a=b", "c") will also be rejected. So the strings that will be defined by setenv will always be of the format x=y where x may not be empty.
That's about the only restriction (also applied by putenv). Well those being NUL terminated strings, of course the NUL character cannot appear in the variable name or value.
setenv("*", "x", 1), or setenv("\n\n", "", 1) are all OK as far as setenv() or the kernel are concerned. Now, whether you're going to be able to do anything useful with those is another matter.
Best Answer
Where to set environment variables is covered in What's the best distro/shell-agnostic way to set environment variables?
Regarding naming, the main reason to set environment variables is because an application uses them, so you don't get to choose the name.
There is no concept of namespaces for environment variables. The closest thing is to pick a prefix, generally of the form
SOMETHING_(i.e. the prefix ends with an underscore and you have variablesSOMETHING_FOO,SOMETHING_BAR, …). But most variables aren't for a specific application, but rather a family of applications. If a variable is only meaningful in one application, it should generally be a command line option. So there isn't much need for namespaces.If you're defining variables only for use on the command line, then don't use environment variables, use shell variables. (See Difference between environment variables and exported environment variables in bash) If you define a variable in a shell script and you don't use
export, that's a shell variable, not an environment variable, and it's only visible in the shell where you defined them. So if you're defining a variable for use on the command line:~/.bashrcfor bash,~/.zshrcfor zsh,~/.config/fish/config.fishfor fish).exportit.For your own use, pick whatever names you like, as long as they don't conflict with environment variables that you use (environment variables are automatically imported as shell variables). I don't recommend an initial underscore because that's what bash and zsh's completion systems use internally.