Axel Liljencrantz wrote: >>> 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. > > True, there are theoretical uses for an 'anti-definition'. Not going > to implement this until I see a sound real-world case where it is > really desirable, but I'm not ruing out that that can happen. > >> how about >> #set -Q CDPATH >> CDPATH is a global non-exported variable with the value '.' >> hiding a universal non-exported variable with the value '.' '~' > > Heh, that was simple. I like the term 'shadowing' more than 'hiding' > or 'currently hiding', though.
maybe.. it just seems a little technical and slightly not obvious what it means, to me. But maybe it's fine, and probably conveys the "currently" bit well enough. > >> 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. > > How do you mean this? ]set -Ux test1 abc ]set -gu test1 def ]echo $test1 def ]sh -c 'echo $test1' abc > >> (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.) > > I've been contemplating implementing something like a --local switch > to cd, which would change directory and change back when the current > block goes out of scope. Should be rather usable. --local/-l, sounds good. how to cd to a directory named that? well, ./, but I think cd should recognize the -- convention. It already recognizes --help (which is spuriously shown in red), so if you want to cd to "--help" I'm suggesting "cd -- --help" (among other means: "--help" if there's no executable named that; "cd ./--help" if it doesn't have to be found on CDPATH) should work. say... the command "--help" should probably give help on what the meaning of putting something there is (i.e. execute command or cd). Hmm, "./bin/ --help" seems to just ignore the parameter and cd to the directory, which is a little odd. > >> 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? > > Oops. Fixed. Thanks. > >> >>>> 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. > > Wouldn't it be better to set up a separate admin account to sudo into? For example, I might not even have root access (although I do) (I mean, I run as a normal user normally, and sudo when I need privileges). And I might want to test a development version of fish without endangering the stability of all my terminal windows, certainly without using root privileges, and preferably in the same general environment as the rest of my user directory so I can try using it practically. P.S. is it intentional not cc:ing to list? I tend to be in the habit of keeping discussions on-list unless there's a good reason not to, so that more people can see (potentially learn from or contribute to) the discussion process, it can be archived for later reference, etc. ~Isaac ------------------------------------------------------------------------- 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
