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.
