Surprisingly relevant?

Posted May 20, 2020 6:43 UTC (Wed) by dumain (subscriber, #82016)
In reply to: Surprisingly relevant? by NYKevin
Parent article: The state of the AWK

'{print $1}' may be less readable than cut -f1 but it also deals better with less structured data: separation with variable white space, leading whitespace etc. Plus you can set FS to be a regxp if needed.

Surprisingly relevant?

Posted May 20, 2020 23:27 UTC (Wed) by wahern (subscriber, #37304) [Link] (2 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. 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.

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