Re: Accounting for SHELL in ./configure

Behdad Esfahbod <[email protected]> Wed, 1 May 2024 15:15:09 -0600
Newsgroups gmane.comp.fonts.freetype.devel
Message-ID <CAF63+7Xd4Z4OQU8zErOvBisbSFj5zqdzM+Z0ijOCeW83D7t3uQ@mail.gmail.com>
Can you check if also setting CONFIG_SHELL helps?

behdad
http://behdad.org/


On Wed, May 1, 2024 at 3:06 PM Mohammad Akhlaghi <[email protected]>
wrote:

> The Autoconf-generated configure script, or even CMake, respect SHELL, so
> if a user gives it a problematic shell, they won't be able to build
> anything abd many programs will crash.
>
> But please consider the scenario mentioned before: when a user doesn't
> have root permissions to change '/bin/sh', they are left with non-standard
> hacks like what I did.
>
> When each program's build system respects 'SHELL', the user is free to use
> any shell they want with any program's build.
>
> Cheers,
> Mohammad
>
>
>
>
> On May 1, 2024 10:55:05 PM GMT+02:00, Behdad Esfahbod <[email protected]>
> wrote:
>
>> I'm not talking about the user overriding the shell specifically. I'm
>> talking about users who genuinely use a non-POSIX shell as their terminal
>> shell. Then just running ./configure would fail if configure was to respect
>> $SHELL.
>>
>> Or rather you're saying that only POSIX-compatible shells should set
>> $SHELL.
>> behdad
>> http://behdad.org/
>>
>>
>> On Wed, May 1, 2024 at 2:45 PM Mohammad Akhlaghi <[email protected]>
>> wrote:
>>
>>> Thanks Behdad,
>>>
>>> The problem is that I do not have root permissions on the system with
>>> the faulty '/bin/sh': I cannot change '/bin/sh' and need to build my
>>> programs with a custom shell.
>>>
>>> If the user specifies a wrong shell (not the default '/bin/sh'), it is
>>> their own responsibility that it is POSIX-compatible. The same way that a
>>> user can give a non-GNU Make executable to the GNUMAKE variable.
>>>
>>> In short, when a user changes defaults, it is their resposibility, not
>>> the developer's. So no need to worry about that; the important thing is to
>>> give users the freedon to customize for their custom environments (as GNU
>>> Autoconf does for example; but Autoconf is not used in FreeType).
>>>
>>> Cheers,
>>> Mohammad
>>>
>>>
>>>
>>> On May 1, 2024 10:25:54 PM GMT+02:00, Behdad Esfahbod <[email protected]>
>>> wrote:
>>>
>>>> There's no guarantee that the user's shell is sh-compatible. autoconf
>>>> really means sh here, because that's the shell the script is written for.
>>>> Just symlink your favorite shell to sh then, if it's compatible.
>>>>
>>>> behdad
>>>> http://behdad.org/
>>>>
>>>>
>>>> On Wed, May 1, 2024 at 2:13 PM Mohammad Akhlaghi <[email protected]>
>>>> wrote:
>>>>
>>>>> Hi again,
>>>>>
>>>>> I was able to find a cleaner hack by running this command before the
>>>>> './configure' script:
>>>>>
>>>>> export GNUMAKE="make SHELL=$SHELL"
>>>>>
>>>>> Afterwards, FreeType successfully ran with my desired shell.
>>>>>
>>>>> But generally, it would greatly help those building FreeType from
>>>>> source
>>>>> if the configure script accounts for the 'SHELL' environment variable.
>>>>>
>>>>> Thanks a lot for all the nice work on FreeType,
>>>>> Cheers,
>>>>> Mohammad
>>>>>
>>>>> On 5/1/24 9:00 PM, Mohammad Akhlaghi wrote:
>>>>> > Dear Freetype developers,
>>>>> >
>>>>> > I was trying to build FreeType from source and noticed that the
>>>>> > './configure' script does not account for the 'SHELL' environment
>>>>> and
>>>>> > will always use '/bin/sh'.
>>>>> >
>>>>> > Looking at the source of the './configure' script, I was able to fix
>>>>> the
>>>>> > problem by manually adding a 'SHELL=$SHELL' in line 135 of the
>>>>> > './configure' script:
>>>>> >
>>>>> >
>>>>> https://gitlab.freedesktop.org/freetype/freetype/-/blob/master/configure?ref_type=heads#L135
>>>>> >
>>>>> > Accounting for the user's given SHELL is common in many programs
>>>>> when
>>>>> > building from source, so it would be good if you could account for
>>>>> it in
>>>>> > future versions of FreeType also.
>>>>> >
>>>>> > Cheers,
>>>>> > Mohammad
>>>>>
>>>>>