bug#13635: Strange ls bug (Combination of -a and --color)

[Bob Proulx]

Joshua Rogers wrote:
> Okay, I understand that, but the
> 
> "
> 
> d????????? ? ? ? ?                ? .
> d????????? ? ? ? ?                ? .."
> 
> That is a bug, no?

No it isn't.  Since ls didn't have permission to search the directory
it could not stat those files and therefore could not report any
information aout them.  The long format was specified using -l and
therefore the missing columns were filled in with '?'.

If the above was all there was printed then that would be a bug.  But
That wasn't all of the output.  Let me reproduce it including the
important part.

  $ ls -lh csf/
  ls: cannot access csf/.: Permission denied
  ls: cannot access csf/..: Permission denied
  total 0
  d??? ? ? ? ?                ? .
  d??? ? ? ? ?                ? ..

Specifically these lines:

  ls: cannot access csf/.: Permission denied
  ls: cannot access csf/..: Permission denied

That is an error message printed by ls that it did not have the
permission it needed.  It can read their names but it can't find any
stat information about them such as file mode, owner, group, size or
timestamp.  It printed an error message to stderr.  It then gave the
listing with the information it had available.

Also if you were to check the exit code of ls you would find that it
exited with a non-zero exit code indicating that an error occured.

  echo $?
  1

As long as that isn't asked to be printed then it is okay without
knowing those things.  But when asked with any of -l or --color or -a
then it tries to get information about those files, fails, prints the
error message, and exits non-zero.

The ls program has printed an error message where appropriate and has
exited with an error when appropriate.  I see no bug there.  Plus it
has been this way for forty years.  I wouldn't want to change this
core behavior now without a very good reason to do so.

I think the part you are having trouble with is the separation of
permission between 'r' and 'x'.  The 'r' allows reading the names of
the files.  The 'x' allows "searching" which in this case means being
able to stat(2) the file.

  man 2 stat

       These functions return information about a file.  No
       permissions are required on the file itself, but—in the case of
       stat() and lstat() — execute (search) permission is required on
       all of the directories in path that lead to the file.

And so we see that some actions need 'r' and some need 'x'.  I don't
know why the permissions were split this way.  But they were and so
they continue to be because changing long established behavior is very
disruptive.

Bob