Bug 20291

Summary: [PATCH] ls refuses to output color to anything that's not a tty
Product: Base System Reporter: mike ryan <msr+fbsd>
Component: binAssignee: joe <joe>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 4.1-STABLE   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
file.diff none

Description mike ryan 2000-07-29 20:10:02 UTC
	/bin/ls refuses to generate ansi color codes unless stdout is a
	terminal.  this prevents "ls -G | less -R" from working, for
	instance.

Fix: the patch below forces color output if two -G flags are used.
	this allows "ls -GG | less -R" while preserving existing -G
	behavior.
How-To-Repeat: 
	/bin/ls -G | /usr/bin/less -R
Comment 1 Sheldon Hearn 2000-07-31 10:45:58 UTC
On Sat, 29 Jul 2000 15:04:45 -0400, mike ryan wrote:

> 	the patch below forces color output if two -G flags are used.
> 	this allows "ls -GG | less -R" while preserving existing -G
> 	behavior.

I think that this takes a bad situation and makes it worse.

I think that if some serious thought had gone into colour support in the
base system, it would be conditional on the value of an environment
variable.  This would allow different values for this variable to
control different requirements for colour support.

Given the limitations of a command-line argument, I think that ls should
just always spit colour out when the command-line argument is specified.

The argument that most folks put -G in a shell alias is exactly the
motivation for using an environment variable instead.

But this isn't an environment variable; it's a command-line option
and should be treated as such.  If the user provides the command-line
argument that requires colour, then he should get colour, damnit. :-)

Ciao,
Sheldon.
Comment 2 Sheldon Hearn freebsd_committer freebsd_triage 2000-07-31 10:46:13 UTC
Responsible Changed
From-To: freebsd-bugs->joe

Your mess, you clean it up. :-)
Comment 3 joe freebsd_committer freebsd_triage 2000-08-12 23:40:32 UTC
State Changed
From-To: open->closed

Closed, please refer to PR#bin/20483.