Xref: utzoo unix-pc.general:3610 comp.sys.att:7354
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!indri!uakari.primate.wisc.edu!ctrsol!emory!skeeve!bagend!jan
From: jan@bagend.UUCP (Jan Isley)
Newsgroups: unix-pc.general,comp.sys.att
Subject: Re: uncompress and enhanced diagnostics
Summary: curiosity
Message-ID: <835@bagend.UUCP>
Date: 18 Aug 89 02:25:40 GMT
References: <486@manta.pha.pa.us> <19997@cup.portal.com> <785@bagend.UUCP> <8991@cbnews.ATT.COM>
Reply-To: jan@bagend.UUCP (Jan Isley)
Organization: Just me and my computers, Marietta, GA
Lines: 26

In article <8991@cbnews.ATT.COM> res@cbnews.ATT.COM (Robert E. Stampfli) writes:
>In article <785@bagend.UUCP> someone writes: (it was me)
>>
>>   PID TTY  TIME COMMAND
>> 12218  w1  3:35 uncompre
>>
>>About that time the notorious "no space left on device" appears, ls reveals:
>>-rw-r--r--  1 jan     users   7022592 Jul  3 00:22 s4diag 

>... deleted ... But, I can't understand why people
>allow this to happen in the first place.  There is a shell built-in called
>"ulimit" which will prevent files from growing past a certain size.
> ... etc ...
>It seems like this simple step would save a lot of hassles.

Yes, it can save lots of hassles.  Mine is usually set to 2048 also.  I was,
however, really curious to see just how far expire would run away with this.
You would think that it would notice that the output was bigger than the input
and stop.  In this case, even after I ran out of disk space, expire kept on
running.  I could delete a file and expire would crank up again and the file
would grow until it ran out of space again.

Jan
-- 
jan@bagend | gatech!bagend!jan | h (404)434-1335 | w (404)425-5700
	Humankind cannot bear very much reality.   T. S. Eliot