From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-request@math.gatech.edu>
Received: (qmail 12470 invoked from network); 18 Nov 1998 09:12:10 -0000
Received: from math.gatech.edu (list@130.207.146.50)
  by ns1.primenet.com.au with SMTP; 18 Nov 1998 09:12:10 -0000
Received: (from list@localhost)
	by math.gatech.edu (8.9.1/8.9.1) id EAA15033;
	Wed, 18 Nov 1998 04:11:25 -0500 (EST)
Resent-Date: Wed, 18 Nov 1998 04:11:25 -0500 (EST)
Date: Wed, 18 Nov 1998 10:09:34 +0100 (MET)
Message-Id: <199811180909.KAA14049@beta.informatik.hu-berlin.de>
From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@math.gatech.edu
In-reply-to: Phil Pennock's message of Sun, 15 Nov 1998 03:01:58 +0000 (GMT)
Subject: Re: bug 3.1.5 symlinks & cd
Resent-Message-ID: <"4Dwo11.0.ng3.zyeKs"@math>
Resent-From: zsh-workers@math.gatech.edu
X-Mailing-List: <zsh-workers@math.gatech.edu> archive/latest/4668
X-Loop: zsh-workers@math.gatech.edu
Precedence: list
Resent-Sender: zsh-workers-request@math.gatech.edu


Phil Pennock wrote:

> 
> Typing away merrily, Bart Schaefer produced the immortal words:
> > On Nov 13,  9:19pm, Phil Pennock wrote:
> > } Using a stock zsh-3.1.5, there seems to be some problem with completion
> > } using one interpretation of a directory tree with symlinks, and cd using
> > } another.
> > 
> > This isn't new.  It behaves the same way in 3.0.5.  `setopt chaselinks'
> > will make the effect go away.
> 
> Yes, but:
>        CHASE_LINKS (-w)
>               Resolve symbolic links to their  true  values  when
>               changing directory.
> 
> The 'effect' only goes away insofar as this avoids the problem by never
> having a symbolic-link as part of PWD.
> 
> If you want to have the 'real' view of a layout, fine.  But forcing this
> option just to get a consistent interpretation of the FS dodges the fact
> that two different parts of the shell are taking differing approaches to
> symbolic-links pointing to directories.  Completion ignores the symbolic
> aspect of PWD, such that a ../ always uses the underlying 'true' layout,
> whilst cd handles the symbolic links.  This is a conflict that's
> entirely due to two parts of zsh doing things very differently.

I agree that this is a ugliness. But (as I already wrote) the only way 
I see to fix this cleanly is to add yet another option for compctl to
make -f, -g, and -/ use CHASELINKS. On the other hand, this is a bit
of an overkill considering that this would be useful only for cd and
the like.
A (partial) solution is to use a shell function, like this:

  compctl -K cdcomp -S/ -q cd pushd

  cdcomp() {
        local d r
        if [[ "$1" == */* ]]
        then
                d="${1%%/*}"
                r="${1#*/}"
                cd "$d" >& /dev/null
                reply=( ${r}*${2}(N-/) )
                reply=( $d/$reply )
                cd - >& /dev/null
        else
                reply=( ${1}*${2}(N-/) )
        fi
  }

So the question is: do you think that this is enough (probably with
some more work on the function) or should we build this into the shell?

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de