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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]