jdm@gssc.UUCP (03/20/87)
vi on system 5 is severely limited (in my opinion) by limiting the size of
files that can be edited. on bsd, i can vi a seemingly infinetly large
file (there is *some* limit, of course), but a file of a few hundred K or
so bugs out on system v with the complaint that the temp file is too large.
(yes, i have plenty of room on my filesystems.)
granted, i have use for this only on occasion, like editing a postscript
troff output file, but dammit, limitations are for toys, not real tools.
a related flame: sed is useless for binary files. if you want to change an
ascii string embedded in a binary file, forget it. sed wants to read \n
terminated lines and can't be told otherwise.
anyone have any other slick way to change the name of a subroutine embedded
in a .o? i would have thought that:
% sed 's/_func/_Func/' < mod.o > newmod.o
would have been great, but that doesn't work.
-- jdm
--
in real life: John D. Miller, Graphic Software Systems, Inc., Beaverton OR
...!{tektronix!verdix}!sequent!gssc!jdm (503) 641-2200
...!mntgfx!gssc!jdm "Roger. Go with throttle up."rbj@icst-cmr.arpa (03/30/87)
Anyone have any other slick way to change the name of a subroutine embedded
in a .o? i would have thought that:
% sed 's/_func/_Func/' < mod.o > newmod.o
would have been great, but that doesn't work.
Why don't you just edit it with emacs (any flavor). It doesn't care about
binary files.
-- jdm
in real life: John D. Miller, Graphic Software Systems, Inc., Beaverton OR
...!{tektronix!verdix}!sequent!gssc!jdm (503) 641-2200
...!mntgfx!gssc!jdm "Roger. Go with throttle up."
(Root Boy) Jim "Just Say Yes" Cottrell <rbj@icst-cmr.arpa>
The PILLSBURY DOUGHBOY is CRYING for and END to BURT REYNOLDS movies!!
P.S. But they probably don't use your grafix anyway. Does Pillsbury?ksand@mapper.UUCP (04/03/87)
In article <356@gssc.UUCP> jdm@gssc.UUCP (John D. Miller) writes: >vi on system 5 is severely limited (in my opinion) by limiting the size of >files that can be edited. on bsd, i can vi a seemingly infinetly large >file (there is *some* limit, of course), but a file of a few hundred K or >so bugs out on system v with the complaint that the temp file is too large. There is a virtual memory coded vi for NCR Tower/UNISYS 5000 series (SysV) - you can edit files up to the max virtual memory limit of 14 Mb. The only problem is to get it - it doesn't happen to exist in the installed op. system and thus is unsupported (sigh). Kent Sandvik -- NAME: Kent Sandvik, UNISYS UNIX Support, SWEDEN | Is it a gun in your pocket PHONE: (46) 8 - 55 16 39 job, - 733 32 35 home | or are you just glad to ARPA: enea!mapper!ksand@seismo.arpa | see me ? UUCP: ksand@mapper.UUCP | ***Famous Mae West***
jewett@hpl-opus.UUCP (04/04/87)
> vi on system 5 is severely limited (in my opinion) by limiting the size of > files that can be edited. Depends on the Sys V implementation and system parameters. I find I can "octed spice" on my HPUX (~SYS V) system. octed translates a binary file to ascii codes, then calls $EDITOR (vi), then translates back. It's similar to "bed" and "bpatch", which have been posted to the net. For spice (a circuit simulator) the ascii intermediate file is 4170896 bytes (4x the binary). It takes 5.5 minutes real, 2.5 minutes CPU, for the whole process on a 68020-based system. bpatch, posted by Steven List, has the advantage that it only translates a 256 byte page of the binary at a time. It takes less than a minute to search for and change "iob", which is near the end of the file. The disadvantage is that it has its own editing commands -- you don't get to use your own editor.
jdm@gssc.UUCP (04/07/87)
i would appreciate someone sending me the sources for bed and bpatch, binary
file editor/patcher.
here are the other suggestions i got for the two ailments i posted (system v
vi has a < 100K filesize limit && sed doesn't work with binaries.)
1. "use emacs." - if i worked on only one or two unix systems, maybe
this would work, but i work on multiple machines, with new ones all
the time, and it is not worth the time to port emacs everywhere i go.
2. "modify this line and recompile." - again, i can't spend time
dorking with standard tools everywhere i go.
3. "write your own program to.." - of course, that's what i did for the
"quick and dirty" fix, but it is not as functional as a finished editor.
my main gripe (this time) is vi's size restriction. at&t should bring the
tools up to snuff and leave the toy implementations to the dos boys.
NEWS FLASH: i just got some of my 3b2's "upgraded" to 5.3 and vi has departed
even further from the norm:
1. using ":n" on a modified file (yes, i have aw set) causes a status
message to be printed with "[Hit return to continue]" on the next line!
i hit return, the the next file's status line appears partly on the
"hit return" line, and partly on the next line, sometimes breaking
in the middle of a word, like it thinks it only has 40 columns to
write the message!! then, it makes you "hit return to continue"
again!!
2. using "vi -ta function" causes vi to edit "a" as it now expects
the tag option to be "vi -t function" or "vi -tfunction", even though
while actually in vi you must use :ta or :tag, as :t is undefined.
why does at&t enjoy busting things?
-- jdm
--
in real life: John D. Miller, Graphic Software Systems (GSS), Beaverton, OR
...!{tektronix!verdix}!sequent!gssc!jdm (503) 641-2200
...!mntgfx!gssc!jdm "Take time to smell the highway"