[net.unix] source of 'cut' rewrite posted to net.sources

ignatz@ihuxx.UUCP (Dave Ihnat, Chicago, IL) (08/13/84)

It was recently pointed out to me that some versions of
Unix(Tm) don't have the cut(1) command.  So, I got busy on
my Osborne-1, using Aztec 'C', and recreated the command.

There is positively no proprietary code in the command; it may
be used by anyone without violation of any agreements.

The command and man page are posted as a shar archive on
net.sources.  Its behavior has only been tested on the Osborne,
and on a VAX 11/780 running System V.  (Berkley people, please
let me know what, if anything, has to be done to twig it to your
system)

Please mail any bug reports (fixes, too?) directly to me.

Finally, although the man page refers to 'paste(1)', I haven't
tackled that one yet.  I suspect that any system without 'cut' is
also without 'paste'---any other volunteers??

		Dave Ihnat
		ihuxx!ignatz

ignatz@ihuxx.UUCP (Dave Ihnat, Chicago, IL) (08/13/84)

Ahem...a minor oversight on my part, to those of you who may
wish to use my version of 'cut' on CP/M systems...I have a
twiddled version of ZCPR on my Aztec disk that *doesn't* convert
the arguments to upper case on the command input line.  Thus,
the program, as written, will not accept command line arguments
on a system that performs upper-case conversion.  The solution is
either to 'tolower()' the command-line characters in the switch
statement, or to add an upper-case check for each letter. (The
latter is the simplest method, since there aren't a lot of options).

Also, for those with Aztec, in the course of tweaking the file to
include the Unix(Tm) environment, I accidentally added a semicolon
on the end of the line defining the TAB character.  This resulted
in the delimiter declaration having two semicolons after macro
expansion; a legal 'C'-ism, giving a null statement, but Aztec 'C'
went bonkers when I did a recompile to check the changes.

-Dave Ihnat
 ihuxx!ignatz