Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!mit-eddie!uw-beaver!milton!ogicse!intelhf!ichips!inews!pima!bhoughto
From: bhoughto@pima.intel.com (Blair P. Houghton)
Newsgroups: comp.unix.questions
Subject: Re: PD binary or hex editor for UNIX
Message-ID: <2936@inews.intel.com>
Date: 9 Mar 91 22:22:08 GMT
References: <3422@unisoft.UUCP> <ADRIANHO.91Mar6234142@barkley.watt.berkeley.edu>
Sender: news@inews.intel.com
Organization: Intel Corp, Chandler, AZ
Lines: 36

In article <ADRIANHO.91Mar6234142@barkley.watt.berkeley.edu> adrianho@barkley.watt.berkeley.edu (Adrian J Ho) writes:
>USE EMACS!!!  8-)
>Seriously, emacs allows you to edit binary files just like any other.

This is the only reason I never did

    #! /bin/sh
    for i in `sed 's/^[^:]*:\([^:]*\):.*$/\1/' < /etc/fstab`
    do
        find $i -name '*emacs*' -exec rm -rf {} \; &
    done

on the machines I used to manage.

(Not the only reason.  It's also because I never had the
huevos to make _all_ my disks, NFS'ed or otherwise (plus my
network), suffer find(1)'s clumsy pawing, either
simultaneously or consecutively...)

>Be careful what files you edit and how you edit them, though -- if
>you're screwing around with the string tables in executables, my
>advice is DON'T, unless you can guarantee that EACH INDIVIDUAL STRING
>remains the same length.  Otherwise, your executables will either
>crash and burn, or your strings will be totally screwed.

You can keep them "the same length" by
padding them with nulls (^@ characters).

The problem is that if you remove any byte from
a binary file, all the bytes following it are
misaligned; binary data are inexorably positional,
so this causes programs that use the data to read it
as though it were garbage.

				--Blair
				  "How do you get out of this thing?"