[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#9507: cut bug?

From: Eric Blake
Subject: bug#9507: cut bug?
Date: Wed, 14 Sep 2011 10:52:45 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110831 Fedora/3.1.12-2.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.12

tag 9507 notabug
merge 6394 9507

On 09/14/2011 10:20 AM, James Heather wrote:

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:


"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

Why?  It's already portable to use awk:

awk '{print $2,$1}'


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]