Re: Sed failure in contrib/sboxes on MacOS

[G. Branden Robinson]

Hi, James!

I think the sed portability issues in the build are resolved for now,
and pushed.

At 2021-10-26T10:19:23-0400, James K. Lowden wrote:
> I might have a useful platform to try. I am running autoconf 2.69 on a
> NetBSD machine that I hardly ever change. Its sed and make are derived
> from the same sources as the one you're using. I would be surprised if
> the difference you're seeing is the product of shell quoting, since
> the Mac uses bash.

Yes.  Mac OS X, at least the version I have access to, uses Bash 3.2 as
its script interpreter, and zsh 5.8 as its interactive shell.

> BTW, is this episode yet another nail in the sed coffin? Is it another
> reason not to rely on sed for whatever it is that it's doing?  I have
> no dog in the fight, just asking.

I don't think so.  My impression is that perhaps 90% or more of all sed
usage is solely for its substitution operator, 1..n times.  But it's a
Turing-complete language, so you can get up to all sorts of wonderful
mischief in it.[1]

The other languages one might turn to for reasonably sophisticated text
processing tasks--AWK, Perl, and the Unix shell--all have their
portability challenges as well (Perl's mostly from its much higher rate
of development compared to the other two).  There are multiple competing
implementations of all of these except Perl (which competes mostly with
its own release history).

I don't think there's a silver bullet.  We just have to try to write
portably, and be prepared for bugs, unfortunate interactions between
programs, and the inevitable impedance mismatches that arise from elbow
room in standards documents, and strong personal feelings (about
features, software licensing, or rival organizations) on the part of
the humans behind the development process.

Regards,
Branden

[1] http://sed.sourceforge.net/grabbag/scripts/dc.sed

signature.asc
Description: PGP signature