det@hawkmoon.MN.ORG (Derek E. Terveer) (01/14/91)
jc@minya.UUCP (John Chambers) writes: >This >isn't a ulimit problem; I've verified that vi (like all the rest >of my applications) has the largest ulimit that I've convinced >the system to accept, much large than half a Mbyte. I'm confused here. The ulimit basically applies to a particular shell session and is not attachable to a specific application, like vi. Perhaps you meant to say that "I have verified that my ulimit is >>.5MB?" -- Derek "Tigger" Terveer det@hawkmoon.MN.ORG - MNFHA, NCS - UMN Women's Lax, MWD I am the way and the truth and the light, I know all the answers; don't need your advice. -- "I am the way and the truth and the light" -- The Legendary Pink Dots
tim@delluk.uucp (Tim Wright) (01/14/91)
In <447@minya.UUCP> jc@minya.UUCP (John Chambers) writes: >Does anyone know if it's possible to do something about vi's absurdly >small file-size limit? This is an ESIX system, but I've stumbled >across the same problem on an assortment of other systems, so maybe >there's information to be learned about them, too. On the other hand, >this problem does seem to be specific to Sys/V; I've often edited >multi-Mbyte files on Suns and DECstations. >For instance, this machine has 16 Mbytes of memory, and has around >12 Mbyte free in the root partition, which should be sufficient to >edit some rather large files. But vi absolutely refuses to deal >with files over about 1/2 Mbytes; it says they're too big. This >isn't a ulimit problem; I've verified that vi (like all the rest >of my applications) has the largest ulimit that I've convinced >the system to accept, much large than half a Mbyte. >At the moment, I've sort of kludged my way around it by writing a >little program that breaks a big file up into little pieces, but of >course, doing it that way is a pain in several parts of the anatomy. >I have this suspicion that the size is hard-coded into vi, but I'd >be happy to learn how abysmally ignorant I am. "RTFM" would be quite >welcome, if someone can point out where in TFM this is described. You are correct in that the limit is effectively hard-coded. Vi has a define VMUNIX to say whether you're on a Vax or a pdp11, whoops, sorry this is 1991 :-) On the 3b2 and others (as you correctly point out), VMUNIX was not defined when vi was built hence the ridiculous limit. I'm surprised that ESIX has this error. The answer ? 1) Run vip-mode in GNU-emacs 2) better - run GNU emacs native and edit any file (including binaries) 3) get stevie (vi clone) 4) moan and get vi fixed for ESIX. Tim -- Tim Wright, Dell Computer Corp. (UK) | Email address Bracknell, Berkshire, RG12 1RW | Domain: tim@dell.co.uk Tel: +44-344-860456 | Uucp: ...!ukc!delluk!tim "What's the problem? You've got an IQ of six thousand, haven't you?"
fsfrick@bones.lerc.nasa.gov (David Fricker) (01/17/91)
In article <447@minya.UUCP> jc@minya.UUCP (John Chambers) writes: >Does anyone know if it's possible to do something about vi's absurdly >small file-size limit? My guess is that your problem is not vi but your filesystem. vi creates temporary files such as the file for the recover option, etc. In rough terms, the temporary files are 4-5 times the size of the original file. Double check the amount of free disk space that you have. The various systems I use tend to put the temporary files under /tmp or /usr/tmp. Hope this helps. -- ----------------------------------------------------------------------------- David Fricker | phone: 216-433-5960 NASA Lewis Research Center | M.S. 5-11
craig@attcan.UUCP (Craig Campbell) (01/18/91)
In article <1991Jan14.090434.2296@hawkmoon.MN.ORG> det@hawkmoon.MN.ORG (Derek E. Terveer) writes: >jc@minya.UUCP (John Chambers) writes: > >>This >>isn't a ulimit problem; I've verified that vi (like all the rest >>of my applications) has the largest ulimit that I've convinced >>the system to accept, much large than half a Mbyte. > >I'm confused here. The ulimit basically applies to a particular shell session >and is not attachable to a specific application, like vi. Perhaps you meant to >say that "I have verified that my ulimit is >>.5MB?" ulimit is an attribute inherrited from the parent by all child processes. Unless a program is running an effective uid of root, its ulimit may only be decreased. I beleive that John Chambers is completely correct. Remember that a particular shell session is merely a process running for a time. This process may spawn children (you run other programs). All the rules still apply in full force. >-- >Derek "Tigger" Terveer det@hawkmoon.MN.ORG - MNFHA, NCS - UMN Women's Lax, MWD
bill@bilver.uucp (Bill Vermillion) (01/18/91)
In article <1991Jan17.130822.27543@eagle.lerc.nasa.gov> fsfrick@bones.UUCP (David Fricker) writes: >In article <447@minya.UUCP> jc@minya.UUCP (John Chambers) writes: >>Does anyone know if it's possible to do something about vi's absurdly >>small file-size limit? >My guess is that your problem is not vi but your filesystem. vi creates >temporary files such as the file for the recover option, etc. In rough >terms, the temporary files are 4-5 times the size of the original file. >Double check the amount of free disk space that you have. The various >systems I use tend to put the temporary files under /tmp or /usr/tmp. Some systems are distributed with a vi that will NOT let you edit large files. I am running Esix 5.2.D, and just tested with a large file. It gives a tmp file too large error. I wrote that out and found that the file was 445k long. I then re-edited the file with vi from a Xenix system (they sit side by side here), and it swallowed the whole file, all 66k+ lines 3.2 megs. Same hardware, just two different versions of vi. I had this limit in the past when working on some old Motorola 68000 and Zilog Z8000 based systems, but this should NOT be acceptable in the iNTEL '386 based world. -- Bill Vermillion - UUCP: uunet!tarpit!bilver!bill : bill@bilver.UUCP
jc@minya.UUCP (John Chambers) (01/31/91)
In article <1991Jan14.090434.2296@hawkmoon.MN.ORG>, det@hawkmoon.MN.ORG (Derek E. Terveer) writes: > jc@minya.UUCP (John Chambers) writes: > > >This > >isn't a ulimit problem; I've verified that vi (like all the rest > >of my applications) has the largest ulimit that I've convinced > >the system to accept, much large than half a Mbyte. > > I'm confused here. The ulimit basically applies to a particular shell session > and is not attachable to a specific application, like vi. Perhaps you meant to > say that "I have verified that my ulimit is >>.5MB?" No, the ulimit is maintained by the kernel, on a per-process basis; it has nothing to do with a "shell session" (which is a concept that is not maintained by the kernel). A process's ulimit is inherited from the parent and may be decreased (or increased if you are a super-user) by using the ulimit(2) system call. If, within vi, you say :!ulimit then the ulimit printed is that of the ulimit process, which inherited it from the shell (started by the '!'), which inherited it from the vi process. Unless you are a super-user, the number produced is <= the ulimit of the vi process. -- All opinions Copyright (c) 1991 by John Chambers. Inquire for licensing at: Home: 1-617-484-6393 Work: 1-508-486-5475 Uucp: ...!{bu.edu,harvard.edu,ima.com,eddie.mit.edu,ora.com}!minya!jc