Re: thoughts on NO_COLOR
Pádraig Brady wrote: > I just noticed some de facto treatment of the NO_COLOR env var. > https://no-color.org/ I happened to run across this site myself a few weeks ago. When I saw it I had this immediate feeling of community. Here was someone else who also felt the oppression of endless flashing lights, ringing of bells, and awful color choices being pushed upon us by default! When working on the computer I really don't want to feel like I am walking through a casino. I forwarded the site to another friend who was also was happy to see a site with documentation as a resource for how to stop the noisy color choices. We agreed it was a useful resource because every program has been set up to do this completely independently and differently. > I was considering having ls --color=auto honor this, but then thought > it is not actually needed in ls, since we give fine grained > control over the colors / styles used. Mostly I can always unset any alias that sets ls with --color. This one is so well known that it's an easy routine. It's the other odd corners that one doesn't do very often that are more problematic. When "dmesg" started spraying me with colors then I had to stop and spend time to figure out how to disable the noise. Utilities such as that are not run into immediately. And then when they do get hit then it is a distraction at that time. Others such as a default vim is almost unusable due to the onslaught. It's worse when one is not in their home environment. Such as if I am debugging some server, standing in a freezing datacenter floor, in a limited environment, without all of my home customization. That's when some of these defaults are truly annoying. > For example one might very well always want at least some distinguishing > of files and directories, with bold / bright etc. > which can be achieved now with LS_COLORS. Actually ls -F is pretty good. That's all I use. > Or looking at it another way, ls is ubiquitous enough > that it's probably already color configured as the user desires, > and having ls honor the less fine grained NO_COLOR flag, > would result in less flexibility. I think ls is ubiquitous enough that everyone has already learned how to deal with it right up front. For me usually \ls is enough. Therefore it isn't as much of a concern for ls. And so I am not going to lobby for coreutils picking up NO_COLOR. But if things were to get worse then it could be a proposal I could get behind. Bob
[PATCH] doc: describe `dd iseek` as a feature not a change
* NEWS: Move description from "Changes in behavior" to "New features". --- NEWS | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/NEWS b/NEWS index 2041b8a6d..85fd5be12 100644 --- a/NEWS +++ b/NEWS @@ -63,9 +63,6 @@ GNU coreutils NEWS-*- outline -*- dd conv=fsync now synchronizes output even after a write error, and similarly for dd conv=fdatasync. - dd now supports the aliases iseek=N for skip=N, and oseek=N for seek=N, - like FreeBSD and other operating systems. - dd now counts bytes instead of blocks if a block count ends in "B". For example, 'dd count=100KiB' now copies 100 KiB of data, not 102,400 blocks of data. The flags count_bytes, skip_bytes and @@ -90,6 +87,9 @@ GNU coreutils NEWS-*- outline -*- ** New Features + dd now supports the aliases iseek=N for skip=N, and oseek=N for seek=N, + like FreeBSD and other operating systems. + dircolors takes a new --print-ls-colors option to display LS_COLORS entries, on separate lines, colored according to the entry color code. -- 2.26.2
[PATCH] ls: avoid expensive capability lookup by default
Lookup of file-based capabilities adds 30% overhead to the common
case of ls --color usage. Since the use of file capabilities is
very rare, it doesn't make sense to pay this cost in the common
case. It's better to use getcap to inspect capabilities, and the
following run shows only 8 files using capabilities on my fedora
35 distro (14 years after the feature was introduced to the linux
kernel).
$ getcap -r /
/usr/bin/arping = cap_net_raw+p
/usr/bin/clockdiff = cap_net_raw+p
/usr/bin/gnome-keyring-daemon = cap_ipc_lock+ep
/usr/bin/gnome-shell = cap_sys_nice+ep
/usr/bin/newgidmap = cap_setgid+ep
/usr/bin/newuidmap = cap_setuid+ep
/usr/sbin/mtr-packet = cap_net_raw+ep
/usr/sbin/suexec = cap_setgid,cap_setuid+ep
* src/dircolors.hin: Set "CAPABILITY" to "00", to indicate unused.
* src/ls.c: Set the default C_CAP color to not colored.
* NEWS: Mention the change in behavior.
---
NEWS | 4
src/dircolors.hin | 2 +-
src/ls.c | 2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/NEWS b/NEWS
index 6d6f204ee..2041b8a6d 100644
--- a/NEWS
+++ b/NEWS
@@ -72,6 +72,10 @@ GNU coreutils NEWS-*-
outline -*-
seek_bytes are therefore obsolescent and are no longer documented,
though they still work.
+ ls no longer colors files with capabilities by default, as file-based
+ capabilties are very rarely used, and lookup increases processing per file by
+ about 30%. It's best to use getcap [-r] to identify files with capabilities.
+
ls no longer tries to automount files, reverting to the behavior
before the statx() call was introduced in coreutils-8.32.
diff --git a/src/dircolors.hin b/src/dircolors.hin
index 6dc5a2d74..f11735958 100644
--- a/src/dircolors.hin
+++ b/src/dircolors.hin
@@ -65,7 +65,7 @@ ORPHAN 40;31;01 # symlink to nonexistent file, or
non-stat'able file ...
MISSING 00 # ... and the files they point to
SETUID 37;41 # file that is setuid (u+s)
SETGID 30;43 # file that is setgid (g+s)
-CAPABILITY 30;41 # file with capability
+CAPABILITY 00 # file with capability (very expensive to lookup)
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
diff --git a/src/ls.c b/src/ls.c
index 255789061..d15a10367 100644
--- a/src/ls.c
+++ b/src/ls.c
@@ -638,7 +638,7 @@ static struct bin_str color_indicator[] =
{ LEN_STR_PAIR ("37;44") },/* st: sticky: black on blue */
{ LEN_STR_PAIR ("34;42") },/* ow: other-writable: blue on
green */
{ LEN_STR_PAIR ("30;42") },/* tw: ow w/ sticky: black on
green */
-{ LEN_STR_PAIR ("30;41") },/* ca: black on red */
+{ 0, NULL }, /* ca: disabled by default */
{ 0, NULL }, /* mh: disabled by default */
{ LEN_STR_PAIR ("\033[K") }, /* cl: clear to end of line */
};
--
2.26.2
bug#54521: [PATCH] dircolors: colorize backup files with bright black
On 23/03/2022 23:53, Pádraig Brady wrote: On 22/03/2022 18:24, Ville Skyttä wrote: Useful as it makes them stand out less than non-backup files. --- src/dircolors.hin | 19 +++ 1 file changed, 19 insertions(+) diff --git a/src/dircolors.hin b/src/dircolors.hin index 673835201..6dc5a2d74 100644 --- a/src/dircolors.hin +++ b/src/dircolors.hin @@ -211,5 +211,24 @@ EXEC 01;32 .spx 00;36 .xspf 00;36 +# backup files +*~ 00;90 +*# 00;90 +.bak 00;90 +.old 00;90 +.orig 00;90 +.part 00;90 +.rej 00;90 +.swp 00;90 +.tmp 00;90 +.dpkg-dist 00;90 +.dpkg-old 00;90 +.ucf-dist 00;90 +.ucf-new 00;90 +.ucf-old 00;90 +.rpmnew 00;90 +.rpmorig 00;90 +.rpmsave 00;90 + # Subsequent TERM or COLORTERM entries, can be used to add / override # config specific to those matching environment variables. I quite like that actually. The default coloring works well on both dark and light backgrounds. Coloring this class of files does seem useful. +1 from me anyway. I've pushed this after some perf testing showing it had negligible perf impact. https://git.sv.gnu.org/cgit/coreutils.git/commit/?id=52aeae2c3 Here is a small example of the output: https://www.pixelbeat.org/patches/coreutils/ls-backup-colors.html cheers, Pádraig
