Project

General

Profile

Bug #4193

ls --color with filename arguments does not colorize

Added by Lauri Tirkkonen about 7 years ago. Updated about 7 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
-
Start date:
2013-10-09
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage
Gerrit CR:

Description

ls, when given files as arguments, does not seem to colorize them correctly
when --color is specified.

In an empty directory, expected behavior when the filename argument is not given and unexpected when it is:

% touch foo; chmod +x foo
% /bin/ls --color=always | xxd
0000000: 1b5b 316d 1b5b 3332 6d66 6f6f 1b5b 6d0f  .[1m.[32mfoo.[m.
0000010: 0a                                       .
% /bin/ls --color=always foo | xxd
0000000: 666f 6f1b 5b6d 0f0a                      foo.[m..

#1

Updated by Lauri Tirkkonen about 7 years ago

Dan McDonald wrote:

Can you please also update the bug report with a quick sentence on why moving
the initialization earlier fixes this specific problem? Analyses are useful
for historical records.

Without initialization, the default color (or no color) will be used for
everything. The gstat function will assign colors, so we need to
initialize before any gstat call (for the 'arguments given' case this is
done in the for loop over 'amino').

#2

Updated by Dan McDonald about 7 years ago

  • Status changed from New to Resolved

commit 71ef9ec8a14e5d11c2ac4a72fb5717a330206444
Author: Lauri Tirkkonen <>
Date: Wed Oct 23 02:49:13 2013 +0300

4193 ls --color with filename arguments does not colorize
Reviewed by: Jason King &lt;&gt;
Approved by: Dan McDonald &lt;&gt;
usr/src/cmd/ls/ls.c |    6 ++---
1 files changed, 3 insertions(
), 3 deletions(-)
#3

Updated by Dan McDonald about 7 years ago

  • % Done changed from 0 to 100

Also available in: Atom PDF