Karl.Kleinpaste@cbstr1.att.com (01/01/70)
krishna@athena.mit.edu writes:
AAAiiiieeee!!!
Truly "from the heart," I see. :-)
1. my 3B2/400 (and the other one I have been able to access) cannot cat into
or cat (as in display) files more than 1048576 bytes, or even cp this many.
That's not quite true. You're getting bitten by the ulimit, which
doesn't affect the size of files you can *read*, only those you can
*write*. But yes, you're having troubles writing big files.
3. uncompress, zcat don't work on a file this big on a 3B2/400, as
you might expect from the 1048576 byte limit on regular cat or cp.
(yeah, so, why don't you just copy the files one by one?)
Only partly true: uncompress/zcat won't *write a file* containing the
output of the full result of decompressing the file. The trick is
that you don't have to do that. Keep reading.
4. Main point: since the executable emacs is 1.5 meg, I am now
deathly afraid that 3 nights of staying up till 2 am trying to get the
damn thing going will end up in me having all the files, trying to
build emacs, and having Mr. 3B2 tell me that it can't build a file
this big, and me putting the 3B2 under my feet and jumping out the 2nd
story window.
You're working much, much too hard at this. I use GNU Emacs on dozens
of SysV machines with ulimit to bother me (including 11 3B2s,
ferpetesake) and I have gotten around all these sorts of problems.
[a] To extract the distribution, don't uncompress the distribution and
then tar the resulting output file; rather, do them both in one step.
This is the UNIX system, land of natural pipe controls:
zcat edist.tar-18.47.Z | tar xvf -
Poof, you're done. No files with size > 1Mb.
[b] If your binary is trying to be 1.5Mb long, you probably have -O
optimization turned on. Check your ymakefile and change
C_DEBUG_SWITCH to C_OPTIMIZE_SWITCH. (That's something of a misnomer
in the case of 3B{2,5,15}'s, because the optimizer is broken; but
C_OPTIMIZE_SWITCH at least turns the -O switch off.)
[c] Fundamentally, RTFM. Not to be rude, but it's true. Look in the
INSTALL file for a little info, also etc/MACHINES for a discussion of
the peculiarities of 3B2's using GNU Emacs. You'll notice that it
refers to a file ulimit.hack in the etc/ directory; that's something I
sent to RMS many months ago which I use to fix the basic ulimit
problem on SysVRel2 3B2's by stuffing a rude little program in between
kernel initialization and startup of init - it's installed as
/etc/init, and it gets exec'd by the kernel first and foremost, futzes
the ulimit appropriately so you don't get bitten any more, and then
exec's the real init. Look it over, and run it as a shell script;
it's completely self-installing.
KarlKarl.Kleinpaste@cbstr1.att.com (08/21/87)
In article <332@cbstr1.att.com> I can't believe I wrote:
[b] If your binary is trying to be 1.5Mb long, you probably have -O
optimization turned on. Check your ymakefile and change
C_DEBUG_SWITCH to C_OPTIMIZE_SWITCH. (That's something of a misnomer
in the case of 3B{2,5,15}'s, because the optimizer is broken; but
C_OPTIMIZE_SWITCH at least turns the -O switch off.)
Erph, boy, must have been a long night just before typing that.
Obviously, I meant that a binary trying to be 1.5Mb long means that
the -g debugger-info option was on. Use of -O would turn on
optimization and would reduce the size of the resulting binary. But
the problem is that the 3B{2,5,15} optimizer is broken, and one should
simply turn both -g and -O off; for the 3B{2,5,15}, one does this with
C_OPTIMIZE_SWITCH, which has a null expansion. Jeesh. Sorry.
Egg on my face and all that rot,
Karl