GNU bug report logs -
#9507
cut bug?
Previous Next
Full log
Message #10 received at 9507-done <at> debbugs.gnu.org (full text, mbox):
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 eblake <at> redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
This bug report was last modified 12 years and 183 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.