Bug 18900

Summary: patch to add colorizing feature to /bin/ls
Product: Base System Reporter: Andre Albsmeier <Andre.Albsmeier>
Component: binAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 3.4-STABLE   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
file.diff none

Description Andre Albsmeier 2000-05-30 11:20:01 UTC 
The misc/colorls port adds the colorizing feature to ls and
installs the resulting executable as colorls.

It would be nice to have this feature in /bin/ls so other changes
to /bin/ls don't have to be ported to the distfile on which
the misc/colorls port relies.

The patch below adds this feature to /bin/ls. It is based on
patch-aa from the port with some minor changes to make -Wall
quiet. The manpage has been updated as well.

The colorizing feature is only used if -G has been specified.
Otherwise, /bin/ls behaves completely as it did before. All the
colorizing code is only enabled if the f_color variable has been
set by the -G command line option.

The resulting /bin/ls is 195720 bytes in size. It has been
194568 bytes before so the difference is only 1152 bytes
which should be acceptable even for a file in /bin :-).

Fix: Since I am currently sitting in the Dominican Republic with my
laptop, I have only access to the 3.4-STABLE sources. So the
patch is based on 3.4-STABLE but I don't think /bin/ls differs
a lot between the various versions of FreeBSD.

If you want me to make a patch against -current or 4-STABLE, I
will do so if this helps getting it commited.
How-To-Repeat: 
/bin/ls -lG /
Comment 1 DougB 2000-05-30 16:32:13 UTC 
[snippage]

Andre Albsmeier wrote:

> The misc/colorls port adds the colorizing feature to ls and
> installs the resulting executable as colorls.
> 
> It would be nice to have this feature in /bin/ls so other changes
> to /bin/ls don't have to be ported to the distfile on which
> the misc/colorls port relies.

> The resulting /bin/ls is 195720 bytes in size. It has been
> 194568 bytes before so the difference is only 1152 bytes
> which should be acceptable even for a file in /bin :-).

	For some absurd reason, including this in the base system has, in the
past been some sort of religious war. It's high time for the aburdity to
end. The facts about this are simple:

Many people want it.
If YOU don't want it, YOU don't have to use it. 
We have a good, working version.
Looking at the current state of things, it adds almost nothing to the
3.5 megs of binaries in /bin. 

	This patch applies to -Current, but needs a small adjustment to account
for the -n option. 

Doug
-- 
        "Live free or die"
		- State motto of my ancestral homeland, New Hampshire

	Do YOU Yahoo!?
Comment 2 Andre Albsmeier 2000-05-30 18:00:58 UTC 
On Tue, 30-May-2000 at 08:32:13 -0700, Doug Barton wrote:
> [snippage]
> 
> Andre Albsmeier wrote:
> 
> > The misc/colorls port adds the colorizing feature to ls and
> > installs the resulting executable as colorls.
> > 
> > It would be nice to have this feature in /bin/ls so other changes
> > to /bin/ls don't have to be ported to the distfile on which
> > the misc/colorls port relies.
> 
> > The resulting /bin/ls is 195720 bytes in size. It has been
> > 194568 bytes before so the difference is only 1152 bytes
> > which should be acceptable even for a file in /bin :-).
> 
> 	For some absurd reason, including this in the base system has, in the
> past been some sort of religious war. It's high time for the aburdity to

Oops, it didn't know that. I follow FreeBSD for 4 years now and never
saw discussion about this :-)

> end. The facts about this are simple:
> 
> Many people want it.
> If YOU don't want it, YOU don't have to use it. 
> We have a good, working version.
> Looking at the current state of things, it adds almost nothing to the
> 3.5 megs of binaries in /bin. 

So, what does us keep from committing it :-) ?

> 
> 	This patch applies to -Current, but needs a small adjustment to account
> for the -n option. 

Ahh, I see. There are two small rejections in ls.1 and ls.c which are
easily fixable.

	-Andre


> 
> Doug
> -- 
>         "Live free or die"
> 		- State motto of my ancestral homeland, New Hampshire
> 
> 	Do YOU Yahoo!?

-- 
Micro$oft: Which virus will you get today?
Comment 3 Tim Vanderhoek 2000-05-31 04:27:03 UTC 
On Wed, May 31, 2000 at 02:05:54AM +0100, Brian Somers wrote:
> > 
> > 	So, other than on "purist" grounds, are there any other
> > objections?
> 
> Yes, but I can't think of any at the moment !!! <grumble!>

Well, the problem really calls for a more general solution.  I'd like
to be able to tell ls to list larger files using different shades of a
colour that correspond to the size.  I'd like it to simply not list
some types of files.  I'd like it to support all the primitives that
find(1) supports.

And I'd like it to do this with an interface intuitive enough that I
need only a cursory glance at the manpage to remember it.

Terry, I believe, is fond of saying: better is the enemy of best.
There is no best.  There is no pure.  This is a dark and troubled
world in which we live.

Gentlement, let our `ls` be the light to the world.


> Bah !

Bah! indeed!


-- 
Signature withheld by request of author.
Comment 4 joe freebsd_committer freebsd_triage 2000-06-02 16:19:44 UTC 
State Changed
From-To: open->closed

I've merged this into 5.0's ls.  I've also added the patch from 
ports/18616 and changed the symlink handling slightly so that it 
behaves exactly the same way with or without colour support.