coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Coreutils enhancement: ls: add colorization of mountpoints


From: Dragan Simic
Subject: Re: Coreutils enhancement: ls: add colorization of mountpoints
Date: Wed, 18 Oct 2023 02:41:57 +0200

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                                      )))))



reply via email to

[Prev in Thread] Current Thread [Next in Thread]