Support FOO=bar syntax for passing variables to individual commands

[krobelus]

This adds initial support for statements with prefixed variable assignments.
Statments like this are supported:

a=1 b=$a echo $b # outputs 1

Just like in other shells, the left-hand side of each assignment must
be a valid variable identifier (no quoting/escaping). Array indexing
(PATH[1]=/bin ls $PATH) is not yet supported, but can be added fairly
easily.

The right hand side may be any valid string token, like a command
substitution, or a brace expansion.

Since a=* foo is equivalent to begin set -lx a *; foo; end,
the assignment, like set, uses nullglob behavior, e.g. below command
can safely be used to check if a directory is empty.

x=/nothing/{,.}* test (count $x) -eq 0

Generic file completion is done after the equal sign, so for example
pressing tab after something like HOME=/ completes files in the
root directory
Subcommand completion works, so something like
GIT_DIR=repo.git and command git correctly calls git completions
(but the git completion does not use the variable as of now).

The variable assignment is highlighted like an argument.

Closes #6048

---

TODOs:

• Changes to fish usage are reflected in user documentation/manpages.
• Tests have been added for regressions fixed
• User-visible changes noted in CHANGELOG.md

Follow-ups:

• Figure out what to do for bare a=b
• Figure out if export should work the same way

[faho]

The FAQ contains a question about this that would have to be removed.

How do I set an environment variable for just one command?

[zanchey]

Rather than removing the entry, what about changing it to "Since fish 3.x, the SOME_VAR=1 command syntax can be used, like other shells."?

[krobelus]

I added this to the first FAQ entry, that should make sense but feel free to change it.

[faho]

A question is how we should handle bare "VAR=VALUE" without any command.

Should we actually support foo=bar in addition to set? Or should we specifically block that?

[zx8]

Given the fact that fish already "supports" export FOO=bar syntax (albeit via a horrible hack) to help newcomers transition to fish, my opinion is that we should support bare var=val syntax, purely for convenience.

I often find myself following guides, studying online courses, or simply being sent shell snippets from colleagues that assume bare var=val syntax exists, and it's cumbersome having to manually change them all to set var val, when the script would otherwise have worked verbatim.

[krobelus]

Adding support for var=val seems reasonable to make fish more copy-paste friendly. Its use in scripts should probably be discouraged.

We also need to settle on what to do when the value expands to multiple elements.
Which probably happens in a quite small minority of all uses but the current behavior in this branch is inconsistent:

$ export a=(printf 1\n2\n); printf %s, $a
2,
$ a=(printf 1\n2\n) printf %s, $a
1,2,

[zanchey]

My problem with bare FOO=bar being equivalent to set FOO bar is that it is internally inconsistent - bare it produces a persistent (non-exported) shell variable, but combined with a command it is exported and limited only to that command.

[ridiculousfish]

Overall this is really fantastic - fits in nicely and well designed. This is thrilling!

I haven't fully finished reviewing the execution part yet; I expect it to change a bit if we take the grammar simplification which I suggest.

[ridiculousfish]

Looks great! Merge as you like.

I don't have any strong feelings about the behavior of bare FOO=var but we should at least improve the error message, which is currently:

foo=bar
fish: Expected a command, but instead found end of the statement
foo=bar
        ^

[lilyball]

I'm not in a position to build fish at the moment, but one question that I don't think was raised in the original ticket: What's the behavior of

a=foo b=$a echo $b

Is b set to foo or is it set to the previous value of a from before this statement?

[krobelus]

a=foo b=$a echo $b prints foo, not the previous value of $a