Bug 21086

Summary:	Annoying little bug using ls -G with colorized prompts.
Product:	Base System	Reporter:	eddier <eddier>
Component:	bin	Assignee:	joe <joe>
Status:	Closed FIXED
Severity:	Affects Only Me
Priority:	Normal
Version:	4.1-RELEASE
Hardware:	Any
OS:	Any

Description eddier 2000-09-07 00:00:00 UTC

When using "ls -G" while also using colored bash prompts, if the first file(s) outputted are not to be colorized, they take on the bash prompt color until reaching a file that does have color. Then the folowing non-colored files take on the defualt white. In other words, there is no *initial* setting of the default color.
I know it's a tiny thing and you have better things to worry about, but...  :)

Fix: 

Easy fix is to add 
  endcolor(0);
to parsecolors() in src/bin/ls/print.c
This forces an initial setting of the color, once, before displaying any files. Looks like you tried to fix it with some signal() code just before the call to pasrecolors() but it didn't seem to fix it.
How-To-Repeat: Add a colorized bash prompt.
Do a ls -G
(Make sure that the directory's first few files have no color attribute.)

Comment 1 Gregory Bond 2000-09-07 01:52:41 UTC

> When using "ls -G" while also using colored bash prompts, if the first file(s
> ) outputted are not to be colorized, they take on the bash prompt color until
>  reaching a file that does have color.

Surely this is a bug in the way the bash color prompt is implemented (I assume 
you're doing it with funky escape codes in PS1).  It should leave the terminal 
in the default color mode at the end of the pormpt, rather than rely on all 
the other color-using programs to fix it.

Comment 2 Sheldon Hearn freebsd_committer

2000-09-08 14:29:34 UTC

Responsible Changed
From-To: freebsd-bugs->joe

Joe, could you check out whether the problem lies in ls(1) 
or bash?

Comment 3 joe freebsd_committer

2001-06-29 14:24:58 UTC

State Changed
From-To: open->closed

Timeout on feedback.  If this is still a problem please open 
another PR.