Re: numfmt: minor improvements to --field parsing

[Pádraig Brady]

On 16/07/15 00:58, Assaf Gordon wrote:
> Hello Pádraig,
> 
> On 07/12/2015 02:33 PM, Pádraig Brady wrote:
> <...>
>   
>> Hmm. Shouldn't we treat the above like field 1 and all fields up to 2 
>> inclusive?
>> Similarly shouldn't we allow ranges like:
>>
>> $ echo 1 2 3 4 5 | numfmt --field -2,4- --to-unit=1000 --round=down
>> 0 0 3 0 0
>>
>> $ echo 1 2 3 4 5 | numfmt --field -2,-4 --to-unit=1000 --round=down
>> 0 0 0 0 5
> 
> Attached is a reworked patch. In it, I've copied the 'set_fields' function 
> from cut almost verbatim.
> now numfmt accepts the same variations as 'cut --fields=LIST' (including the 
> examples you mentioned above),
> with the addition that '--field=-' means 'all fields'.
> 
> To illustrate, attached are excerpts of 'set_fields' from cut.c and numfmt.c, 
> a diff between them will show the minor changes.
> 
> comments welcomed,

Well I wasn't suggesting to do all that in this iteration,
but this was definitely on the TODO list, so thanks!
With that we can remove the xlist and linked-list modules from bootstrap.conf.

Given the overlap it would be best to move the shared code
(and any associated global vars) to a set-fields.c module,
similar to what was done with operand2sig.[ch] for example.
FATAL_ERROR() or error() could be used, but I'd have a very
slight preference for error(). For divergences you could
key on an extern int field_mode, initialized globally
in both cut.c and numfmt.c

cheers,
Pádraig.