Re: [Fish-users] How do array environment variables (like PATH) work?

On 4/10/07, Omari Norman <om...@sm...> wrote:
> Hi all,
>
> I'm a new Fish user; it looks promising. The documentation is actually readable!

Happy to hear you like fish!

> I am wondering how array environment variables, like PATH, work.
> Specifically I wonder how they are stored and how they are
> communicated to other processes when they are exported. For example,
> when I fire up Python, I see that any array variables I exported from
> Fish are colon-delimeted. That is, if I do
>
> set -x listvar hello hello2
>
> it seems the value of this as seen by other processes is that listvar
> is a string, equal to 'hello:hello2'. The same is true if I export
> listvar to bash. It is just UNIX convention to delimit these sorts of
> variables with colons? Does fish hide this from the user?

Fish has native support for arrays internally. In fact, all variables
are arrays. An empty variable is really a zero element array, and a
string varialbe is really a one element array. Fish does not
internally treat the colon character differently from other
characters. You can verify this by trying to create a variable
containing a colon character:

$ set arrtest foo:bar
$ echo $arrtest
foo:bar

The problems (and the colons) appear when fish exports variables to
other programs - other programs do not support environment variable
arrays, so fish resolves this as best as it can by concatinating array
elements together using the colon. The reson why fish does things this
way is so that colon-delimited lists like PATH, CDPATH, CLASSPATH,
LDPATH, etc. will transparently work. If fish did not do this, it
would be neccesary  to invent some other mechanism to transform all
these variables from the native array representation they have in fish
into the colon-delimited format other programs expect.

Other shells seem to solve this problem by simply refusing to export
arrays. zsh can also create magical variable aliases, so that there is
both a PATH variable and a path array that always hold the same value
but in different formats. I find the fish approach to be a better
balance between useful, simple and intuitive behaviour, though it is
still obviously a hack to work around the basic problem that
environment variables are not arrays.

Also note that fish does the reverse colon to array mapping on
startup. Variables containing colons are taken to actually be
colon-separated lists, and are transformed into fish arrays. This
might seem a bit scary, but it is a safe operation, since the results
are 100 % reversible - the altered state is only visible in fish,

> Also I noticed that in fish, 'echo $listvar' yields 'hello hello2'. In
> bash, the same command (whether with the bash builtin or with
> /bin/echo; I like fish's principle of stripping out the unnecessary
> builtins) yields 'hello:hello2'. Why the difference?

If you use an array variable without specifying any indices, then the
array will be expanded into one argument for every array element. This
makes it trivial to iterate over an array:

for i in $PATH; ...; end

Since the bash variable in your example is not a real list variable,
you would have to write something like 'for i in $(echo $PATH|tr :
$'\n'); do ...; done' to get the same effect.

I hope this makes things clearer. If not, feel free to ask again. If
you have suggestions on how the documentation could be reorganized,
rewritten or otherwise updated, feel free to submit updates and
suggestions.

> Thanks,
> Omari

-- 
Axel