Re: coreutils feature requests?

[Kaz Kylheku (Coreutils)]

On 19.07.2017 10:30, Eric Blake wrote:
> On 07/19/2017 12:03 PM, Lance E Sloan wrote:
> > Hi, Eric.
> >
> > Thank you for the thoughtful response.  I regret that I have trouble
> > understanding your point of view, though.  Please know that I do not 
> > mean
> > any disrespect.  I'd appreciate it if you could explain why you're 
> > opposed
> > to adding new features to cut (or to comm).
>
> I'm not opposed to well-justified new features.  It's just that the bar
> for justifying new features is rather high (it's a lot of code to add 
> to
> get field reordering, and that code has to be tested; it is also a
> question of how many users will rely on that extension.  A testsuite
> addition is mandatory as part of adding the new feature, if the new
> feature is worth adding).

It is nontrivial code. For instance if we look at how the function
cut_bytes works in the implementation, what it's doing is simply
doing a getchar() from the stream, and querying a data structure
to determine whether the byte should be printed or not.
(That data structure consists of a pointer which marches through
field range descriptors in parallel with going through the data.)

cut_fields is more complicated due to the delimiting of fields,
but essentially the same overall approach.

Basically, printing of fields that isn't sorted and de-duplicated
is a rewrite of all parts of the utility other than command
line processing and the printing of usage help text.

It's like two different programs in one, sharing a minimal
skeleton.