Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!seismo!sundc!newstop!sun!sally!plocher
From: plocher@sally.Sun.COM (John Plocher)
Newsgroups: comp.unix.i386
Subject: Re: vi: Tmp file too large - ULIMIT?
Message-ID: <131448@sun.Eng.Sun.COM>
Date: 8 Feb 90 08:38:48 GMT
References: <8655@cbnewsm.ATT.COM> <15108@bfmny0.UU.NET> <3P91VN6ccs@ficc.uu.net> <1235@rsiatl.UUCP>
Sender: news@sun.Eng.Sun.COM
Reply-To: plocher@sun.UUCP (John Plocher)
Distribution: usa
Organization: Sun Microsystems, Mountain View
Lines: 36

+-- In <1235@rsiatl.UUCP> jgd@rsiatl.UUCP (John G. De Armond) 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 :-)
+--

No, not obviously.

The simple case is that you ran out of space in the root filesystem
and that the temp file (in /tmp) really was too large. :-)

The other case would be plausable if you weren't using the same
version of ISC Unix that John G. De Armond was using:

All the versions of vi source that I have seen have a define called
VMUNIX.  If that is not set, the code assumes a "Swapping" type of
memory subsystem (ala pdp11/Vr3.0...) and sets up things so that you
have fixed size tables (for line pointers...).  This effectively
limits you to "small" files (less than some number of lines) In the
Microport Vr3 386 case I was hitting the limit at less than 300k for
normal C source files.

If you define VMUNIX, the code assumes virtual memory and tries to
dynamically allocate things.

This does two things; the startup time is much less (no big data
structures to initialize) and you can suddenly edit huge files.  I
successfully edited a 30Mb file with the recompiled version...

What *is* obvious here is that ISC has recompiled vi with the VMUNIX
define turned on.

AT&T (for one) ships their version  without it defined.

   -John Plocher