Description of Problem:

tree dumps core if LS_COLORS is big.

How Reproducible:

When $LS_COLORS really big ("echo $LS_COLORS | wc -c" gives over 1500
here, and in DIR_COLORS I can grep over 100 lines with the char ";", aka
over 100 with colour info), and tree is invoked with colour option. If no
colour or piped, it works fine. 

Steps to Reproduce:
1. Edit /etc/DIR_COLORS to add lots of entries, or set a big $LS_COLORS
(but valid data, it is not due wrong data).
2. Do tree in a dir where you can write, and instead of the list you get
a new file named core.
3. >Pick core. "The core is recent" >Examine core. "This core was created
by tree" :]

Actual Results:

Cores with colors, no cores if piped to somewhere or the nocolor
option is used. The core happens before anything can be shown.

Expected Results:

A nice ASCII representation of the files, with colour if requested,
but never cores.

Additional Information:
	
I talked with the coder of tree some months (years?) ago, and after
some comments about what was going on in the traces I did, he pointed
me to an area of the code, asking me to change an array size. I did,
and it works now. So the problem is that the array was too small for
my LS_COLORS info. Another solution would be to change that code to
use lists.

Dunno why has not been fixed yet, cos the first time I saw it I think
7.0 had not been released, and I have patched my files two or three
times.

Here is a diff based in the tree.c I got from the RH71 SRPM:

---8<---
--- tree.c-new  Mon Jul 16 01:13:14 2001
+++ tree.c      Mon Jan  6 04:56:17 1997
@@ -752,7 +752,7 @@
 char **parse(b)
 char *b;
 {
-  static char *arg[1000];
+  static char *arg[100];
   int i, j;
 
   for(j=0;*b;b++) {

--->8---

I use around 140 of the array now, so 1000 should be enough until
a real solution is applied. I guess few people use so many entries, but
I would like to see the solution applied.