Re: Coreutils enhancement: ls: add colorization of mountpoints

[Dragan Simic]

On 2023-10-17 23:54, Parke wrote:
> On Tue, Oct 17, 2023 at 10:42 AM Dragan Simic <dsimic@manjaro.org> 
> wrote:
> > Regarding performing the additional stat() calls on all files, which
> > currently aren't performed at all in ls(1), but only when $LS_COLORS
> > tells ls(1) that they should be performed, I'm afraid that 
> > dircolors(1)
> > would be expected to have that in the $LS_COLORS that it produces,
> > making many users perform the stat() calls they actually don't want or
> > need.
>
> dircolors.hin, line 75 seems to suggest otherwise (but I could be 
> wrong):
>
> CAPABILITY 00 # file with capability (very expensive to lookup)
>
> Source:
> https://github.com/coreutils/coreutils/blob/master/src/dircolors.hin#L75

The following excerpt from src/ls.c shows that some of the coloring 
options are disabled by default:

 615 static struct bin_str color_indicator[] =
 616   {
 617     { LEN_STR_PAIR ("\033[") },         /* lc: Left of color 
sequence */
 618     { LEN_STR_PAIR ("m") },             /* rc: Right of color 
sequence */
 619     { 0, nullptr },                     /* ec: End color (replaces 
lc+rs+rc) */
 620     { LEN_STR_PAIR ("0") },             /* rs: Reset to ordinary 
colors */
 621     { 0, nullptr },                     /* no: Normal */
 622     { 0, nullptr },                     /* fi: File: default */
 623     { LEN_STR_PAIR ("01;34") },         /* di: Directory: bright 
blue */
 624     { LEN_STR_PAIR ("01;36") },         /* ln: Symlink: bright cyan 
*/
 625     { LEN_STR_PAIR ("33") },            /* pi: Pipe: yellow/brown 
*/
 626     { LEN_STR_PAIR ("01;35") },         /* so: Socket: bright 
magenta */
 627     { LEN_STR_PAIR ("01;33") },         /* bd: Block device: bright 
yellow */
 628     { LEN_STR_PAIR ("01;33") },         /* cd: Char device: bright 
yellow */
 629     { 0, nullptr },                     /* mi: Missing file: 
undefined */
 630     { 0, nullptr },                     /* or: Orphaned symlink: 
undefined */
 631     { LEN_STR_PAIR ("01;32") },         /* ex: Executable: bright 
green */
 632     { LEN_STR_PAIR ("01;35") },         /* do: Door: bright magenta 
*/
 633     { LEN_STR_PAIR ("37;41") },         /* su: setuid: white on red 
*/
 634     { LEN_STR_PAIR ("30;43") },         /* sg: setgid: black on 
yellow */
 635     { LEN_STR_PAIR ("37;44") },         /* st: sticky: black on 
blue */
 636     { LEN_STR_PAIR ("34;42") },         /* ow: other-writable: blue 
on green */
 637     { LEN_STR_PAIR ("30;42") },         /* tw: ow w/ sticky: black 
on green */
 638     { 0, nullptr },                     /* ca: disabled by default 
*/
 639     { 0, nullptr },                     /* mh: disabled by default 
*/
 640     { LEN_STR_PAIR ("\033[K") },        /* cl: clear to end of line 
*/
 641   };

However, the dircolors(1) on my system still generates the "ca" (i.e. 
"C_CAP") entry, for some reason, which led to this confusion.

> > Maybe having an additional command-line option for ls(1), which
> > would enable the additional processing, could be an option.
>
> If necessary, an additional command line option would be fine with me.
> (I'd just alias it, as I already do with other command line options.)
> But I'm not yet convinced that such an additional option is necessary.

It actually isn't necessary, but it would still be needed to investigate 
why dircolors(1) may behave the way I described it above, because it may 
cause the new feature to be enabled even when not intended so.

> > It goes without saying that performing numerous stat() calls would
> > induce a significant performance penalty, compared with the currently
> > employed readdir() approach.
>
> I'm confused.  Don't the following (default?) colorizations already
> require stat()ing every file and directory?
>
> SETUID 37;41 # file that is setuid (u+s)
> SETGID 30;43 # file that is setgid (g+s)
> STICKY_OTHER_WRITABLE 30;42 # dir that is sticky and other-writable 
> (+t,o+w)
> OTHER_WRITABLE 34;42 # dir that is other-writable (o+w) and not sticky
> STICKY 37;44 # dir with the sticky bit set (+t) and not other-writable
> # This is for files with execute permission:
> EXEC 01;32
>
> Source:
> https://github.com/coreutils/coreutils/blob/master/src/dircolors.hin#L73

You're right, the following excerpt from src/ls.c confirms that:

3429       || (format_needs_type
3430           && (type == unknown || command_line_arg
3431               /* --indicator-style=classify (aka -F)
3432                  requires that we stat each regular file
3433                  to see if it's executable.  */
3434               || (type == normal && (indicator_style == classify
3435                                      /* This is so that --color 
ends up
3436                                         highlighting files with 
these mode
3437                                         bits set even when options 
like -F are
3438                                         not specified.  Note we do 
a redundant
3439                                         stat in the very unlikely 
case where
3440                                         C_CAP is set but not the 
others. */
3441                                      || (print_with_color
3442                                          && (is_colored (C_EXEC)
3443                                              || is_colored 
(C_SETUID)
3444                                              || is_colored 
(C_SETGID)
3445                                              || is_colored 
(C_CAP)))
3446                                      )))))