mainAutoconf - Support: sr #110612, Re-exec of $as_myself chooses...

 
 

sr #110612: Re-exec of $as_myself chooses wrong configure script from PATH

Submitter:  Michael Orlitzky <mjo>
Submitted:  Sat 19 Feb 2022 01:07:39 AM UTC
   
 
Priority:  * 3 - Release N+1 Severity:  2 - Minor
Status:  Need Info Privacy:  Public
Assigned to:  None Open/Closed:  Open
Operating System:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Fri 08 Dec 2023 07:00:50 PM UTC, comment #4: 

This is all helpful but I'm leaving this marked "need info" until someone has the time to do a broader investigation of what we get in $0 and $_ for invocations of a trivial script with many different shells.  Note that there may be up to three different shells involved: the shell you're typing commands at, the shell invoked by 'sh', and the shell named on the #! line.

Zack Weinberg <zackw>
Group administrator
Fri 08 Dec 2023 02:46:39 AM UTC, comment #3: 

comment #1:

> If you or anyone else has ideas for how to tell "configure" from "sh configure", I am all ears.


If it's Bash, "$_" (at the start of the script) should tell you.  This is true for other shells (e.g., it works with Solaris 10 /bin/sh) but I don't know whether it's universal. Not sure whether it's worth the trouble.

Paul Eggert <eggert>
Group administrator
Fri 08 Dec 2023 02:44:17 AM UTC, comment #2: 

No problem. If I create,

$ cat configure
#!/bin/sh
echo $0

in my home directory, then at least in bash and dash, the $PATH entry gets prepended to $0 when it is needed to resolve "configure":

$ PATH=/home/mjo configure
/home/mjo/configure
$ PATH=. configure
./configure

Having tested on one platform and two shells, I conclude that there's no way to get "configure" without a directory separator, unless "sh configure" was used :)

Alas, someone wrote that $as_myself code for a reason, so we're probably not so lucky. I see the problem and if it's not fixable, that's OK. IIRC we only wound up in this situation because someone created a tarball with a non-executable configure script, and then the person writing the workaround was unlucky and left out the "./". And then I was even more unlucky and had both a shell without LINENO, and some other "configure" in my $PATH. It's not worth spending a lot of time on.

Michael Orlitzky <mjo>
Fri 08 Dec 2023 02:01:33 AM UTC, comment #1: 

We regret the delay in responding to this bug report.

In principle, this is something we should try to fix, but I do not see a good way to do it.  The problem is that there's no way (that I know of) to tell, when $0 is just "configure", whether the script was invoked with "sh configure" (in which case we should look only in the current working directory when re-execing with a better shell) or with "configure" (in which case we should not look in the current directory unless it appears in $PATH).  Unless we can tell, any change would just be moving the problem around.

(In case you didn't know, it is normal and fully supported to invoke a configure script that's not in the current working directory; the effect is to set things up to store the build output separately from the source tree.  It's called a "split tree build".  In fact, some projects require you to build this way.  That's why we can't just always look in the current directory.)

If you or anyone else has ideas for how to tell "configure" from "sh configure", I am all ears.  I would also happily take a patch to the documentation (probably install.texi is the place to put it) that tells people to use "sh path/to/configure" (whether or not "path/to" is ".") rather than "sh configure".

Zack Weinberg <zackw>
Group administrator
Sat 19 Feb 2022 01:07:39 AM UTC, original submission:  

(This is copy/pasted in its entirety from an old bug- mailing list post of mine)

In the configure scripts that I'm generating, I see the following
variable assignment:

  # Find who we are.  Look in the path if we contain no directory
  # separator.
  as_myself=...

Later, this may be used to re-exec the configure script with a better shell,

  exec $CONFIG_SHELL $as_opts "$as_myself" ${1+"$@"}

But, consider the following scenario:

  * I have some other "configure" in my $PATH.
  * I have a shell that doesn't support LINENO.
  * I execute ./configure for some package by running "sh configure".

What happens in that case is that the "as_myself" computation fails to
find a directory separator in "configure", and instead searches my path
for a usable "configure". It finds one, but not the one I wanted to run!
Now I have

  as_myself=/path/to/some/other/configure/script

and then since my shell doesn't support LINENO, I wind up running

  $CONFIG_SHELL ... /path/to/some/other/configure/script

In other words, I re-exec the wrong script entirely. This can be worked
around by running "sh ./configure" instead of "sh configure", but leads
to a great deal of head-scratching.

Is this something that can (should?) be fixed?

Michael Orlitzky <mjo>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by eggert (Posted a comment)
  • -email is unavailable- added by zackw (Posted a comment)
  • -email is unavailable- added by mjo (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-12-08 zackw StatusNone Need Info
    2023-12-08 zackw Priority5 - Unprioritized 3 - Release N+1

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code