coreutils
[Top][All Lists]
Advanced

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

Re: coreutils feature requests?


From: Steeve McCauley
Subject: Re: coreutils feature requests?
Date: Wed, 19 Jul 2017 09:18:01 -0400

I can't believe I'd never thought of reordering output columns like this.
FWIW, I agree that another option should be used to prevent issues with
backward compatibility.

$ echo 1,2,3,4,5,6 | cut -d, -f3,5,2
2,3,5

$ echo 1,2,3,4,5,6 | cut -d, -f3,5,2 -o
3,5,2

Should this be extended to character output as well?

echo output | cut -c6,4,2 -o
tpu


On Wed, Jul 19, 2017 at 8:54 AM, Nellis, Kenneth <
address@hidden> wrote:

> From: coreutils > Hi, Kaz.
> >
> > Thanks for the response.  I'm happy that you've come to the same
> > conclusion
> > that I'd reached. I only have a moment for a quick reply now, but my
> > inclination was to add a -o / --ordered option to make -f (and other
> > options) work the way I'd expected.
> >
> > I'd be happy to implement the feature myself and contribute it back to
> the
> > community. I'd just like to know what are the procedures. Should I wait
> > for
> > the feature request to be approved by someone?  I didn't want to spend
> > time
> > implementing it only to see out rejected soon afterwards.
> >
> > I've seen the hacking readme and I understand what to do technically.
> > However, I couldn't find any documentation about what happens
> > procedurally.  If you or others can share some insight, I'd appreciate
> it.
> >
> > Thanks in advance.
> >
> > On Tue, Jul 18, 2017 at 21:06 Kaz Kylheku (Coreutils) <
> > address@hidden> wrote:
> >
> > > On 18.07.2017 15:44, Lance E Sloan wrote:
> > > > Hi, all.
> > > >
> > > > Aside from a bug report, is there a way to submit a feature request
> > for
> > > > coreutils?  I have a couple of requests in mind, which I don't think
> > > > qualify as bugs:
> > > >
> > > > 1. Add a feature to "cut" that allows selected fields to be output in
> > a
> > > > different order.  That is "cut -f4,1,8-6" would cause it to output
> > > > fields
> > > > in the order of 4, 1, 8, 7, and 6.
> > >
> > > I'm amazed that it doesn't work this way; the utility of implicitly
> > > sorting the fields appears low compared to the damage that it does
> > > to the flexibility of cut. (What little it has!)
> > >
> > > If POSIX specifies it, I have to say that its requirements are
> > > suboptimal (as is often the case in diverse areas).
> > >
> > > Indeed, the requirement is sadly given as:
> > >
> > >     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. If an element appears in
> the
> > >     selection list more than once, it shall be written exactly once.
> > >
> > > Do people often write cut specifications in ad hoc orders, with
> > > repetitions and then rely on the sorting behavior?
> > >
> > > The GNU implementation of cut could lead standardization in this
> > > area to improve things.
> > >
> > > All the possible solutions to make cut not sort the fields or
> > > de-duplicate them are ugly. Either you  need a global option to
> > > opt out of that behavior, like "-o" (preserve (o)rder) and
> > > keep remembering to use it, or else provide order-preserving
> > > versions of the various options, like perhaps through capitalization:
> > > -F, -C, -B.
> > >
> > > An attractive alternative is to have a whole new command which
> > > mirrors cut, like say "clip", which is exactly like cut, but
> > > order and repetition preserving.
> > >
> > > Note that the --complement option is semantically incompatible with
> > > order-preserving mode; the complement concept follows from the
> > > selected elements being regarded as a set rather than ordered
> > > sequence. If -F, -C or -B is used with --complement, it has to be
> > > diagnosed.  Or if there is a "clip" command, then that simply
> > > doesn't support --complement.
>
> Indeed, I've wanted this feature for a while. We use QNX4 in our
> legacy embedded product, and its cut indeed outputs fields in the
> order specified. I was quite surprised when the script I wrote for
> QNX4 didn't work with Gnu.
>
> qnx4> echo 1,2,3,4,5,6 | cut -d, -f3,5,2
> 3,5,2
> qnx4> use cut
> cut - cut out selected fields of each line of a file (POSIX)
>
> cut -c list [file ...]
> cut -f list [-d delim] [-s] [file ...]
> Options:
>  -c      Cut out the <list> of fields based on character position.
>  -f      Cut out the <list> of fields based on field position.
>  -d      Specify the field delimiter character.
>  -s      Suppress the output of lines which contain no field delimiter.
> Where:
>  list    Is a list of character or field positions separated by a <space>
>          or a <comma>. A range of positions may be specified using the
>          <hyphen>.
> Examples:
>  cut -c 20-29,40-49 myfile    Output character columns 20 to 29 and 40 to
> 49
>                               of the file 'myfile'
>  cut -f 3,5,7-11 -d| myfile   Output fields numbered 3, 5, and 7 to 11 of
> the
>                               file 'myfile'.  The fields in each input line
>                               are separated by the '|' character.
> qnx4>
>
> I support the change.
>
> --Ken Nellis
>



-- 
:wq


reply via email to

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