ln, ls or readline problem?
Hello, In my home directory named /home/Carlo, I have a directory named foo and under foo is the directory bar: $ ls -ld foo drwxr-xr-x 3 Carlo None 0 Nov 9 08:46 foo $ ls -ld foo/bar drwxr-xr-x 2 Carlo None 0 Nov 9 08:46 foo/bar I also have a symbolic link to foo/bar on my home directory named bar2: $ ls -ld bar2 lrwxrwxrwx 1 Carlo None 7 Nov 9 08:47 bar2 - foo/bar Here's the problem: When I do a `cd bar2' and do an `ls -l ../', here's what I get: $ pwd /home/Carlo $ cd bar2 $ pwd /home/Carlo/bar2 $ ls -l ../ total 0 drwxr-xr-x 2 Carlo None 0 Nov 9 08:46 bar As you can see, it shows only `bar' (since ls obviously looks under /home/Carlo/foo) However, when I go inside bar2, and press the TAB after `ls -l ../', I get the contents of /home/Carlo: $ cd /home/Carlo $ pwd /home/Carlo $ cd bar2 $ pwd /home/Carlo/bar2 $ ls -l ../PRESSED THE TAB KEY HERE .addressbook desktop/ .addressbook.ludicom.txt.bak .aspell.en.prepl dicom_capture .bash_history foo/ .bash_profile fop-0.20.5-bin.tar.gz .bashrcidentity .cvspass index.html .ddd/ index.php In other words, the output of `ls -l ../ shows the contents of the directory relative to the target path of the symbolic link while `ls -l ../PRESSED TAB' shows the contents of the directory above the symbolic link. Which is incorrect, the output of `ls -l ../', or the output of `ls -l ../PRESSED TAB'? Thanks! Best Regards, Carlo -- Carlo Florendo Astra Philippines Inc. www.astra.ph -- 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/
Re: ln, ls or readline problem?
$ ls -ld bar2 lrwxrwxrwx 1 Carlo None 7 Nov 9 08:47 bar2 - foo/bar Here's the problem: When I do a `cd bar2' and do an `ls -l ../', here's what I get: 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. -- 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/
Re: ln, ls or readline problem?
Eric Blake wrote: $ ls -ld bar2 lrwxrwxrwx 1 Carlo None 7 Nov 9 08:47 bar2 - foo/bar Here's the problem: When I do a `cd bar2' and do an `ls -l ../', here's what I get: 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). -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- 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/
Re: ln, ls or readline problem?
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/
