ascii-2-ascii filter for VI?

ascii-2-ascii filter for VI?

Post by USENET News Syst » Fri, 20 Sep 1991 13:00:08



I've got a2b and b2a filters. b2a lets you work on any file. However, I am
looking for something which lets you

set wm=5

on existing files, i.e. convert files with long lines to a certain length,
BUT break them at a white space.

I found an editor called bed. Does anybody have a man page for it. It's
supposed to be a vi for binaries.

Thanx

Raminder Singh                              Phone : +64 6 356 9099 X 7772
Computer Centre MASSEY UNIVERSITY           Fax   : +64 6 350 5607

 
 
 

ascii-2-ascii filter for VI?

Post by Tom Christians » Fri, 20 Sep 1991 14:32:32



:I've got a2b and b2a filters. b2a lets you work on any file. However, I am
:looking for something which lets you
:
:set wm=5
:
:on existing files, i.e. convert files with long lines to a certain length,
:BUT break them at a white space.

So all you need is a version of fold that breaks at word boundaries?
Sounds like what you need is around 3 lines of perl...

    #!/usr/bin/perl

    eval "format =\n^" . (">" x $cols) . " ~~\n\$_\n.\n";
    write while <>;

This works pretty much like the fold(1) man page, except for breaking at
word-boundaries.

--tom

 
 
 

ascii-2-ascii filter for VI?

Post by Tom Christians » Fri, 20 Sep 1991 22:26:30




:>looking for something which lets you
:>
:>set wm=5
:>
:>on existing files, i.e. convert files with long lines to a certain length,
:>BUT break them at a white space.
:
:Assuming that if a word has 6 characters you want to print it on one line,
:   fmt -5
:will work if you have it.  

No, that won't work.  First of all, fmt grabs words from shorter lines
to make longer ones, not just taking long ones and making shorter
ones.  Also, fmt -5 would give you a lot of VERY short lines.

--tom

 
 
 

ascii-2-ascii filter for VI?

Post by Tom Christians » Sat, 21 Sep 1991 05:03:39


:    #!/usr/bin/perl

:    eval "format =\n^" . (">" x $cols) . " ~~\n\$_\n.\n";
                           "<"
:    write while <>;

Or it will be ragged left, instead of ragged right, which looks funny.

--tom

 
 
 

ascii-2-ascii filter for VI?

Post by Mitchell Wyle - Inf. 254 72 » Sat, 21 Sep 1991 15:54:50




>So all you need is a version of fold that breaks at word boundaries?
>Sounds like what you need is around 3 lines of perl...

>    #!/usr/bin/perl

>    eval "format =\n^" . (">" x $cols) . " ~~\n\$_\n.\n";
>    write while <>;

How do you unfold?

vi on SunOS is now 8-bit clean.  If it could handle arbitrarily long lines,
one could use vi like emacs to edit a.out and other binary files.
if fold(1) can chop up a binary, how can one glue it back together?

Why would one ever want to edit a.out files you may well ask?

Some packages are installed here with machine-specific, hard-coded
paths.  Users will often copy the binary, emacs it, change the path,
and then use the local version of it. (Of course the new path must be
exactly the same length as the string in the orig.) Many users here
don't have internet access or don't have time to re-configure a private
copy of big packages like TeX.

Another reason one might want to edit binary files with big lines is to
change text produced by programs like MS-Word in vi.

 
 
 

ascii-2-ascii filter for VI?

Post by Tom Christians » Sat, 21 Sep 1991 17:58:59



:How do you unfold?

Didn't know you wanted reversible filters.

I just edited vi source and added a 0 to the line length max
and window size maximums.  Cheap, easy, and useful, and of course,
suboptimal.  But it worked.

:vi on SunOS is now 8-bit clean.  If it could handle arbitrarily long lines,
:one could use vi like emacs to edit a.out and other binary files.
:if fold(1) can chop up a binary, how can one glue it back together?

Doesn't anyone remember how to use adb anymore?

I actually keep one of these around for punching strings into binaries:

    #!/usr/local/bin/perl
    $ARGV[0] eq '-f' && ($force++, shift);
    die "usage: puts [-f] addr old new exec\n"

    if (length($new) > length($old)) {
        warn "new string longer than old string\n";
        exit unless $force;
    }
    $addr = oct($addr) if $addr =~ /^0/;
    open(EXEC, "+<$binary") || die "can't open $binary for update: $!";
    seek(EXEC, $addr, 0);
    read(EXEC, $was, length($old));
    if ($was ne $old) {
        print STDERR "old string was \"$was\", should be \"$old\"!\n";
        exit unless $force;
    }
    $new .= "\0";
    seek(EXEC, $addr, 0);
    print EXEC $new;
    close EXEC;
    print "$binary updated\n";

I guess I don't really need the old string, but it helps me make
sure I'm doing the write thing in the write place.

--tom

 
 
 

ascii-2-ascii filter for VI?

Post by peter da sil » Sun, 22 Sep 1991 23:31:30



> Doesn't anyone remember how to use adb anymore?

Yeh. You haven't lived until you've used "adb -w" to edit your kernel right
before a major demo, because there wasn't time for a rebuild.

Unfortunately, few new UNIX systems come with ADB any more. SDB is arguably
a better de*, but ADB was a much more useful all-around tool. These
days I keep a copy of a freeware program called "xvi" handy. It's too much
to expect to be able to carry a working copy of GNU emacs around on a floppy
for such occasions, you know.
--
-- Peter da Silva
-- Ferranti International Controls Corporation
-- Sugar Land, TX  77487-5012;  +1 713 274 5180
-- "Have you hugged your wolf today?"

 
 
 

ascii-2-ascii filter for VI?

Post by Silv » Mon, 23 Sep 1991 15:35:55


wyle> If [vi] could handle arbitrarily long lines, one could use vi like
wyle> emacs to edit a.out and other binary files.

vi can't handle arbitrary-lengthed lines?  Hee hee, and people wonder that
users of real text editors bust vi's chops so much?  I define text the same
way I define string, an arbitrarily long sequence of arbitrary characters
with a known length.  It's not unreasonable to restrict characters to the
ASCII set because of its prevalence.  It's not unreasonable to restrict
length based upon a relatively large standard implementation limit.  But
limiting the distance between line-break indicators, in this reference, is a
very stringent restriction on the set of editable strings.  The phrase "a
text editor with a line-length limit" is a contradiction in terms.  How
prevalent is this idiocy among the more recent vi implementations?  (I can
only speak for GNU Emacs pseudo-vi emulations, which accomodate lines of
arbitrary length.)


              `Gun for Hire'

 
 
 

ascii-2-ascii filter for VI?

Post by peter da sil » Wed, 25 Sep 1991 03:22:30



> wyle> If [vi] could handle arbitrarily long lines, one could use vi like
> wyle> emacs to edit a.out and other binary files.
> vi can't handle arbitrary-lengthed lines?  Hee hee, and people wonder that
> users of real text editors bust vi's chops so much?

Emacs won't run on a PDP-11? And people wonder why real users without unlimited
hardware budgets dump on Emacs so much?

Quote:> [highly opinionated flame about what constitutes a line deleted]

--
-- Peter da Silva
-- Ferranti International Controls Corporation
-- Sugar Land, TX  77487-5012;  +1 713 274 5180
-- "Have you hugged your wolf today?"
 
 
 

ascii-2-ascii filter for VI?

Post by Silv » Wed, 25 Sep 1991 09:08:26


gaynor> vi can't handle arbitrary-lengthed lines?  Hee hee, and people wonder
gaynor> that users of real text editors bust vi's chops so much?

Er, "real text editors" as in "editors capable of editing any file which has a
text representation".

peter> Emacs won't run on a PDP-11?  And people wonder why real users without
peter> unlimited hardware budgets dump on Emacs so much?

The truth hurts.  GNU Emacs should have been written in a machine precision
independent fashion.

peter> [highly opinionated flame about what constitutes a line deleted]

This portion of my discussion was neither highly opinionated nor flamable.
There is simply not a lot of leeway in the definition of `text'.  Distance
between eol indicators is irrelevant.

Regards, [Ag]

 
 
 

ascii-2-ascii filter for VI?

Post by Larry Margol » Thu, 26 Sep 1991 04:25:45



Quote:> This portion of my discussion was neither highly opinionated nor flamable.
> There is simply not a lot of leeway in the definition of `text'.


Quote:> I define text the same
> way I define string, an arbitrarily long sequence of arbitrary characters
> with a known length.

I just looked up the word "text" in the dictionary, and saw nothing like what
you wrote.  So, perhaps there's not much leeway in *your* definition of text,
but that doesn't necessarily apply to other definitions.  *I* define text as
a sequence of lines in a file.  I care about the lines I see on my screen, not
about the internal representation.

Quote:> Distance between eol indicators is irrelevant.

*Existance* of eol indicators is irrelevant.  I don't care if the file is
represented on disk as an ASCII stream, with the lines delimited by LF's;
if it's an array of pointers to strings; or if it's a doubly-linked list
of line structures.  I just want to be able to deal with my *lines* of text.


 
 
 

ascii-2-ascii filter for VI?

Post by peter da sil » Thu, 26 Sep 1991 00:32:41



> gaynor> vi can't handle arbitrary-lengthed lines?  Hee hee, and people wonder
> gaynor> that users of real text editors bust vi's chops so much?
> Er, "real text editors" as in "editors capable of editing any file which has a
> text representation".

Fine, I'll take an intel hex dump, split it, edit that, then concatenate it
and run undump on it. The hex dump is the text representation.

Quote:> peter> Emacs won't run on a PDP-11?  And people wonder why real users without
> peter> unlimited hardware budgets dump on Emacs so much?
> The truth hurts.  GNU Emacs should have been written in a machine precision
> independent fashion.

Machine address-space independent, too.

Quote:> This portion of my discussion was neither highly opinionated nor flamable.
> There is simply not a lot of leeway in the definition of `text'.  Distance
> between eol indicators is irrelevant.

Sure there is. There are more definitions of what constitutes "text" than
you can shake a stick at.  One of them is "the executable code segment of
a UNIX program".

The common usage of "text" refers to human readable data organised as a
collection of strings of ascii characters (lines). Tools used to manipulate
these strings frequently place limits on their length.

VI is easily applicable to a smaller set of problems than Emacs, I will
freely admit that, but it requires far fewer resources and is much more
standardised.

And Emacs has its own design problems. We haven't had a good flame war over
Emacs and VM (the buffer gap method tends to thrash VM when jumping around
much) lately.

You seem to have this basic assumption that Emacs is clearly a win over vi
in all circumstances. I contend that this is only true in an extremely
resource-rich environment... and even then start-up time is high enough
that you need to keep it around most of the time even when you're not using
it...
--
-- Peter da Silva
-- Ferranti International Controls Corporation
-- Sugar Land, TX  77487-5012;  +1 713 274 5180
-- "Have you hugged your wolf today?"

 
 
 

ascii-2-ascii filter for VI?

Post by Silv » Thu, 26 Sep 1991 07:39:20


peter> And Emacs has its own design problems. We haven't had a good flame war
peter> over Emacs and VM (the buffer gap method tends to thrash VM when jumping
peter> around much) lately.

I'm not real fond of an unembellished buffer gap implementation myself.

peter> You seem to have this basic assumption that Emacs is clearly a win over
peter> vi in all circumstances.

I'm biased, yes, but not blind, for instance, my occasional references to GNU
Emacs as `that porker' and the like.  But I acknowledge emacs's disadvantages
comfortable in the knowledge that its advantages more than make up for them.

Regards, [Ag]

 
 
 

ascii-2-ascii filter for VI?

Post by Mitchell Wyle - Inf. 254 72 » Thu, 26 Sep 1991 16:27:02


GNU-Emacs is the "official" editor taught to students here.  Each
student runs at least three emacs-tools or x-emacs processes on the
memory starved file servers, so they swap a lot :-(

Never having invoked emacs (I would not know how to quit if I did) I am
not much help when they ask me questions about ETAGS and Compile.  I
send them to the emacs gurus and the documentation.

They all ask about a PC version and I tell them about micro-Emacs.
They report back that it is not gnu-compatible enough.  They want
ETAGS, Compile, some of the C coding modes, but don't need the
full-blown 257 commands, lisp machine, shell, mail UA, mail MTA, gnews,
vmunix.el, scsi-bus-driver.el or the 4 Gigabyte hyper-media browser
documentation and associated .el code.

Quote:>Emacs won't run on a PDP-11? And people wonder why real users without
>unlimited hardware budgets dump on Emacs so much?

Is there a gnu-emacs config for Brief or a micro-emacs dialect with the
same default key bindings and some of the C-coding stuff?

Elvis (a vi clone) on DOS is great.