autoconf-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Pass CONFIG_SHELL down if provided


From: Eric Blake
Subject: Re: [PATCH] Pass CONFIG_SHELL down if provided
Date: Tue, 11 Nov 2008 21:29:57 +0000 (UTC)
User-agent: Loom/3.14 (http://gmane.org/)

Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de> writes:

> * Paolo Bonzini wrote on Thu, Oct 30, 2008 at 02:59:49PM CET:
> > Subconfigures are invoked with $SHELL, not with $CONFIG_SHELL.  And
> > config.status is also created with
> > 
> > #! $SHELL
> > 
> > +else
> > +  SHELL=$CONFIG_SHELL
> >  fi
> 
> Not sure about this one.  It is not wrong to pass SHELL down, but
> typically, inside the generated scripts you still won't be able to rely
> on its value.  config.status for example is called from Makefiles as
> well, not just from configure.

config.status (and other generated scripts) are created with an unquoted here-
doc that expands the current value of $SHELL (whether they use the new 
AS_INIT_GENERATED, or whether you are talking about existing libtool 
releases).  You are correct that the generated script can't rely on $SHELL 
being the same as what its #! line contains; but the point of this patch is 
making sure the #! line contains the same shell as what the parent script 
settled on (in other words, since we take shortcuts in the prolog of the child 
based on information learned from the parent, then the #! line of the child had 
better specify the same shell that the parent ran under).  Prior to this patch, 
configure (but not m4sh) guaranteed that $SHELL was set to either $CONFIG_SHELL 
or /bin/sh, and CONFIG_SHELL was set if the parent script re-execed under a 
better shell or if requested by the user.  We are also quasi-guaranteed that 
when CONFIG_SHELL is not set, then the parent is running under /bin/sh (since 
m4sh starts the parent with #!/bin/sh, and since we tell the user that they 
must do 'CONFIG_SHELL=mysh mysh ./parent' rather than 'mysh ./parent' if they 
plan on running ./parent under any shell other than /bin/sh).

Hmm, you were right: we are still buggy.  M4sh should be the one guaranteeing 
that we do SHELL=${CONFIG_SHELL-/bin/sh}, and not autoconf/general.m4.  
Otherwise, AS_INIT_GENERATED is broken when using m4sh but not autoconf, and 
when CONFIG_SHELL is not set.

This brings up another interesting point - it means that child scripts must be 
executed as './script', and not '$SHELL ./script', because $SHELL might not 
necessarily match the #! line.  We probably ought to document that restriction 
as part of AS_INIT_GENERATED.  It also makes me wonder if it is possible to 
check whether the user is executing a script under a different shell than the 
#! line, in the case where they had not set CONFIG_SHELL.

-- 
Eric Blake






reply via email to

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