[Top][All Lists]

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

Re: [PATCH] Pass CONFIG_SHELL down if provided

From: Ralf Wildenhues
Subject: Re: [PATCH] Pass CONFIG_SHELL down if provided
Date: Tue, 11 Nov 2008 22:42:26 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

* Eric Blake wrote on Tue, Nov 11, 2008 at 10:29:57PM CET:
> Prior to this patch, 
> configure (but not m4sh) guaranteed that $SHELL was set to either 
> 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).

BTW, this has bugged me for quite a while.  Can we get things to work
without requiring
  CONFIG_SHELL=mysh mysh ./parent
but only
  CONFIG_SHELL=mysh ./parent
or even
  ./configure CONFIG_SHELL=mysh
without too much overhead?

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

Didn't think of that, but good to see that my grumbling helps.  :-)

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

Yes.  This is not in any way a new restriction, though.
My suggestion above would eliminate this problem.
(OTOH you can be sure to have irritated users that *want*
$SHELL to execute the script; oh well.)

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

AFAIK it is not easy to portably find out which shell we're under.


reply via email to

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