Honestly, it can’t be more obvious, and it could be worse.

It’s not always possible to use env because temporary assignment works for other builtins, which can then interact with the current shell’s environment.

You need two builtins, one for env and one for assigning to the local shell’s parameters. Some shells are like this and it’s not obvious to me that the experience is better overall. Especially since they still have to be a bit special (if you want to assign to an array, say).

I think it’s basically because shell didn’t start off as a programming language, and you can especially see that around variables. Shell basically started in the early 70’s like this:

ls /tmp | wc -l

It was commands and pipelines.

Now how do you add assignments? How about do it like Python:

x = 42

Well that doesn’t work, because what if it’s

ls = 42

That’s already a command with 2 arguments: the string = and the string 42. This syntax would break too much – we’ve already parsed arbitrary, unquoted strings as commands for years. There is no “syntax error hole” to upgrade the language.

So let’s just put a little hack in the parser, and say that the first word is an assignment if it has an =

ls=42   # this is an assignment

And now how do you bind an env variable for a command? Well you can kinda reuse the same cheesy parser:

ls=42 my-command

So:

1. I split my command into words
2. some of them are key=value words
   • if there’s just one of them, then it’s an assignment statement
   • if there’s a leading key=value, then interpret the rest as a command, run with those env bindings

There are even more hacks added later with:

local a=$x  

local is a special word, with no word splitting on unquoted $x, unlike in rest of shell. But this is not special, there is word splitting

env a=$x

Also, env is external, and local is builtin, but there’s no syntactic indication of that. It’s a mess.

The hacks continue to pile up:

a[i++]=42  # array assignment
a[ i++ ]=42  # weirdly, spaces are accepted in bash

I think it helps to view this from the perspective of: parsing in C is extremely difficult. There is no string type in C.

So all shell implementers, from Thompson to Bourne to Korn to bash, basically took a lot of shortcuts. They created a syntax that was easy to implement in C.

There are some other places you can see this egregiously in bash:

read -t 1.1  # read with timeout 
read -t 0.0  # select() on file descriptor.  It does NOT read !!!

There are no function calls in bash, like strftime() or quoteShellString, so you can just hide functionality inside printf

printf %q "$str"  # extremely useful shell quoting that is hidden
printf %b "$str"  # extremely useful shell dequoting that is hidden

And

printf '%T(Y-m-d)' 12345    # useful strftime that is hidden
printf '%T(Y-m-d)' -1    # -1 is a hidden current time
printf '%T(Y-m-d)' -2    # time the shell was invoked

And

printf -v myvar '%f' 3.14   # assign to variable

myvar=$(printf '%f' 3.14)  # -v is a way to avoid this subshell

In a real language you would write these like:

shellQuote()       
shellEval()

strftime('Y-m-d', 12345)
strftime('Y-m-d', time())
strftime('Y-m-d', shellStartTime())

And

myvar = '%f' % 3.14

https://www.gnu.org/software/bash/manual/bash.html

So basically, shell syntax has “topped out” in C. But they need more features, like formatting strings, and assigning a formatted string without a command sub.

So they just add a bunch of functionality without regard to whether it’s a readable or intuitive syntax. They just add magic -1 and -2 and 0.0 values, because you can hack that in quickly.

https://www.oilshell.org fixes this – we have real parsing, real expressions with functions, and structured data.

But ls /tmp | wc -l still works exactly the same way!