[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 )))))
- Coreutils enhancement: ls: add colorization of mountpoints, Parke, 2023/10/16
- Re: Coreutils enhancement: ls: add colorization of mountpoints, Rob Landley, 2023/10/18
- Re: Coreutils enhancement: ls: add colorization of mountpoints, Parke, 2023/10/18
- Re: Coreutils enhancement: ls: add colorization of mountpoints, Dragan Simic, 2023/10/18
- Re: Coreutils enhancement: ls: add colorization of mountpoints, Dragan Simic, 2023/10/18