coreutils
[Top][All Lists]
Advanced

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

RE: coreutils feature requests?


From: Nellis, Kenneth
Subject: RE: coreutils feature requests?
Date: Wed, 19 Jul 2017 12:54:47 +0000

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

reply via email to

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