On Jan 8, 2008 11:33 PM, Isaac Dupree <[EMAIL PROTECTED]> wrote: > 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.
Maybe it's a language thing. In swedish you'd use the word överskugga in this situation, meaning 'to cover something in shadow'. To me, it is very visual and intuitive. > > > >> 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 > Ah, ok. Do you think this behavior is wrong? > > > > >> (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. Yes, that is how the other fish builtins do it as well. [...] > >>>> 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. I just realised you can actually do this already. You can already specify different locations for the system files and the site specific config files using switches to the configure script. You can use the XDG_CONFIG_HOME directory to specify a new location for the user specific config files. You can use the FISHD_SOCKET_DIR environment varialbe to specify the filename for the fishd socket file. That should as far as I can see cover every single file. And here I though fish didn't offer that many configuration options. > 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. No, it is because I'm a klutz that can't remember to hit 'reply to all' instead of 'reply to', no matter how many times I screw up. :) Axel > > ~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
