bug#9507: cut bug?

[Eric Blake]

tag 9507 notabug
merge 6394 9507
thanks

On 09/14/2011 10:20 AM, James Heather wrote:
> Hi,
>
> I'm sure this must have been spotted before, but
>
>      cut -f2,1
>
> produces the fields in the order 1,2 rather than 2,1. That seems wrong
> to me.

You're not the first to complain of this, and probably won't be the last.

> Changing it would probably break a thousand scripts.

Yep.  And it would also violate POSIX, so changing it now is a 
non-starter.  For reference, here's the POSIX text:

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cut.html

"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."

"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"."

> But could we have
> an additional option to respect the order of fields given on the command
> line?

Why?  It's already portable to use awk:

awk '{print $2,$1}'

https://lists.gnu.org/archive/html/bug-coreutils/2007-09/msg00169.html

at which point, you have the choice between a POSIX-mandated solution 
already on your system, even if you don't use coreutils; or waiting for 
a coreutils extension to be written and propagate to your distro, and 
which still won't work on other platforms like BSD.  You can tell which 
way we are leaning.

> It is a pain to rearrange fields with sed, though of course it can
> be done.

awk is better than sed for this task.

--
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org