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