This switches quoted expansion like "$foo" to use foo's delimiter instead of
space. The delimiter is space for normal variables and colonf or path variables.
Expansions like "$PATH" will now expand using ':'.
This commit begins to bake in a notion of path-style variables.
Prior to this fix, fish would export arrays as ASCII record separator
delimited, except for a whitelist (PATH, CDPATH, MANPATH). This is
surprising and awkward for other programs to deal with, and there's no way
to get similar behavior for other variables like GOPATH or LD_LIBRARY_PATH.
This commit does the following:
1. Exports all arrays as colon delimited strings, instead of RS.
2. Introduces a notion of "path variable." A path variable will be
"colon-delimited" which means it gets colon-separated in quoted expansion,
and automatically splits on colons. In this commit we only do the exporting
part.
Colons are not escaped in exporting; this is deliberate to support uses
like
`set -x PYTHONPATH "/foo:/bar"`
which ought to work (and already do, we don't want to make a compat break
here).
Prior to this fix, if you exported a variable in one scope
and then unexported it in the next, it would remain exported.
Example:
set -gx VAR 1
function foo; set -l VAR; env; end
foo
Here 'VAR' would be exported to 'env' because we failed to
notice that the env var is shadowed by an unexported variable.
This occurred at env var computation time, not in env_set!
Fixes#2132
Prior to this change, inherited environment variables
would be split on colons, becoming an array. This change
eliminates that behavior. Now environment variables are
always split on the record separator character (ASCII 0x1e),
with the exception of a short whitelist of PATH, MANPATH,
CDPATH. Likewise, exported variables are also exported
delimited by rs, with the exception of the above whitelist.
Fixes#1374, also see #1656
We can't use $PATHS to test the :-splitting because the global config
file adds extra paths based on /etc/paths and /etc/paths.d.
Ideally fish would have a way to suppress behavior like that, but for
the time being it doesn't.
`exec` removes fish from the shell "stack", so SHLVL needs to be
decremented to match. This means `exec fish` will result in the same
SHLVL in the new fish instance.
Also tweak the SHLVL logic to interpret an environment SHLVL of "3foo"
as garbage instead of as the value "3".
Fixes#1693.
