Description of problem: I see in man page: -L, --dereference when showing file information for a symbolic link, show information for the file the link references rather than for the link itself It means if using -L the link should show the linked file not the link itself. In a POSIX.shell test case. It make a bad link. Using ls -RLi to show it. It still show the link itself. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: mkdir A chmod 777 A ln -s nonexistingfile A/xxx ls -RLi A 2> /dev/null rm -rf A Actual results: A: 0 xxx Expected results: Do not show "xxx" in stdout Additional info: This is a part of POSIX shell test from opengroup
Forget to mention The coreutils version. coreutils-7.6-5.fc12.x86_64
From the "info ls invocation": "`-L' `--dereference' When showing file information for a symbolic link, show information for the file the link references rather than the link itself. However, even with this option, `ls' still prints the name of the link itself, not the name of the file that the link points to." As the file is not command line argument (notice the difference when you specify ls -RLi A/xxx directly), ls spawns an error message about "No such file or directory" , sets exit code to 1 and exits. In the case of command line argument the exit code is 2 and nothing is shown. I see nothing wrong in that as POSIX defines: "-R Recursively list subdirectories encountered." - that's done correctly "-L Evaluate the file information and file type for all symbolic links (whether named on the command line or encountered in a file hierarchy) to be those of the file referenced by the link, and not the link itself; however, ls shall write the name of the link itself and not the file referenced by the link. When -L is used with -l, write the contents of symbolic links in the long format (see the STDOUT section)." - that's done correctly, link name is shown "-i For each file, write the file's file serial number (see stat() in the System Interfaces volume of IEEE Std 1003.1-2001)." - that's something you could argue - as it has not inode 0 - it doesn't exist at all. So 0 is misleading/wrong - but inode 0 is reserved, so it's safe/easy to filter that. Closing NOTABUG, as imho all posix requirements were met. Feel free to discuss what's wrong, but as this is behaviour upstream, it would be better to discuss it on upstream mailing list bug-coreutils.
I think I agree that the spec is silent on this case. But i also think that it is bad practice to print information that is wrong or misleading. In case more information than just the name is needed printing an entry for a dangling symlink is IMO wrong (only when -L is used). An error message and an != 0 exit code are likely better. This will also correspond more closely what other implementations do, I assume. Jim?
Thanks for the report and the Cc. I've posted a patch for this: http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/18318