Axel Liljencrantz wrote: > On Jan 8, 2008 6:09 PM, Isaac Dupree <[EMAIL PROTECTED]> wrote: >> Axel Liljencrantz wrote: >>> Ok, once again fish is a bit too eager to set up default variables. >>> >>> Fixed, fish now only tries to set CDPATH _once_. If you drop it, fish >>> won't recreate it. >> okay, seems good >> >>>>>> Eventually I remembered universal variables and >>>>>> checked 'echo $CDPATH' (why??), 'type CDPATH'(didn't work), `set -U` and >>>>>> look through the list for CDPATH, and I found it, so then I did `set >>>>>> CDPATH .` and it was fixed. >>>>>> >>>>> I'm not sure what the '(why?)' referrs to. You obviously feel >>>>> something is done badly. Could you explain? >>>> I don't remember... maybe wondering why I had the bright idea to look at >>>> CDPATH. Is there some more straightforwards way to look at a >>>> particularly-named variable in fish (e.g. CDPATH or PATH) and find out >>>> what properties it has, rather than looking through lists. >>> Not really. Something like this might make sense: >>> #set -Q CDPATH >>> CDPATH is a global variable with the value '.' >>> CDPATH is a universal variable with the value '.' '~' >>> >>> Note how in the example above, there are two variables named CDPATH, >>> with the global definition shadowing the universal one. >> that would be nice (I wonder if it's obvious/well-known enough which >> versions of the variable shadow which other versions -- and what if only >> some of the versions are exported to subshells?) > > If a variable is exported should be mentioned as well. > > I can't really think of a nice hint to shadowing, suggestions are welcome.
I meant that what if, say there's a -Ux and a -gu variable... apparently the search for an exported one will find a universal variable if it has to; there's no way to make a "not defined" -gx variable that overrides a "defined to some value" -Ux variable in subprocesses. how about #set -Q CDPATH CDPATH is a global non-exported variable with the value '.' hiding a universal non-exported variable with the value '.' '~' on the other hand, as I was mentioning, sometimes in the same given scope, one variable is used in fish and another one in subprocesses. (but then, for local variables, one version is used there and another in called functions, too.) So in CDPATH is a global non-exported variable with the value '.' hiding a universal exported variable with the value '.' '~' "hiding" might be a bit misleading. maybe "currently hiding" or "presently hiding". Let's try a complicated example. CDPATH is a local variable non-exported variable with the value '/usr' currently hiding a global non-exported variable with the value '.' currently hiding a universal exported variable with the value '.' '~' (since local variables can't be exported, don't mention their e -- oh wait, they can be exported, nice! It's a pity there's no way to set the current directory locally like that (neither in fish nor `env`), since it's a very similar operation -- the main difference being that it can fail. and that it can prevent a directory from being deleted.) oh, this thing in the `set` documentation as well as the Environment Variables documentation under "Exporting variables", didn't make any sense "If a variable is not explicitly set to be either global or local and has never before been defined, the variable will not be exported." Finally I realized it meant "either exported or not exported", not "either global or local", which actually makes sense, meaning the same thing as "Otherwise, the variable will not be exported" but clearer ... copy-and-paste-o, I guess? >> When it's really important to do weird things (like locally unsetting a >> variable for subprocesses), env can be used... although... it doesn't >> work for functions. (I bet it would be possible, though, to export >> functions by putting them in a directory somewhere and adding that >> directory to the beginning (or end) of PATH, (coordinating, possibly via >> fishd, as necessary). Then 'sudo ll' could work when ll is a >> function... oh wait, sudo in particular tries to limit how much of your >> environment it carries over, so that might not work) > > Also, keep in mind that universal varaibles are per user, so you can't > set universal variables for another user. but "user"s take work to create and require admin powers. I wish there was perhaps some environment variable so I could do 'env FISH_HOME_DIR=some_other_place fish-version' and get a separate bunch of fish shells. Although, that might be not useful compared to the cost of confusion and of finding a reasonable way to make it happen. ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Fish-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fish-users
