This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 525400 - ls -L option problem
ls -L option problem
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: coreutils (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Ondrej Vasik
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-09-24 04:58 EDT by Yang Ren
Modified: 2009-09-28 14:46 EDT (History)
6 users (show)

See Also:
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:


Attachments (Terms of Use)

  None (edit)
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

Note You need to log in before you can comment on or make changes to this bug.