Re: coreutils feature requests?

[Eric Blake]

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

Furthermore, on the topic of cut, we've already had the discussion
multiple times over multiple years:

https://www.gnu.org/software/coreutils/rejected_requests.html
which links to
http://lists.gnu.org/archive/html/bug-coreutils/2012-12/msg00115.html
which links to
http://lists.gnu.org/archive/html/bug-coreutils/2005-06/msg00125.html

Reading some of those threads show that there's not outright opposition,
so much as "why isn't awk good enough, since it already is standardized
and does what you want" - mixed with quotes like "In spite of all of
that, the existing behavior (of not honoring the user-specified
field/column-number ordering) is non-intuitive enough that I'd consider
a patch adding an option to make cut provide the more sensible
behavior."  And remember that patches DO speak louder than words.
Repeating a mantra of "this new feature would be great, can someone else
implement it for me" is a lot easier to ignore than "this new feature
helped me, and here's the patch for your consideration".  So I'm not
outright rejecting the idea, so much as stating that you are not the
first to propose it, and none of the previous proposals got it incorporated.

I haven't made any decisions about the benefit of a change to comm, and
will leave that to other maintainers to chime in.

> Even if this feature suggestion isn't approved by the GNU community, I will
> implement it for my own use anyway.

Absolutely!  That's the beauty of free software, that you ARE permitted
to improve it and share your changes, whether or not other people pick
up on your changes.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

signature.asc
Description: OpenPGP digital signature