> > 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. >
It's more complicated than that. Apple have announced that the default shell (Bash 3.2) will be removed in a future version of macOS, meaning ` /bin/sh` will point to zsh(1) instead of bash(1). There's already a deprecation warning in-place warning users against relying on the existence of /bin/bash or the assumption that /bin/sh == /bin/bash. I recommend testing against both Bash 3.2 and Zsh. As for sed(1), this might make cross-testing easier: https://opensource.apple.com/source/text_cmds/text_cmds-106/sed/ > Perl's mostly from its much higher rate of development compared to the > other two You might be thinking of Python. Perl—more so than most programming languages—takes backwards compatibility very seriously, as detailed in perlpolicy(1) (see *"Backwards compatibility and deprecation"*). Scripts can enable features for an explicit version of Perl via the `*use v5.N*` pragma. That's also the reason `use strict` and `use warnings` aren't enabled by default. 😉 Regards, — John On Wed, 27 Oct 2021 at 18:11, G. Branden Robinson < g.branden.robin...@gmail.com> wrote: > 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 >