Frequently I have troubles with configure being run by /bin/sh, not only performance related, but also broken behaviour - this time on AIX, triggering another bug within cvs-1.11.22 itself. This is why we set CONFIG_SHELL to $BASH in some prefix' profile.bashrc's. But according to [1] and [2], $CONFIG_SHELL has to be used when invoking ./configure already, not relying on configure restarting itself with $CONFIG_SHELL. [1] http://www.gnu.org/software/libtool/manual/html_node/Configure-notes.html [2] http://lists.gnu.org/archive/html/bug-libtool/2008-11/msg00061.html
Created attachment 222987 [details, diff] proposed patch to use CONFIG_SHELL when set I can think of situations where ./configure is not a real shell-script, which should not be executed using some shell, so I do not set CONFIG_SHELL in general. IFF such an ebuild really uses econf(), it would have to 'unset CONFIG_SHELL', but this might be a problem on the less important platforms AIX and IRIX only ATM.
Created attachment 223057 [details, diff] portage-2.2-config-shell.patch If portage should be using CONFIG_SHELL, this is a simpler approach. I've been using it for a while, but I never opened a bug for it because to be honest I'm not sure this is the right way to go about it. Non-autoconf configure scripts with #!/usr/bin/bash exist, and if any of those are called using econf, this change will break things.
(In reply to comment #2) > If portage should be using CONFIG_SHELL, this is a simpler approach. I've been > using it for a while, but I never opened a bug for it because to be honest I'm > not sure this is the right way to go about it. Non-autoconf configure scripts > with #!/usr/bin/bash exist, and if any of those are called using econf, this > change will break things. We could probe the shebang and only use CONFIG_SHELL when the shebang specifies sh.
What if we would run the prefix shebang check upfront on the configure file? That would also catch configure scripts written in perl or python that use /usr/bin/{perl,python}. Those exist, and are now sedded in the ebuilds.
Comment on attachment 222987 [details, diff] proposed patch to use CONFIG_SHELL when set (In reply to comment #2) > Created an attachment (id=223057) [details] > portage-2.2-config-shell.patch > > If portage should be using CONFIG_SHELL, this is a simpler approach. This one is unsafe to CONFIG_SHELL containing blanks, but maybe this will never really work anyway. OTOH, it might allow for CONFIG_SHELL="/bin/bash -x" (just a thought, not tested). It also is the (upstream) suggested one...
(In reply to comment #5) > This one is unsafe to CONFIG_SHELL containing blanks, but maybe this will never > really work anyway. OTOH, it might allow for CONFIG_SHELL="/bin/bash -x" (just > a thought, not tested). It also is the (upstream) suggested one... Calling commands unquoted is the norm, precisely to allow arguments. Take a look at make's default rules (make -pf /dev/null) if you like, for example, and you won't find any shell quoting. For another example, setting CC="/path/to/gcc -m32" is not uncommon and you'll have a hard time finding a package where this does anything other than calling gcc with the -m32 option. :)
Created attachment 223237 [details, diff] use sed to substitute $CONFIG_SHELL in the shebang
Uhm, doesn't this break for perl scripts that mimick autoconf enough to be able to use econf? I know these scripts exist in @system. How about -e'1s:^#! \?/bin/sh$:#! '"${CONFIG_SHELL}"':' instead then?
(In reply to comment #6) > ... if you like, for example, and > you won't find any shell quoting. For another example, setting CC="/path/to/gcc > -m32" is not uncommon and you'll have a hard time finding a package where this > does anything other than calling gcc with the -m32 option. :) off-topic, but: actually not, I had to fix 2 or 3 packages to be able to bootstrap with CC="gcc -m32"
(In reply to comment #8) > Uhm, doesn't this break for perl scripts that mimick autoconf enough to be able > to use econf? I know these scripts exist in @system. > > How about -e'1s:^#! \?/bin/sh$:#! '"${CONFIG_SHELL}"':' instead then? The match against $(head -n1 "$ECONF_SOURCE/configure") is supposed to identify relevant configure scripts. Is there something wrong with that part?
(In reply to comment #10) > The match against $(head -n1 "$ECONF_SOURCE/configure") is supposed to identify > relevant configure scripts. Is there something wrong with that part? There's a possible problem with your {^'#!'/bin/sh} part: The shebang might look like "#!/bin/sh" as well as "#! /bin/sh". I'm not sure if there are autoconf verisons creating the former, as the latter is the most portable one (old BSD's IIRC used "#! /" as 32bit file-magic number - seen on some autoconf site once, but cannot find this again). However, searching for "#!" in autoconf doc[1], both variants seem to be in use. [1] http://www.gnu.org/software/autoconf/manual/autoconf.html
And we (G/FBSD) could use this too, thanks Fabian for the heads up.
This is in git now: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=b1e8c0e266cf875787cf44ee22458008845d22a4 (In reply to comment #11) > There's a possible problem with your {^'#!'/bin/sh} part: The shebang might > look like "#!/bin/sh" as well as "#! /bin/sh". The regex looks like this now: ^'#!'[[:space:]]*/bin/sh[[:space:]]*$
(In reply to comment #13) The 's' command of sed is unterminated. The shebang might contain some options passed to interpreter. I have fixed these problems: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commitdiff;h=6dcb8b35d6bda91556ab5bb05d0666f71d207fc9
This is in 2.2_rc68, but I'll leave this bug open until it's in an unmasked version.
This is fixed in 2.1.9.