On Mon, Aug 5, 2024, at 2:45 PM, Bob Friesenhahn wrote:
> On 8/5/24 12:02, Paul Eggert wrote:
>> On 2024-08-04 15:33, Bob Friesenhahn wrote:
>>> Hopefully a future stable Autoconf will detect the broken shell and
>>> set CONFIG_SHELL=/usr/bin/bash in order to succeed.
>>
>> That will happen if someone gives us a reliable way to detect the
>> broken shell, most likely by inspecting ${.sh.version} or equivalent.
>> Could you do that? If you don't do it, I expect it'd be quite some
>> time before someone else did, as there aren't that many OmniOS users.
>
> I can tell you that I get this:
>
> $ printf "${.sh.version}\n"
> Version JM 93t+ 2010-03-05
>
> I expect that this shell originates from the OpenSolaris ksh93
> sub-project, is made available via the common Illumos project, and is
> thus shared by OmniOS, OpenIndiana, and other variants/forks which are
> based on Illumos. It is true that the user-base is vastly smaller than
> Linux, although the core OS functionality is still competitive with
> modern Linux (and in fact inspired it, given a lineage from AT&T's
> UNIX). I am totally unaware if there has been success with
> updating/fixing it's ksh93 in more recent versions.
Just to check, this is the same ksh bug as was discussed here, right?
https://savannah.gnu.org/support/?func=detailitem&item_id=110403
If so, it _should_ have been fixed in the Illumos "gate" some time
ago according to https://www.illumos.org/issues/13434 and
https://www.illumos.org/issues/13405 -- so presumably we are just
waiting for that change to make it into OmniOS?
If you can get your hands on the updated ksh, verify that it does
address the bug you are seeing, and report what its value of
${.sh.version} is, then we can make _AS_DETECT_BETTER_SHELL reject
the old ksh.
As discussed in the Autoconf bug report linked above, I don't want
to try to probe directly for the bug because a reliable test will
probably also be unacceptably slow (needing to generate hundreds,
possibly thousands, of test scripts and run them all).
zw
