Re: Sed failure in contrib/sboxes on MacOS

[John Gardner]

>
>  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.robinson@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
>