[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
- coreutils feature requests?, Lance E Sloan, 2017/07/18
- Re: coreutils feature requests?, Kaz Kylheku (Coreutils), 2017/07/18
- Re: coreutils feature requests?, Lance E Sloan, 2017/07/18
- RE: coreutils feature requests?,
Nellis, Kenneth <=
- Re: coreutils feature requests?, Steeve McCauley, 2017/07/19
- RE: coreutils feature requests?, Nellis, Kenneth, 2017/07/19
- Re: coreutils feature requests?, Eric Blake, 2017/07/19
- Re: coreutils feature requests?, Lance E Sloan, 2017/07/19
- Re: coreutils feature requests?, Eric Blake, 2017/07/19
- Re: coreutils feature requests?, Kaz Kylheku (Coreutils), 2017/07/19
- Re: coreutils feature requests?, Bernhard Voelker, 2017/07/19
- Re: coreutils feature requests?, Lance E Sloan, 2017/07/20
- Re: coreutils feature requests?, Kaz Kylheku (Coreutils), 2017/07/19
- ENVVars Removal and functional replacements (was Re: coreutils feature requests?), L A Walsh, 2017/07/19