On Thu, 15 Dec 2005, Netocrat wrote: > Axel Liljencrantz wrote: > > On Wed, 14 Dec 2005, Harshad wrote: > >>Axel Liljencrantz wrote: > >> > >>>Silly me. An event handler is a command substitution, so that will always > >>>evaulate to true. > >>> > >>>Ok, new approach. Lets' define a cd function. The trouble here is that a > >>>cd wrapper function is already defined, doing things with the directory > >>>history. So we redefine it as __cd_wrapper. Something like this: > >>> > >>>eval (functions cd|sed -e 's/function cd/function __cd_wrapper/')\n > >>>function cd > >>> __cd_wrapper $argv > >>> if status --is-command-substitution > >>> return > >>> end > >>> blah blah blah > >>>end > >> > >>This works. > >> > >>>A bit of a hack, but it could be worse. > > How about: within a command substitution - which afaik is the context > the problematic completion functions are running in - fish automatically > localises PWD in scope as though declared with "set -l PWD" (and thus > events are localised to the command substitution scope).
That is a rather simple and elegant solution. One worth thinking about. I'm worried about unforseen issues, deserves a bit of pondering. > > Based on this premise: since the cd command does not affect the parent > shell, neither should changes to PWD. Seems to fit with your minimalist > principle and avoid the possibility of recursion that Harshad's pointed > out when using events. > > -- > http://members.dodo.com.au/~netocrat > -- Axel ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Fish-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fish-users
