Re: Accounting for SHELL in ./configure

[Mohammad Akhlaghi]

I had set the 'SHELL' environment variable but still '/bin/sh' was used. 
The only way I could pass my SHELL to the Make command within the 
configure script was through the non-standard hack I mentioned before: 
GNUMAKE="make SHELL=$SHELL"

Autoconf generates the './configure' script automatically though a 
'configure.ac' file. But I don't see any 'configure.ac' in FreeType's 
source. For example here is the source code of a project that I maintain 
which uses Autoconf:

https://git.savannah.gnu.org/cgit/gnuastro.git/tree

The './configure' script is generated automatically from 'configure.ac' 
when building the tarball (since the configure script is automatically 
generated, we don't keep it under version control).

Cheers,
Mohammad

On 5/1/24 11:17 PM, Behdad Esfahbod wrote:
> 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 <behdad@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 <mohammad@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 <behdad@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 <mohammad@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 <
> > > > > behdad@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 <
> > > > > > mohammad@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