[Bug 257886] ls: don't check color env variables if compiled with WITHOUT_LS_COLORS="YES"

From: <bugzilla-noreply_at_freebsd.org>
Date: Wed, 18 Aug 2021 18:46:53 +0000

Piotr Pawel Stefaniak <pstef_at_freebsd.org> changed:

           What    |Removed                     |Added
                 CC|                            |pstef_at_freebsd.org

--- Comment #2 from Piotr Pawel Stefaniak <pstef_at_freebsd.org> ---

I agree with you, but I would fix this another way: since the warnx is
generally useless, I would like to remove it. But Ed pointed out that we may
want to have a way to determine whether a particular copy of ls has been
compiled with color support or not. So I think it's best to move the warnx to
getopt in a WITHOUT_LS_COLORS build to fire if user asks for color. Like this:

diff --git a/bin/ls/ls.c b/bin/ls/ls.c
index 338b3d1d2a2..92575711251 100644
--- a/bin/ls/ls.c
+++ b/bin/ls/ls.c
_at__at_ -105,9 +105,7 _at__at_ static void  traverse(int, char **, int);

 static const struct option long_opts[] =
-#ifdef COLORLS
         {"color",       optional_argument,      NULL, COLOR_OPT},
         {NULL,          no_argument,            NULL, 0}

_at__at_ -448,8 +446,8 _at__at_ main(int argc, char *argv[])
                case 'y':
                        f_samesort = 1;
-#ifdef COLORLS
                case COLOR_OPT:
+#ifdef COLORLS
                        if (optarg == NULL || do_color_always(optarg))
                                colorflag = COLORFLAG_ALWAYS;
                        else if (do_color_auto(optarg))
_at__at_ -460,6 +458,8 _at__at_ main(int argc, char *argv[])
                                errx(2, "unsupported --color value '%s' (must
be always, auto, or never)",
+                       warnx("color support not compiled in");
                case '?':
_at__at_ -503,8 +503,6 _at__at_ main(int argc, char *argv[])
                        f_color = 1;
                        explicitansi = true;
-               warnx("color support not compiled in");
 #endif /*COLORLS*/

You are receiving this mail because:
You are the assignee for the bug.
Received on Wed Aug 18 2021 - 18:46:53 UTC

Original text of this message