Axel Liljencrantz wrote: > On Jan 2, 2008 2:13 PM, Isaac Dupree <[EMAIL PROTECTED]> wrote: >> in fact there are two confusing things, though I figured them out >> eventually, that perhaps fish could be more helpful about >> >> 1. when '.' is not *first in CDPATH*, 'cd ..' doesn't work as expected >> -- it cd's from whatever the first thing in CDPATH is. > > Hmm, this is a bit of a misfeature, I'll admit. Will fix.
I guess the expected behavior is that paths like './x' and '..' ignore CDPATH and are just relative to the cwd, the same way those paths ignore PATH? such that only relative paths that don't have '.' or '..' as their first component take path-environment into account? e.g. (these are my intuitive guesses: I think bash may not agree with me on looking for "xyz/abc" in PATH nor in the current directory, for executing it) path: xyz .xyz xyz/abc .xyz/../abc/. ..xyz (it's possible to start a filename with any number of dots...) no-path: / ~ ./xyz ../xyz . .. >> And CDPATH seems >> to be treated as a universal variable even though I didn't tell fish to >> do this, so, even though I commented out setting CDPATH in >> .config/fish/config.fish, and opened a new terminal window, 'cd' still >> behaved very oddly. > > The default fish init scripts create a universal CDPAth variable for > you. CDPATH is not treated differently than any other variables. If > you want to remove it, type 'set -e CDPATH' and you should be all set. > I've updated the documentation to mention this. that works for a little while... and seems to be equivalent to CDPATH being '.'. However, when I open a new shell, CDPATH is back again in all my shells, in fact different before. Presumably this is because of the mentioned init-scripts which do 'set_default CDPATH . ~'. I guess keeping a universal CDPATH of '.' and allowing some fish shells to override it with a global (possibly via config.fish) (I forget if that's possible) might work. (or maybe there's some way for the init-scripts to recognize when it's deliberately been removed, after installing -U CDPATH just for the first time? or wait, CDPATH isn't exported, but there could be a time when it was important to be... or just use `env CDPATH=value command args` > >> 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. CDPATH is the only non-fish-specific variable that is universal by default, and I wasn't expecting it to be, and I don't see a particularly good reason for it to be universal (unless you want to make a lot of other standard variables universal?) -- this changed the consistent shell semantics I was expecting, (where I thought universal variables were a feature I could take advantage of where I wanted to, not something I'd have to figure out how to work around, although the latter really is always a risk of having excessively-global mutable variables in any language) > Heh. > > If you start fish from the commandline in a specific directory, you > want to remain in that directory after startup. yep, I realized this... it makes it less obvious what to do. Merely setting it for interactive shells is probably too much, yet that's what I was doing for bash-like shells, so it must not be too bad... > This conflicts with > the assumptions some people have when writing startup scripts that the > cwd is ~. Fish solves this by cd:ind to ~, calling the startup scripts > and the cd back to wherever cwd was before the startup scripts. > > This unfortunatly makes your rather sane and reasonable expectations > fail. Perhaps it would be a better tradeof to never change the cwd and > let broken startup scripts fail? actually they don't execute in '~', but in '~/.config/fish' (on my fish anyway) (I guess this makes broken startup scripts fail immediately, so their owners can fix them without getting too confused usually). I guess it would be a little more consistent to just execute them without messing with the cwd (which would basically solve my problem... I guess I would say "if we're interactive and in ~, go to my preferred directory", which seems pretty safe). -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
