Scratch that. Where is it exactly failing? On Unix, the build system is essentially autoconf, so it should respect SHELL as you suggest.
behdad http://behdad.org/ On Wed, May 1, 2024 at 3:15 PM Behdad Esfahbod <beh...@behdad.org> wrote: > Can you check if also setting CONFIG_SHELL helps? > > behdad > http://behdad.org/ > > > On Wed, May 1, 2024 at 3:06 PM Mohammad Akhlaghi <moham...@akhlaghi.org> > 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 <beh...@behdad.org> >> 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 <moham...@akhlaghi.org> >>> 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 < >>>> beh...@behdad.org> 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 < >>>>> moham...@akhlaghi.org> 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 >>>>>> >>>>>>
