Re: /bin/ls is impure!

[Chris Danis <screechco@home.com>]

>>>>> On Wed, 19 Sep 2001, "Norbert" == Norbert Veber wrote:
[snip]
  Norbert> --> Now run ls.

I can reproduce this.

[snip]
  Norbert> Be prepared to abort it before it consumes all the available
  Norbert> memory on your system.
[snip]
  Norbert> To me it looks like this would be a bug in ls, though I
  Norbert> cant figure out what is causing it, or why it happens after
  Norbert> running purity.  The environment is unchanged, the aliases are
  Norbert> unchanged, the only difference is that ls no longer works.

Did you check the COLUMNS environment variable?

brooks% echo $COLUMNS
80
brooks% /usr/games/purity list
welcome to the purity test.  the current available tests are:

mtrek  - see how muck of an mtrek geek you are...
nerd   - tests to see how "nerdy" you are...
hacker - a hard core computer hacker purity test.

format - an explanation of the data file format (for writing your own tests)
sample - prints a generic sample datafile

to run each test, use "purity <type_of_test> [flags]".

bye.
brooks% echo $COLUMNS
49151

IIRC the memory use of the algorithm ls uses to sort its output into
varying-length columns increases greatly with wider terminals. Something 
this absurdly large will cause the algorithm to start eating RAM, just as 
reported. However, *why* COLUMNS gets set so big is another matter...

purity seems to be causing this. No idea why or how, but it seems to be 
the culprit.

thanks,

-chris
-- 
"Meat. They're made out of meat."

"It's better than bad, it's good!"

(I subscribe to all lists that I post to; please do not Cc me on list
reply)
Chris Danis                                 screech@mad.scientist.com
danish@debian.org                                  screechco@home.com
Debian GNU/Linux - www.debian.org                    dadanish@usa.net