On 2023-08-01 16:42, Pádraig Brady wrote:
On 01/08/2023 10:07, Dragan Simic wrote:
Add new command-line option and the required logic that allow multiple
consecutive delimiters to be treated as a single delimiter. Of
course,
this option is valid only with the cut's field mode.
This new feature should make cut much more usable in various
real-world
applications, some of which are already mentioned in the gotchas. For
example, merging the consecutive delimiters is very useful when cut is
used to process the outputs of various commands.
Add a whole battery of new cut tests, which cover this new feature,
and
add more tests for the related already existing features, to make sure
no regressions are introduced.
While there, clean up the comments and the whitespace in the cut tests
a bit, to make them slightly more readable.
Thanks for the patch.
I wonder whether a --empty-fields={ignore,suppress} is a more general
interface.
I wonder would it be a more complex approach, and more importantly, less
intuitive? Quite frankly, I think it's easier to visualize the empty
space. or the delimiters as a more general approach, becoming
"squeezed". I think that visualizing the empty fields is harder,
especially when the delimiter is a whitespace character.
This overlaps somewhat with the -w option in FreeBSD's cut,
which merges runs of whitespace, and which I was also considering
adding.
After thinking a bit about it, how about having both "-m", from the
patch I submitted, and "-w", which would behave differently than the
FreeBSD's "-w"? Please, allow me to explain.
More specifically, our "-w" would simply "squeeze" all the whitespace in
the input without forcing the delimiter to be whitespace. The
"squeezing" would produce a whitespace character in the input, instead
of whatever got "squeezed" there. That would be either the whitespace
character specified as an optional value for the "-w" option, or it may
by default produce a space wherever only spaces were "squeezed", or a
tab wherever the "squeezed" whitespace contained at least one tab.
With both "-m" and "-w" options in place we'd end up with a quite
versatile cut, which would cover what FreeBSD's cut does, and be able to
do more. I'd be willing to implement the "-w" option as well.
