bug 3.1.5 symlinks & cd

bug 3.1.5 symlinks & cd

[Phil Pennock]

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.  (Linux 2.0.x on x86.)

% zsh-3.1.5 -f
machinename% PS1='%~%# '
~% mkdir tmp/tst && cd tmp/tst
~/tmp/tst% mkdir foo foo/bar wibble
~/tmp/tst% ln -s foo/bar .
~/tmp/tst% cd bar
~/tmp/tst/bar% 

At this points, try tab-completing "cd ../" and you get "../bar", try
../w<tab> and it beeps.  Try "../../w<tab>" and you get the wibble
directory completed, but:

~/tmp/tst/bar% cd ../../wibble
cd: no such file or directory: ../../wibble
~/tmp/tst/bar% cd ../wibble
~/tmp/tst/wibble% compctl -L cd
compctl: no compctl defined for cd

Note that the ../wibble refuses to tab-complete.

HTH
-- 
--> Phil Pennock ; GAT d- s+:+ a22 C++(++++) UL++++/I+++/S+++/H+ P++@ L+++
E-@ W(+) N>++ o !K w--- O>+ M V !PS PE Y+ PGP+ t-- 5++ X+ R !tv b++>+++ DI+ D+
G+ e+ h* r y?

Re: bug 3.1.5 symlinks & cd

[Bart Schaefer]

On Nov 13,  9:19pm, Phil Pennock wrote:
} Subject: bug 3.1.5 symlinks & cd
}
} 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.

There is one difference between 3.0.5 and 3.1.5 with chaselinks; here's
3.0.5:

zagzig[45] cd /tmp/test/bar
zagzig[46] pwd
/tmp/test/foo/bar
zagzig[47] print -P %~
/tmp/test/bar

Now 3.1.5:

zagzig<22> cd /tmp/test/bar
zagzig<23> pwd
/tmp/test/foo/bar
zagzig<24> print -P %~
/tmp/test/foo/bar

Apparently chaselinks didn't affect prompt expansion in 3.0.5, but does
in 3.1.5.  This may (?) have something to do with un-special-izing $PWD.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: bug 3.1.5 symlinks & cd

[Phil Pennock]

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.

$0.01 (discounted 50% -- as Bart says, it can be worked around, but it
       shouldn't have to be.)
-- 
-Phil 'my paragraphs naturally right-align' Pennock

Re: bug 3.1.5 symlinks & cd

[Phil Pennock]

Typing away merrily, Sven Wischnowsky produced the immortal words:
> A (partial) solution is to use a shell function, like this:
[...]
> 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?

Since you asked ... a function is fine, provided either:
 1) that the function/compctl is made standard for future releases;
 2) by default, 'chaselinks' is set and a user needs to explicitly unset
    this.

The former /requires/ extended installation instructions, "to get a
working shell, you will need this here and that there".

The latter would provoke a lot of "why doesn't this work anymore" and
probably a FAQ addition (oh joy).

The issue that the changes in FS semantics is introduced by the shell
and then not carried through to completion (no pun intended, honest!).
The presented directory could affect arbitrary arguments in arbitrary
commands, and to completely 'fix' would require scanning all
arguments... this gets messy.

Uhm..
 a) I've just put 'setopt chaselinks' into my .zshrc
 b) If this doesn't make sense, I'm blaming it on the bang to my head
    which resulted in me getting staples put in by a nurse yesterday --
    I'm not supposed to be using a computer.  :^(
-- 
Phil 'your blood looks interesting coagulating on your glasses' Pennock

Re: bug 3.1.5 symlinks & cd

[Bart Schaefer]

On Nov 18, 10:09am, Sven Wischnowsky wrote:
} Subject: Re: bug 3.1.5 symlinks & cd
}
} > [...] 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.
} 
} 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 )

Should be:        reply=( $d/$^reply )

}                 cd - >& /dev/null
}         else
}                 reply=( ${1}*${2}(N-/) )
}         fi
}   }

That's an unpleasant solution because it silently changes the value of
$OLDPWD, messing up the use of ~- in filename expansions.  One possible
workaround:

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

"${(@f)$(print -l ...)}" in case some of the directory names have spaces.

On Nov 18, 2:06pm, Peter Stephenson wrote:
} Presumably it will one day become possible to replace the (../)# with
} a truncated version of $PWD, then reapply -/ using the -W option to
} compctl to generate the completions you want.  Then the script
} solution ought to become pretty painless.

Hmm.

    compctl -/ -x 'S[../]' -S/ -q -K cdcomp -- cd
    cdcomp() {
        local h t p d			# No, not Apache :-)
	h="${(M)1##*../}"		# Extract leading (../)#
	t="${1##*../}"			# Delete leading (../)#
	p="${h:gs@../@/*@}"		# Convert $h to a pattern
	eval 'd="${PWD%'"$p"'}"'	# Remove matching tail of $PWD
	reply=( $d/$t*$2(N-/) )		# Generate list of directories
	eval 'reply=( ${reply'":s@$d/$t@$1@"'} )'	# Fix up prefixes
    }

The last line fails on directories with "@" in their names, and the first
two fail on things like ../foo/bar/../baz/.  Oh, well.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: bug 3.1.5 symlinks & cd

[Sven Wischnowsky]

Peter Stephenson wrote:

> Sven Wischnowsky wrote:
> > 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?
> 
> Isn't the problem only with ../ ?  -/ and the rest happily follow
> symlinks, it's only when going up there's a problem.  In that case, it
> would be OK to use -/ most of the time and only have a special
> function when there's a ../ in the string so far.  As the only case
> where you would normally use this is ../ at the start (although I've
> been known to use $PWD/.. when I needed an absolut path), I should
> have thought a shell function for this one case would have been quite
> good enough.  ../../ etc. is a complication, but one a function could
> still easily handle. (Unless I've missed some other potential
> problem.)

I don't see any other problem either. So I won't dive into the
completion code today, fine.


Bye
 Sven


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

Re: bug 3.1.5 symlinks & cd

[Peter Stephenson]

Sven Wischnowsky wrote:
> 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?

Isn't the problem only with ../ ?  -/ and the rest happily follow
symlinks, it's only when going up there's a problem.  In that case, it
would be OK to use -/ most of the time and only have a special
function when there's a ../ in the string so far.  As the only case
where you would normally use this is ../ at the start (although I've
been known to use $PWD/.. when I needed an absolut path), I should
have thought a shell function for this one case would have been quite
good enough.  ../../ etc. is a complication, but one a function could
still easily handle. (Unless I've missed some other potential
problem.)

Presumably it will one day become possible to replace the (../)# with
a truncated version of $PWD, then reapply -/ using the -W option to
compctl to generate the completions you want.  Then the script
solution ought to become pretty painless.

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56100 Pisa, Italy

Re: bug 3.1.5 symlinks & cd

[Sven Wischnowsky]

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

Re: bug 3.1.5 symlinks & cd

[Sven Wischnowsky]

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.  (Linux 2.0.x on x86.)
> 
> % zsh-3.1.5 -f
> machinename% PS1='%~%# '
> ~% mkdir tmp/tst && cd tmp/tst
> ~/tmp/tst% mkdir foo foo/bar wibble
> ~/tmp/tst% ln -s foo/bar .
> ~/tmp/tst% cd bar
> ~/tmp/tst/bar% 
> 
> At this points, try tab-completing "cd ../" and you get "../bar", try
> ../w<tab> and it beeps.  Try "../../w<tab>" and you get the wibble
> directory completed, but:
> 
> ~/tmp/tst/bar% cd ../../wibble
> cd: no such file or directory: ../../wibble
> ~/tmp/tst/bar% cd ../wibble
> ~/tmp/tst/wibble% compctl -L cd
> compctl: no compctl defined for cd
> 
> Note that the ../wibble refuses to tab-complete.

Damn. Currently I see no simple solution for this. It looks as if we
would need a compctl flag for completing paths with special sym-link
handling just for `cd' and friends which seem to be the only builtins
that use CHASESYMLINKS for their arguments.

Bye
 Sven


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