Bug 525400

Summary: ls -L option problem
Product: [Fedora] Fedora Reporter: Yang Ren <ryang>
Component: coreutilsAssignee: Ondrej Vasik <ovasik>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: drepper, kdudka, llim, meyering, ovasik, twaugh
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-09-24 07:39:36 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Yang Ren 2009-09-24 04:58:03 EDT
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
Comment 1 Yang Ren 2009-09-24 05:00:08 EDT
Forget to mention The coreutils version.
coreutils-7.6-5.fc12.x86_64
Comment 2 Ondrej Vasik 2009-09-24 07:39:36 EDT
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@gnu.org.
Comment 3 Ulrich Drepper 2009-09-28 13:16:54 EDT
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?
Comment 4 Jim Meyering 2009-09-28 14:46:51 EDT
Thanks for the report and the Cc.
I've posted a patch for this:

http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/18318