Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!uunet!gistdev!flint
From: flint@gistdev.gist.com (Flint Pellett)
Newsgroups: comp.binaries.ibm.pc.d
Subject: Re: **** WANTED **** BINARY FILE COPY PROGRAM
Message-ID: <1007@gistdev.gist.com>
Date: 22 Sep 90 18:23:47 GMT
References: <90263.114424POTELLE@MAINE.BITNET>
Organization: Global Information Systems Technology Inc., Savoy, IL
Lines: 69

POTELLE@MAINE.BITNET (John A. Potelle) writes:

>This program should be able to copy PARTS of files, given a starting
>relative address within the source file and a length.
> 
>Example of a possible command line syntax:
> 
>chopcopy [-s100 [-l360]] <source-file> <target-file>
> 
>HEX or DECimal addressess/lengths - I don't care which...
> 
>Anyone know of such a beast or care to write one ?
> 

I may decide to write this in a couple days, as I've wanted to be able to
grab small parts like version strings (that are in fixed byte locations)
out of binary data files before.

<Mount Soapbox:>

I wish people would give more thought to the command line syntax though:
your example is a bad design for command line syntax, because it makes the
program unuseable in a pipe for no good reason.  Why force the user to read
from one file into another file when you don't have to do so?)  Here is a
similar but much more useable syntax:

chop -s<start_byte> -e<end_byte> -b<buffer_size> inputfile

where everything defaults: -s defaults to 0 (start of file), -e to
end-of-file, -b (the buffer size used during copies) to some value like
8192 (I don't know what the best default would be here, but I would guess
a fairly large multiple of both 512 and 1024 would be best.)

If you don't specify the input file, it defaults to stdin for use in a pipe.
It always writes to stdout, so if you want the output in a file, just use
chop -s# -e# infile > outfile

Doing it that way gives you a lot more power: you can send the output
anywhere you want.

A lot of utilities seem to want to force you to read and write to files.
Even worse, some of them don't let you specify the files on the command
line, they mess with the screen display to put up a whole menu just for
the purpose of letting you enter the file names: this makes those utilities
a LOT less useful, sometimes even making them useless.  (For example, an
editor which has an option to pipe part of the file being edited out to
some command, and then replace that part of the file with the output of
the command, can not get any use at all out of a spelling checker utility 
that insists on erasing the whole display of the file you are editing,
switching you out of 132 column mode into some other mode, and then prompting
you for the names of the files.  If the utility would read stdin and write
stdout when no other options are given, it would be useable from within
the editor and could then be invoked with a single key.)

The proper sequence in a good utility ought to be this:

1. If an input file name is given on the command line, use it.  Always
   write to stdout if you can.
2. If the user entered some option like "-p", (saying "I don't remember
   the options I need, please prompt me for all of them"), then prompt
   them for all the info you need, including names of input & output files.
3. Otherwise, read your input from stdin and write your output to stdout,
   and adopt reasonable defaults for every option not explicitly specified.

<Dismount Soapbox>
-- 
Flint Pellett, Global Information Systems Technology, Inc.
1800 Woodfield Drive, Savoy, IL  61874     (217) 352-1165
uunet!gistdev!flint or flint@gistdev.gist.com