> Thanks. I'll add a call to gettext() that will happen right after bash sets
> its default values for the various locale categories.
When building the latest commit on `devel`
(`b3d8c8a4e7c5417d986f93f646ea740cb13c08d7`) this issue no longer occurs.
Thanks!
On 5/6/24 11:17 AM, Tom wrote:
It looks like it's the call to setlocale() that creates the auxiliary
threads, and the call to gettext() that forces the artificial crash.
Yep, that's my understanding.
Thanks. I'll add a call to gettext() that will happen right after bash sets
its default value
> It looks like it's the call to setlocale() that creates the auxiliary
> threads, and the call to gettext() that forces the artificial crash.
Yep, that's my understanding.
> So any call to gettext() in the parent process before any fork would be
> sufficient to complete the initialization?
It d
On 5/3/24 10:31 PM, Tom wrote:
That report has a work-around invoking a syntax error which presumably calls
out to `setlocale`/`gettext` pre-`fork`, caching the result somewhere (`bash`
or `gettext`?) such that the offending call post-`fork` on an unknown command
doesn't trigger this issue.
> Oh, I see, from gettext-0.22.
Yes, that's right, this came up in the context of a [macports bug report][1].
> Still, how should bash avoid this using only public function interfaces?
That report has a work-around invoking a syntax error which presumably calls
out to `setlocale`/`gettext` pre-
On 5/2/24 10:54 AM, Chet Ramey wrote:
On 5/2/24 2:23 AM, Tom wrote:
Bash Version: 5.2
Patch Level: 26
Release Status: release
Description:
When linked against `libintl.8.dylib`, if an unknown comand is executed, the
following error is seen:
Where do you get libintl.8.dylib? I don't see it o
On 5/2/24 2:23 AM, Tom wrote:
Bash Version: 5.2
Patch Level: 26
Release Status: release
Description:
When linked against `libintl.8.dylib`, if an unknown comand is executed, the
following error is seen:
Where do you get libintl.8.dylib? I don't see it on my macOS systems.
And doesn't this l
