Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!rsiatl!jgd From: jgd@rsiatl.UUCP (John G. De Armond) Newsgroups: comp.unix.i386 Subject: Re: vi: Tmp file too large - ULIMIT? Message-ID: <1235@rsiatl.UUCP> Date: 24 Jan 90 10:01:12 GMT References: <8655@cbnewsm.ATT.COM> <15108@bfmny0.UU.NET> <3P91VN6ccs@ficc.uu.net> Reply-To: jgd@rsiatl.UUCP (John G. De Armond) Distribution: usa Organization: Radiation Systems, Inc. (a thinktank, motorcycle, car and gun works facility) Lines: 36 In article <3P91VN6ccs@ficc.uu.net> karl@ficc.uu.net (Karl Lehenbauer) writes: >>>I cannot edit a large text file (~450K) using 'vi'. >>>It complains 'Tmp file too large' and switches to 'ed' mode. You obviously hit a ulimit :-) >>There are vi clones running around, perhaps one already accepts huge >>files or could be patched to do so. I don't doubt the right EMACS can >>do it too. > >Elvis (a vi clone) can edit files up to about 500K unmodified >on a 386, which is much more than vi can. Subjectively, it's >a lot faster, too, tho' that's from the console. peter@sugar >says it's slower at low baud rates because the real vi is really >smart about minimizing number of characters transmitted or >screen updates. > Why do a clone when the gen-u-wine vi with 386/ix will do the job. I routinely edit my mbox file looking for old letters. (No, dammit, I DON'T have elm up yet :-) I just looked at its size and was somewhat surprised to see that it's >> 1 meg! Vi brought it up in about 10 seconds, and that with news unbatching running in the background. I've never hit a file too big to edit, assuming the line lengths are reasonable. I could see no real reason for there to be a practical limit because even if they are using an int as a line counter, a 32 bit int is pretty big. John -- John De Armond, WD4OQC | The Fano Factor - Radiation Systems, Inc. Atlanta, GA | Where Theory meets Reality. emory!rsiatl!jgd **I am the NRA** |