Re: ln, ls or readline problem?

[ericblake at comcast dot net (Eric Blake)]

> > 
> > Known problem.  Cygwin takes a shortcut and treats name/.. as
> > though it were a single ., which unfortunately is counter to posix
> > when name was a symlink.  The problem is that patching cygwin
> > is likely to slow down the common case, so the cygwin developers
> > have chosen speed over correctness for the moment on this issue.
> 
> 
> And I can't remember if this came up in that original thread but I see
> the same behavior as described by the OP on Linux (FC4).

Then maybe my initial evaluation was a bit hasty - it looks like the OP
is calling ls without any name before .., so it does not actually tickle
the cygwin bug.  To actually see the cygwin bug, note that on
cygwin, "ls bar2/.." does the same as "ls .", whereas on Linux,
it is the same as "ls foo/bar/.." or "ls foo".

One other thing to remember - POSIX specifies that cd takes an
optional argument -P or -L, but by default it uses -L.  When you
do "cd -L bar2", the shell remembers that bar2 is a symlink on
as part of the current logical directory name, and since readline
is built into the shell, it treats an unqualified .. as relative to the
logical directory during TAB completion.  But ls is not allowed by
POSIX to use logical directories, so "ls .." behaves the same
whether you did "cd -L bar2" or "cd -P bar2".  Meanwhile, if
you do "cd -P bar2", then the shell will know that your physical
location really is foo/bar, so that readline would then treat .. as
relative to the physical directory just as ls does.

So, I retract my earlier statement that this is a bug in cygwin,
because in this particular case, you are seeing everything
working as designed.

--
Eric Blake



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/