[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Substitution of SHELL and CONFIG_SHELL
From: |
Niels Möller |
Subject: |
Re: Substitution of SHELL and CONFIG_SHELL |
Date: |
16 Feb 2004 09:31:37 +0100 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 |
Alexandre Duret-Lutz <address@hidden> writes:
> >> I noticed this because only because one user couldn't got bash errors
> >> when running make, and it turned out he had a set -u in his .bashrc.
> >> To me, doing that unconditionally in .bashrc seems like a very broken
> >> thing to do,
>
> Sorry if I'm missing something obvious, but why was `.bashrc'
> read at all? I though it was only read by interactive shells.
I'm honestly not 100% sure exactly how he had managed to break his bash
installation. The error message was
make[2]: Leaving directory `/home/grubba/src/nettle-1.9/build/sun4u/examples'
/bin/bash: fail: unbound variable
which looks very much like a set -u somewhere.
> Paul> Also, perhaps this is more of an Automake issue rather than an
> Paul> Autoconf issue? That is, either the GNU coding standards should be
> Paul> changed, or Automake should be changed to output "SHELL = /bin/sh"
> Paul> rather than "SHELL = @SHELL@" into Makefile.in. (Or perhaps it should
> Paul> be changed to "SHELL = @MAKE_SHELL@" so that we could distinguish the
> Paul> two uses of shells.)
>
> Hmmm, what are these two uses? It seems preferable to me not to
> multiply the number of shells in use. What is good for
> configure ought to be good for make.
Both the configure script and make rules are written to be executed by
/bin/sh. As far as I understand, the reason configure sometimes use
/bin/bash instead, is that it provides for better logging and/or error
messages (via $LINENO), and perhaps it's faster as well. Those two
reasons don't really apply to make rules, so there it seems better to
just stick to /bin/sh.
Regards,
/Niels