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 >>>>> >>>>>