On Tue, Oct 17, 2023 at 10:42 AM Dragan Simic <dsi...@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 > 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 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 Cheers, Parke
