Surprisingly relevant?

Posted May 20, 2020 23:27 UTC (Wed) by wahern (subscriber, #37304)
In reply to: Surprisingly relevant? by dumain
Parent article: The state of the AWK

That cut only accepts a single character delimiter (rather than a set like IFS in shell, or a regular expression like FS in AWK[1]), and that it can't span adjacent delimiters (like shell and AWK), is a nearly fatal flaw. I have half a mind to submit a proposal to POSIX to add a new option, but there's no such extension in any implementation of cut that I've seen. Pre-existing practice isn't a hard requirement, especially for the upcoming revision, but I feel like the fact it doesn't exist constitutes proof that cut is a lost cause and should be left alone.

[1] There are special semantics for single-character FS; semantics that mimic shell word splitting.

to post comments

Surprisingly relevant?

Posted May 21, 2020 17:11 UTC (Thu) by NYKevin (subscriber, #129325) [Link] (1 responses)

> That cut only accepts a single character delimiter (rather than a set like IFS in shell, or a regular expression like FS in AWK[1]), and that it can't span adjacent delimiters (like shell and AWK), is a nearly fatal flaw.

No it isn't. You're meant to call tr(1) with appropriate arguments, and pipe the result into cut. If you do that, then neither of those limitations matter.

Surprisingly relevant?

Posted May 22, 2020 8:58 UTC (Fri) by ptman (subscriber, #57271) [Link]

I'll just reach for this handy POSIX AWK instead