ls --color

Version:

7.6 (fixed in 8.0)

How to reproduce the failure?

We cannot reproduce it and rely on source code analysis.

Symptom:

Wrong result.

 ls --color now reverts to the color of a base file type consistently

 when the color of a more specific type is disabled.

Root cause:

ls missed certain conditions when computing color printing strategy.

static bool print_color_indicator (... ...) {

 … …

 if (linkok == -1 && color_indicator[C_MISSING].string != NULL)

   type = C_MISSING;

 else if (! stat_ok)

   {

     static enum indicator_no filetype_indicator[] =FILETYPE_INDICATORS;

     type = filetype_indicator[filetype];

   }

 else

   {

     if (S_ISREG (mode))

       {

         type = C_FILE;

-        if ((mode & S_ISUID) != 0)

+       if ((mode & S_ISUID) != 0 && is_colored (C_SETUID))

           type = C_SETUID;

-         else if ((mode & S_ISGID) != 0)

+        else if ((mode & S_ISGID) != 0 && is_colored (C_SETGID))

           type = C_SETGID;

         … …

       }

   } // else

}

Is there Error Message?

No.

Can developers/Errlog anticipate error?

No. Since the error manifestation condition is very application specific, and the fault (root cause) point is subtle. So detecting the error requires the developers to anticipate the bug --- in that case why not just fix it?

Also, the error condition is not that noticeable from the application’s point of view. For ls, when print_color_indicator decides not to print the color correctly, ls would think it is normal.