Re: Setting $path variable

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

On Aug 19,  2:55pm, Bruce Stephens wrote:
} Subject: Re: Setting $path variable
}
} > zsh 2.5.0 did not do this. Should we really change this behaviour?
} 
} ("path=$path" losing arrayness of path.)  Don't know.  I must confess
} it seems more intuitive for a simple assignment of this kind to keep
} arrays as arrays, but I assume there are reasons for the current
} behaviour.  Does this relate in some way to sh_word_split?

It relates to this (from Etc/NEWS in the dist):

 The right-hand side of assignments are no longer globbed by default hence
 assignment foo=* will assign '*' as a value of foo.  Use the foo=( * )
 array assignment syntax to get the old behaviour.  Alternatively the
 GLOB_ASSIGN can be set to emulate the old behaviour but the usage of this
 option is strongly discouraged and this option may be completely removed in
 the future.

However, due to the usual zsh rules about variable expansions, path=$path
is not treated as a glob, and there's no combination of option settings
that can cause it to be so treated.  So there's no way to get back the
"preserve arrayness" behavior when the RHS is a variable reference.

There does, however, seem to be some bad interaction among glob_subst and
glob_assign:

zsh% setopt shwordsplit globsubst globassign
zsh% foo=(1 \* 2)
zsh% foo=$foo
zsh: no match

Seems to me that foo should have been word-split before it was globbed
(with or without shwordsplit, since it started out as an array), and
that because it was globbed it should have been glob_assign'd (and this
should probably be true even if there are no actual glob patterns in
the value of foo, as long as glob_subst is set).

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"