htc@cbnewsm.ATT.COM (hyun-taek.chang) (01/18/90)
I have a 386 box running with AT&T System V/386 R3.2.1. I cannot edit a large text file (~450K) using 'vi'. It complains 'Tmp file too large' and switches to 'ed' mode. Also, neither can I uncompress a big file (~1.5M) nor make a big tar file. I've changed ULIMIT in /etc/conf/cf.d/stune file to 8192 and rebuilt the kernel as described in the Administration Guide. (I've modified ULIMIT in /etc/default/login file also) But it doesn't help. The problem remained same even I tried it as a superuser. What's wrong? Oh, I have a plenty of free disk space. Hyun-Taek Chang htc%m3ux@research.att.com
jgd@rsiatl.UUCP (John G. De Armond) (01/24/90)
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** |
dyer@spdcc.COM (Steve Dyer) (02/08/90)
In article <1235@rsiatl.UUCP> jgd@rsiatl.UUCP (John G. De Armond) writes: >You obviously hit a ulimit :-) >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. "Tmp file too large" has nothing to do with ulimit. It has to do with versions of "vi" which have fixed array sizes, a frequent bug in programs which originated on the PDP-11 and whoise sizes have only been adjusted in later releases rather than being redesigned for a virtual memory environment. If you haven't seen this with 386/ix, they've either chosen large enough manifest constants for you not to notice or they attacked the problem earlier. -- Steve Dyer dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer dyer@arktouros.mit.edu, dyer@hstbme.mit.edu
plocher@sally.Sun.COM (John Plocher) (02/08/90)
+-- 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
cpcahil@virtech.uucp (Conor P. Cahill) (02/09/90)
In article <1235@rsiatl.UUCP> jgd@rsiatl.UUCP (John G. De Armond) writes: >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 :-) No. They had a problem with thier stock vi. A little research has shown that the system V R3.2 vi distributed by AT&T, intel and I belive ESIX has been compiled with very restricted limits on the number of lines in a file, number of rows/cols of a display and other such stuff. The version released in SV R3.1 has much more expansive limits. A quick look at the 386/ix vi (using strings /usr/bin/vi | grep Version) will show that it is running version 3.1. Maybe version doesn't correspond to Release, but there is a difference. And I did try to edit a large file with the vi from my Bell Tech SV R3.1 and it was able to edit large files. -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
rjd@dell.dell.com (Randall J. Davis) (02/10/90)
In article <131448@sun.Eng.Sun.COM> plocher@sun.UUCP (John Plocher) writes: |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. Best I can remember from looking at the source a while back, it is limited by number of characters in the swapping version, not number of lines. The limit is normally 256k bytes. It has a predefined #define that you can employ to bump it up to double that value at compile time. Randy Davis UUCP: dell.dell.com!rjd