why does "cut" print fields in original order?

Robert P. J. Day rpjday at crashcourse.ca
Wed Nov 21 15:57:50 UTC 2007

On Wed, 21 Nov 2007, Dave Ihnat wrote:

> Actually, I originally wrote cut & paste, but after the initial release,
> left it on its own.  Thankfully, David MacKenzie and Jim Meyering (neither
> of whom I've ever met or communicated with) picked up the ball and kept
> working on the programs.  (And whatever prompted me to spend the time to
> recreate these programs?  I was working on a Unix clone called 'Venix',
> and was annoyed that it didn't have these commands.)
> I wrote the programs to be as close to identical to the original Unix
> System 5 man page as I could, and "reverse-engineered" it from the man
> page description of behavior and options, deliberately not ever referring
> to or accessing the original source, since it was copyrighted material
> of AT&T.  At the time I was reverse engineering it, I asked numerous
> questions on Usenet as to whether I should fix obvious bugs or deviations
> in behavior, or extend the command; the overwhelming response was "make
> it behave like the 'real' command".
> Now, as to why it does what it does?  I don't know for sure, since
> I didn't go find whoever wrote the original and ask.  But I can
> guess--"do one thing, and do it well."  Cut is supposed to get fields
> from a line-delimited data stream.  Period.  Rearrangement is an added
> function--one that might be useful, certainly; but that can be done via
> other shell tools.

yes, i now appreciate that cut's behaviour is the very efficient
technique of treating the data as a one-way stream, so i'm good with
that.  so lay off already.  ya hear me??  LAY OFF!!!

double shot espresso:  accept no substitutes.

Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA


More information about the fedora-list mailing list