ls: -L on broken links should return 1

[jtracey]

ls is supposed to have an exit status of 1 for "minor problems". This includes trying to dereference symbolic links (via -L) when they don't link anywhere. The lack of return code is causing the latest tests/ls/selinux-segfault GNU test to fail.

[tertsdiepraam]

The call that should return 1, according to the GNU test, is specifically:

ls -L -Z

We already return 1 with:

ls -L -l

Or any other case where we try to deference the a broken symlink. I believe (but am not sure) that the issue is that because the security context is not supported in the first place, we never get the metadata, so we don't show the error.

[kimono-koans]

ls seems like it needs a meta-thread for its issues. Is OP implementing this?

[sylvestre]

sure, please open as many issues as you need :)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[jtracey]

This is still an issue.

We already return 1 with:
ls -L -l
Or any other case where we try to deference the a broken symlink.

I'm still seeing ret code 0 with just ls -L for us, and ret code 1 on GNU.

[granquet]

I've looked into it and think I've solved the ls -L -Z issue.

Though with GNU coreutils 9.1, I see ls -L returns 0, which is aligned with the behaviour I see in uutils ?

[tertsdiepraam]

uutils ls -L is returning 0 for me. Which case is incompatible exactly?

[granquet]

ls -L -Z

• returns 0 in uutils
• returns 1 in GNU coreutils
  Attempting to fix this case with : ls: force fetching metadata when called with -L -Z #4960

ls -L returns 0 on both, @jtracey seemed to imply that ls -L should return 1 too?

[tertsdiepraam]

Ah sorry, I misread your comment. I think you're right!

[cakebaker]

Fixed in #4960