On 9/25/23 11:06, Zack Weinberg wrote:

For clarity, I was talking about the overhead of
_AS_DETECT_BETTER_SHELL, not the overhead of functions themselves.

Great!
It is unclear to me whether bourne-ish shells that were new in March
13 1992 that still didn't support shell functions, or whether there
were simply older shells still floating around in widespread use.
I don't know either.  What I do know is that in 1995 there were several
proprietary Unix vendors that intentionally froze their /bin the way it
was *before* the changes mandated by "Unix95", and I fully expect there
are still computers today running *those versions* of those OSes, in
conjunction with expensive equipment, like mass spectrometers and
industrial robots, which still works Just Fine but the vendor longer
exists.  Some subset of those computers also need to need to communicate
with more modern systems, which involves doing things like compiling
current versions of libssl, and here we are.

Autotools should transition from "we support everything since 1984"
Please understand that the last time I tried to make such a change -
to autoconf proper, not to config.* - I got flamed to a crisp by
the maintainer of C-Kermit.
I would be happy to revert the change at the first since of trouble, to raise the white flag before the flamethrower goes off.
On Mon, Sep 25, 2023, at 10:57 AM, John Cotton Ericson wrote:
Sure. If they show up, we can definitely revert it. But what happens
if they *don't* show up? What do you think in that case?
How long are you prepared to stick to your position? How many angry e-
mails are you prepared to field?

Perhaps you are worried about a principle--agent problem where the angree emails don't go to this list, and persist even after the change is reverted? I.e. I tiptoe and do then undo a thing, while you bear the burden of getting the angry emails?

John

Reply via email to