why does "cut" print fields in original order?

[Tim Waugh]

For what it's worth, cut(1) is just following the spec.

"The elements in list can be repeated, can overlap, and can be specified
in any order, but the bytes, characters, or fields selected shall be
written in the order of the input data."

and later, in "Rationale":

"""
The list option-arguments are historically used to select the portions
of the line to be written, but do not affect the order of the data. For
example:

echo abcdefghi | cut -c6,2,4-7,1


yields "abdefg".

A proposal to enhance cut with the following option:


-o
        Preserve the selected field order. When this option is
        specified, each byte, character, or field (or ranges of such)
        shall be written in the order specified by the list
        option-argument, even if this requires multiple outputs of the
        same bytes, characters, or fields.

was rejected because this type of enhancement is outside the scope of
the IEEE P1003.2b draft standard.
"""

So the answer to the original poster's question is: because the spec
requires the order to be ignored.

Tim.
*/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-list/attachments/20071121/95e19953/attachment-0001.sig>