Shell – Why do `env var=value` allow arbitrary name in var

In the unix model, starting another program involves two primivites:

• fork() creates an (almost) identical copy of the calling process. The new process is called the child process and the original process is called the parent process. The child process runs the same code as the original, has the same permissions, has the same environment, and receives a copy of the mutable data memory of the parent process. The most visible difference between the two processes is that they have different process IDs and different parent process IDs (the child's PPID is the parent's PID).
• execve() replaces the code and data of the current process by code and data loaded from an executable file. This system call takes the new environment of the process as an argument.

Most high-level functions built around fork() and execve() pass the process's current environment to execve(). Thus, unless the process changes its own environment or calls execve() directly, the called program will inherit the calling program's environment.

Shells normally pass their environment to the programs they call. You can change the environment of a shell at any time by assigning a value to an environment variable (foo="some value"; you must call export foo if the variable isn't in the environment already), or remove a variable from the environment by unsetting it (unset foo). If you want to start an external program with different or additional environment variables, there is a shortcut syntax:

foo="some value" mycommand

is roughly equivalent to

(foo="some value"; export foo; exec mycommand)

(where the parentheses restrict the scope of the setting of foo).

As you've found, that's spec'd behavior. But it also makes sense.

The value is retained in the shell's environment for the same reason the value of other environment variables are retained by other commands when you prefix definitions to their command-lines - you're setting the variables in their environment.

The special builtins are generally the most intrinsic variety in any shell - eval is essentially an accessible name for the shell's parser, set tracks and configures shell options and shell parameters, return/break/continue trigger loop control flow, trap handles signals, exec opens/closes files. These are all fundamental utilities - and are typically implemented with barely-there wrappers over the meat and potatoes of your shell.

Executing most commands involves some layered environment - a subshell environment (which needn't necessarily be a separate process) - which you don't get when calling the special builtins. So when you set environment for one of these commands you set environment for your shell. Because they basically represent your shell.

But they're not the only commands that retain environment that way - functions do the same as well. And errors behave differently for special built-ins - try cat <doesntexist and then try exec <doesntexist or even just : <doesntexist and while the cat command will complain, the exec or : will kill a POSIX shell. The same is true of expansion errors on their command line. They're the main loop, basically.

These commands don't have to retain environment - some shells wrap their internals up more tightly than others, expose less of the core functionality and add more buffer between the programmer and the interface. These same shells might also tend to be a bit slower than others. Definitely they require a lot of non-standard adjustments to make them to conform to spec. And anyway, it's not as if this is a bad thing:

fn(){ bad_command || return=$some_value return; }

That stuff is easy. How else would you preserve the return of bad_command so simply without having to set a bunch of extra environment and yet still do assignments conditionally?

arg=$1 shift; x=$y unset y

That kinda stuff works too. In place swaps are more simple.

IFS=+  set -- "$IFS" x y z
x="$*" IFS=$1 shift
echo "${x#"$IFS"}" "$*"

+x+y+z x y z

...or...

expand(){
    PS4="$*" set -x "" "$PS4" 
    { $1; }  2>&1
    PS4=$2   set +x
}   2>/dev/null

x='echo kill my computer; $y'
y='haha! just kidding!' expand "${x##*[\`\(]*}"

...is another one I like to use...

echo kill my computer; haha! just kidding!