coreutils
[Top][All Lists]
Advanced

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

Re: coreutils feature requests?


From: Kaz Kylheku (Coreutils)
Subject: Re: coreutils feature requests?
Date: Wed, 19 Jul 2017 10:43:48 -0700
User-agent: Roundcube Webmail/0.9.2

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.




reply via email to

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