Re: coreutils feature requests?

[Lance E Sloan]

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.
>