On 4/10/07, Omari Norman <[EMAIL PROTECTED]> 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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Fish-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fish-users
