towfiq@FTP.COM (Mark Towfiq) (02/22/91)
In article <jsrobins.667129377@galaxy.afit.af.mil> news@afit.af.mil writes:
I'm having problems editing large files over 300k with vi on our ATT 3B2.
We're running System V3.3 Unix. When I try to edit a large file, vi reads
in only a portion of the file and gives the "TMP file too large" error.
I have plenty of disk space under /usr/tmp where the temp files are written
and 48MB of RAM.
I hate to say it, but perhaps it's time to switch to Emacs....
--
Mark Towfiq, FTP Software, Inc. towfiq@FTP.COM
Work No.: +1 617 246 0900 Home No.: +1 617 488 2818
"The Earth is but One Country, and Mankind its Citizens" -- Baha'u'llahtchrist@convex.COM (Tom Christiansen) (02/22/91)
From the keyboard of news@afit.af.mil: :I'm having problems editing large files over 300k with vi on our ATT 3B2. :We're running System V3.3 Unix. When I try to edit a large file, vi reads :in only a portion of the file and gives the "TMP file too large" error. :I have plenty of disk space under /usr/tmp where the temp files are written :and 48MB of RAM. : :The question is: Is there some system parameter I can change to increase :the allowable size of the TMP file, or is this just another wonderful :"feature" of System V? Thank AT&T. Their vi, or at least some of its incarnations, has a filesize limit. Get the real vi from BSD or Sun and the problem will go away. If you can't do that, flame your vendor. --tom -- "UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." -- Doug Gwyn Tom Christiansen tchrist@convex.com convex!tchrist
basil@cbnewsm.att.com (joseph.d.balshi) (02/22/91)
In article <TOWFIQ.91Feb21111448@babyoil.FTP.COM> towfiq@FTP.COM writes: >In article <jsrobins.667129377@galaxy.afit.af.mil> news@afit.af.mil writes: > > I'm having problems editing large files over 300k with vi on our ATT 3B2. > We're running System V3.3 Unix. When I try to edit a large file, vi reads > in only a portion of the file and gives the "TMP file too large" error. > I have plenty of disk space under /usr/tmp where the temp files are written > and 48MB of RAM. > Try using split. This will break the file up into smaller manageable files that vi will be able to edit. - Basil - |**********************************|***********************************| | Internet: jdb@aloft.att.com | There's a town I know, | | UUCP: ...!att!aloft!jdb | Where the hipsters go, | | | Called Bedrock! | | | Twitch! Twitch! | | | -- Rock Roll | |**********************************|***********************************|
Dan_Jacobson@ATT.COM (02/22/91)
>>>>> On 21 Feb 91 16:14:48 GMT, towfiq@FTP.COM (Mark Towfiq) said:
Mark> I hate to say it, but perhaps it's time to switch to Emacs....
[just for the viewing public: standard GNU Emacs has 2 vi emulation modes,
here's one:]
VIP
***
VIP is a Vi emulating package written in Emacs Lisp. VIP implements most
Vi commands including Ex commands. It is therefore hoped that this package
will enable you to do Vi style editing under the powerful GNU Emacs
environment. This info file describes the usage of VIP assuming that you
are fairly accustomed to Vi but not so much with Emacs. Also we will
concentrate mainly on differences from Vi, especially features unique to
VIP.
[...]
--
Dan_Jacobson@ATT.COM Naperville IL USA +1 708-979-6364tchrist@convex.COM (Tom Christiansen) (02/22/91)
From the keyboard of Dan_Jacobson@ATT.COM: :>>>>> On 21 Feb 91 16:14:48 GMT, towfiq@FTP.COM (Mark Towfiq) said: : :Mark> I hate to say it, but perhaps it's time to switch to Emacs.... : :[just for the viewing public: standard GNU Emacs has 2 vi emulation modes, :here's one:] This is ATT's answer to having a sucky vi??? --tom -- "UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." -- Doug Gwyn Tom Christiansen tchrist@convex.com convex!tchrist
Dan_Jacobson@ATT.COM (02/22/91)
>>>>> On 21 Feb 91 21:22:00 GMT, tchrist@convex.COM (Tom Christiansen) said:
Tom> From the keyboard of Dan_Jacobson@ATT.COM:
Tom> :>>>>> On 21 Feb 91 16:14:48 GMT, towfiq@FTP.COM (Mark Towfiq) said:
Tom> :
Tom> :Mark> I hate to say it, but perhaps it's time to switch to Emacs....
Tom> :
Tom> :[just for the viewing public: standard GNU Emacs has 2 vi emulation modes,
Tom> This is ATT's answer to having a sucky vi???
Disclaimer: I do not necessarily represent an AT&T official view. I am
but one programmer. Followups: /dev/null.
--
Dan_Jacobson@ATT.COM Naperville IL USA +1 708-979-6364jgd@Dixie.Com (John G. DeArmond) (02/22/91)
towfiq@FTP.COM (Mark Towfiq) writes: >In article <jsrobins.667129377@galaxy.afit.af.mil> news@afit.af.mil writes: > I'm having problems editing large files over 300k with vi on our ATT 3B2. > We're running System V3.3 Unix. When I try to edit a large file, vi reads > in only a portion of the file and gives the "TMP file too large" error. > I have plenty of disk space under /usr/tmp where the temp files are written > and 48MB of RAM. >I hate to say it, but perhaps it's time to switch to Emacs.... I'm sure that Mr. Robins appreciated that answer. Switching to EMACS WOULD mean that he'd only have about 40 mb of RAM. To address the original question, you might first want to look at your ULIMIT. It could be that you're exceeding the ULIMIT in your temp file. Failing that, you may be running up against a compiled in limit reported to be in some versions of vi. If that is the case, then you can either try to get AT&T to fix the problem (harf! :-) or get a PD editor like steVIe or similiar and install it. If you have root access or can get it, try editing your file as root. That should override the user ULIMIT. (please be gentle if I'm wrong :-) My opinion is that ULIMIT is biting you. I've never experienced problems editing large files on 386/ix, any flavor of NCR Unix or AT&T Unix on a 3b2/400 once the ULIMIT problem is out of the way. John -- John De Armond, WD4OQC | "Purveyors of speed to the Trade" (tm) Rapid Deployment System, Inc. | Home of the Nidgets (tm) Marietta, Ga | {emory,uunet}!rsiatl!jgd |"Politically InCorrect.. And damn proud of it
cat@tygra.UUCP (CAT-TALK Maint. Account) (02/22/91)
In article <1991Feb21.183218.8617@convex.com> tchrist@convex.COM (Tom Christiansen) writes:
"
"Thank AT&T. Their vi, or at least some of its incarnations, has a
"filesize limit. Get the real vi from BSD or Sun and the problem will go
"away. If you can't do that, flame your vendor.
"
"--tom
Ditto SCO XENIX's vi (its probably a SYSV clone). It'll handle just under
500k before spitting out that message. We have ELVIS and STEVIE, but they
can't handle using TERMINFO instead of the error-riddled TERMCAP and the
arrow keys don't work at 2400bps or lower.guy@auspex.auspex.com (Guy Harris) (02/23/91)
>Thank AT&T. Their vi, or at least some of its incarnations, has a >filesize limit. Get the real vi from BSD Umm, the BSD "vi", or at least some of its incarnations, has a filesize limit, too; I think the problem is that AT&T didn't bother turning VMUNIX on when building "vi" in S5, while Berkeley did turn it on when building "vi" (well, "ex") in BSD.
news@afit.af.mil (02/24/91)
Well, If I had known I'd get so many responses to this vi problem, I'd have posted a lot sooner! I've got a much more accurate AND timely response from this board than I have from the ATT support line. As it turns out, ATT *cripples* some of their versions of vi with a file size limit. I assume it's to prevent resource conflicts on some of the smaller machines they market. If that's so, then you would think that they would send me a version with no limit or at least a much larger limit, right? Their answer: "Sure, if you just send us $$$, we'll send you an *enhancement* version." Needless to say, I didn't take them up on the offer. I guess I'll just work around it by splitting up the larger files, editing, and putting them back together again. Thanks again to all those who responded. John Robinson John S. Robinson Air Force Institute of Technology Instructor in Computer Engineering Wright Patterson AFB, OH 45433-6583 jsrobins@blackbird.afit.af.mil Work: (513) 476-4500
tchrist@convex.COM (Tom Christiansen) (02/24/91)
From the keyboard of news@afit.af.mil:
:As it turns out, ATT
:*cripples* some of their versions of vi with a file size limit.
:I assume it's to prevent resource conflicts on some of the smaller machines
:they market. If that's so, then you would think that they would send me a
:version with no limit or at least a much larger limit, right? Their answer:
:"Sure, if you just send us $$$, we'll send you an *enhancement* version."
I'm shocked and amazed. It brings to mind the punchline of an old joke:
We're the phone company. We don't care -- we don't have to.
--tom
--
"UNIX was not designed to stop you from doing stupid things, because
that would also stop you from doing clever things." -- Doug Gwyn
Tom Christiansen tchrist@convex.com convex!tchristbill@bilver.uucp (Bill Vermillion) (02/26/91)
In article <1991Feb22.142239.16509@tygra.UUCP> cat@tygra.UUCP (CAT-TALK Maint. Account) writes: >In article <1991Feb21.183218.8617@convex.com> tchrist@convex.COM (Tom Christiansen) writes: >"Thank AT&T. Their vi, or at least some of its incarnations, has a >"filesize limit. Get the real vi from BSD or Sun and the problem will go >"away. If you can't do that, flame your vendor. >Ditto SCO XENIX's vi (its probably a SYSV clone). It'll handle just under >500k before spitting out that message. We have ELVIS and STEVIE, but they >can't handle using TERMINFO instead of the error-riddled TERMCAP and the >arrow keys don't work at 2400bps or lower. Well there must be different versions of SCO's vi, because I have one that I have had files larger than 2 megs that I have edited. The Unix V.2.3 from Esix on another system I have dies at about 400k max. As a matter of fact I copied the vi from SCO onto the Unix box (I own them both). Just grabbed the history file and loaded in 50272 lines at 3,177,657 byte in size. This is SCO Xenix 2.3.0 with development system. -- Bill Vermillion - UUCP: uunet!tarpit!bilver!bill : bill@bilver.UUCP
jpp@tygra.UUCP (John Palmer) (02/27/91)
In article <1991Feb26.152650.12458@bilver.uucp> bill@bilver.uucp (Bill Vermillion) writes:
"
"Well there must be different versions of SCO's vi, because I have one that
"I have had files larger than 2 megs that I have edited. The Unix V.2.3
"from Esix on another system I have dies at about 400k max. As a matter of
"fact I copied the vi from SCO onto the Unix box (I own them both).
"Just grabbed the history file and loaded in 50272 lines at 3,177,657 byte
"in size.
"
"This is SCO Xenix 2.3.0 with development system.
"
I have SCO Xenix 2.3.2 with dev. sys. I tried the history file thing
and got "Temp file too large" at 10,305 lines, 518,144 characters. I
would think that the "buggy" vi would have been in the older version
with the correction in the newer (2.3.2) version, but hey - SCO is
always full of suprizes...gsteckel@vergil.East.Sun.COM (Geoff Steckel - Sun BOS Hardware CONTRACTOR) (02/28/91)
In article <1991Feb26.152650.12458@bilver.uucp> bill@bilver.uucp (Bill Vermillion) writes: " "Well there must be different versions of SCO's vi, because I have one that "I have had files larger than 2 megs that I have edited. The Unix V.2.3 " "This is SCO Xenix 2.3.0 with development system. " In article <1991Feb27.012643.21189@tygra.UUCP> jpp@tygra.UUCP (John Palmer) writes: - -I have SCO Xenix 2.3.2 with dev. sys. I tried the history file thing -and got "Temp file too large" at 10,305 lines, 518,144 characters. I -would think that the "buggy" vi would have been in the older version -with the correction in the newer (2.3.2) version, but hey - SCO is -always full of suprizes... Does SCO have the Missed'em V file size limits installed? If so, /etc/defaults should contain a file which login reads to set the maximum size file a user can write. This limit would cause the error symptoms displayed. geoff steckel (gwes@wjh12.harvard.EDU) (...!husc6!wjh12!omnivore!gws) Disclaimer: I am not affiliated with Sun Microsystems, despite the From: line. This posting is entirely the author's responsibility.
phil@ls.com (Phil Eschallier) (02/28/91)
In article <1991Feb27.012643.21189@tygra.UUCP> jpp@tygra.UUCP (John Palmer) writes: >In article <1991Feb26.152650.12458@bilver.uucp> bill@bilver.uucp (Bill Vermillion) writes: > >I have SCO Xenix 2.3.2 with dev. sys. I tried the history file thing >and got "Temp file too large" at 10,305 lines, 518,144 characters. I >would think that the "buggy" vi would have been in the older version >with the correction in the newer (2.3.2) version, but hey - SCO is >always full of suprizes... if you have sco xenix 2.3.+ for the 80386 you should have no problem using vi on larger files -- however, there is a problem with the vi that comes w/ the crypt suplement disk -- it restricts the size of the file. my work around was to install the crypt disk then copy vi to vi.crypt -- i then re-installed ex/vi from the operating install disk. this will allow me to use a real vi but use vi.crypt when necessary. -- Phil Eschallier | E-Mail to: US Mail to: | INET: phil@ls.com 248B Union Street Lagniappe Systems | UUCP: ...!uunet!lgnp1!phil Doylestown, PA 18901 Computer Services | CIS: 71076,1576 VOICE: +1 215 348 9721
bob@wyse.wyse.com (Bob McGowen x4312 dept208) (03/01/91)
In article <tim.667224648@holly> tim@dell.co.uk (Tim Wright) writes: >In <jsrobins.667129377@galaxy.afit.af.mil> news@afit.af.mil writes: > >>I'm having problems editing large files over 300k with vi on our ATT 3B2. >>We're running System V3.3 Unix. When I try to edit a large file, vi reads --- >got a brain-dead version. The System V/386 version doesn't suffer from Not true, in my experience. SysV/386 vi does works this way. In fact it is a real pain 'cause I cannot just look at any old big file (like /usr/adm/messages). >this ridiculous state of affairs (at least under ISC/SCO). You could moan at So ISC and SCO obviously changed the DEFINE. Without source, you would have to switch editors or use split. Complain to the supplier, maybe the info in this post can help them fix it. Bob McGowan (standard disclaimer, these are my own ...) Product Support, Wyse Technology, San Jose, CA ..!uunet!wyse!bob bob@wyse.com