bug: 0.5.13 regression in parsing

bug: 0.5.13 regression in parsing

[Reilly Brogan]

I upgraded the dash package on aerynos to v0.5.13 and started seeing 
some build failures in packages that previously built just fine.

Build error:
```
+ make -j 32
   GEN      src/extensions.c
   CC       src/libxcb_errors_la-xcb_errors.lo
./libtool: 369: Syntax error: "}" unexpected
```

And the relevant line in the libtool script:
```
archive_expsym_cmds="echo "{ global:" > $output_objdir/$libname.ver~
             cat $export_symbols | $SED -e "s/\(.*\)/\1;/" >> 
$output_objdir/$libname.ver~
             echo "local: *; };" >> $output_objdir/$libname.ver~
             $CC -shared $pic_flag $libobjs $deplibs $compiler_flags 
$wl-soname $wl$soname $wl-version-script $wl$output_objdir/$libname.ver 
-o $lib"
```
(I've uploaded the full libtool script at 
https://gist.githubusercontent.com/ReillyBrogan/9a4e6a02e5871fdbeb793a549131e197/raw/5a00be91f0cf38df7706eabc4c0eadcac74e84dd/gistfile1.txt)

Bisecting between 0.5.12 and 0.5.13 reveals that 
e878137f63e61926bbdff7062a558f0143ed5872 is the first bad commit.

Regards,
Reilly

Re: bug: 0.5.13 regression in parsing

[Abdullah]

Same error also happened to me with dash 0.5.12.

But I assume the bug is not from dash but from libtool.

> archive_expsym_cmds="echo "{ global:" > $output_objdir/$libname.ver~
>              cat $export_symbols | $SED -e "s/\(.*\)/\1;/" >>
> $output_objdir/$libname.ver~
>              echo "local: *; };" >> $output_objdir/$libname.ver~
>              $CC -shared $pic_flag $libobjs $deplibs $compiler_flags
> $wl-soname $wl$soname $wl-version-script $wl$output_objdir/$libname.ver
> -o $lib"

That is a broken syntax, they should've used single quotes.
I.e.:

> archive_expsym_cmds="echo '{ global:' > $output_objdir/$libname.ver~
>              cat $export_symbols | $SED -e 's/\(.*\)/\1;/' >>
> $output_objdir/$libname.ver~
>              echo 'local: *; };' >> $output_objdir/$libname.ver~
>              $CC -shared $pic_flag $libobjs $deplibs $compiler_flags
> $wl-soname $wl$soname $wl-version-script $wl$output_objdir/$libname.ver
> -o $lib"

Re: bug: 0.5.13 regression in parsing

[Herbert Xu]

Reilly Brogan <reilly@reillybrogan.com> wrote:
>
> (I've uploaded the full libtool script at 
> https://gist.githubusercontent.com/ReillyBrogan/9a4e6a02e5871fdbeb793a549131e197/raw/5a00be91f0cf38df7706eabc4c0eadcac74e84dd/gistfile1.txt)

There's something wrong with this script because it fails with
every shell, including bash:

$ bash -n gistfile1.txt
gistfile1.txt: line 369: syntax error near unexpected token `}'
gistfile1.txt: line 369: `            echo "local: *; };" >> $output_objdir/$libname.ver~'

Did it get corrupted somehow?

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: bug: 0.5.13 regression in parsing

[Harald van Dijk]

On 23/09/2025 07:29, Herbert Xu wrote:
> Reilly Brogan <reilly@reillybrogan.com> wrote:
>>
>> (I've uploaded the full libtool script at
>> https://gist.githubusercontent.com/ReillyBrogan/9a4e6a02e5871fdbeb793a549131e197/raw/5a00be91f0cf38df7706eabc4c0eadcac74e84dd/gistfile1.txt)
> 
> There's something wrong with this script because it fails with
> every shell, including bash:
> 
> $ bash -n gistfile1.txt
> gistfile1.txt: line 369: syntax error near unexpected token `}'
> gistfile1.txt: line 369: `            echo "local: *; };" >> $output_objdir/$libname.ver~'
> 
> Did it get corrupted somehow?

Those lines are:

   archive_expsym_cmds="echo "{ global:" > $output_objdir/$libname.ver~
               cat $export_symbols | $SED -e "s/\(.*\)/\1;/" >> 
$output_objdir/$libname.ver~
               echo "local: *; };" >> $output_objdir/$libname.ver~
               $CC -shared $pic_flag $libobjs $deplibs $compiler_flags 
$wl-soname $wl$soname $wl-version-script $wl$output_objdir/$libname.ver 
-o $lib"

What those lines should look like, and look like on my local system 
after running configure:

   archive_expsym_cmds='echo "{ global:" > $output_objdir/$libname.ver~
               cat $export_symbols | $SED -e "s/\(.*\)/\1;/" >> 
$output_objdir/$libname.ver~
               echo "local: *; };" >> $output_objdir/$libname.ver~
               $CC -shared $pic_flag $libobjs $deplibs $compiler_flags 
$wl-soname $wl$soname $wl-version-script $wl$output_objdir/$libname.ver 
-o $lib'

config.status file is a file that gets generated by configure, so 
something is going wrong running configure with dash 0.5.13, and some 
more digging is needed to figure out where exactly it's going wrong.

Cheers,
Harald van Dijk

Re: bug: 0.5.13 regression in parsing

[Herbert Xu]

On Tue, Sep 23, 2025 at 11:11:37AM +0100, Harald van Dijk wrote:
>
> config.status file is a file that gets generated by configure, so something
> is going wrong running configure with dash 0.5.13, and some more digging is
> needed to figure out where exactly it's going wrong.

Thanks for the hint.  I can reproduce now by attempting to build
xcb-util.  I'm looking into it.
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: bug: 0.5.13 regression in parsing

[Herbert Xu]

On Tue, Sep 23, 2025 at 06:33:25PM +0800, Herbert Xu wrote:
>
> Thanks for the hint.  I can reproduce now by attempting to build
> xcb-util.  I'm looking into it.

OK it's the same old problem: whenever we add a new feature that
makes us closer to bash, libtool gets confused and mistakes dash
for bash.  Normally it would explicitly invoke /bin/bash if it
detects that /bin/sh is dash.

As libtool is still not POSIX-compliant, that means it produces
crap.

I need to look into exactly which bash/dash test it's using that
we've managed to break and see if we can undo it.  If not then
libtool will just have to be fixed.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: bug: 0.5.13 regression in parsing

[Herbert Xu]

On Tue, Sep 23, 2025 at 06:36:37PM +0800, Herbert Xu wrote:
>
> I need to look into exactly which bash/dash test it's using that
> we've managed to break and see if we can undo it.  If not then
> libtool will just have to be fixed.

Actually it appears that nothing has changed.

autoconf relies on LINENO to distinguish between dash and bash.
Because dash has supported LINENO for years, this causes massive
breakage because autoconf then goes on to rely on a non-POSIX
echo with dash, which causes backslashes to be lost.

Debian works around this by disabling LINENO in dash.

So it's a bug in autoconf that should be fixed there.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: bug: 0.5.13 regression in parsing

[Harald van Dijk]

On 23/09/2025 11:36, Herbert Xu wrote:
> On Tue, Sep 23, 2025 at 06:33:25PM +0800, Herbert Xu wrote:
>>
>> Thanks for the hint.  I can reproduce now by attempting to build
>> xcb-util.  I'm looking into it.
> 
> OK it's the same old problem: whenever we add a new feature that
> makes us closer to bash, libtool gets confused and mistakes dash
> for bash.  Normally it would explicitly invoke /bin/bash if it
> detects that /bin/sh is dash.

configure did/does prefer bash but can run with dash, either on systems 
where bash is not available or when CONFIG_SHELL is set to bypass the 
automatic switch to bash. This has been working for years, and I very 
much suspect that if you run with a slightly older version of dash, you 
will see that it also works for you.

Cheers,
Harald van Dijk

[PATCH] expand: Fix typo in pmatch for wildcard search

[Herbert Xu]

On Tue, Sep 23, 2025 at 12:03:20PM +0100, Harald van Dijk wrote:
>
> configure did/does prefer bash but can run with dash, either on systems
> where bash is not available or when CONFIG_SHELL is set to bypass the
> automatic switch to bash. This has been working for years, and I very much
> suspect that if you run with a slightly older version of dash, you will see
> that it also works for you.

Thanks, you're right.

And Reilly had already isolated the buggy commit through bisection:

---8<---
Skip the optimisation for * for only if the next character is
? and [, rather than ? and anything but [.

Reported-by: Reilly Brogan <reilly@reillybrogan.com>
Fixes: e878137f63e6 ("expand: Move stop array closer to strpbrk call")
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

diff --git a/src/expand.c b/src/expand.c
index 992cbe8..1fab394 100644
--- a/src/expand.c
+++ b/src/expand.c
@@ -1911,7 +1911,7 @@ static int pmatch(char *pattern, const char *string)
 				c = *++p;
 			if (!c)
 				return 1;
-			if (c == '?' || c != '[')
+			if (c == '?' || c == '[')
 				c = CTLESC;
 			for (;;) {
 				if (c != CTLESC) {
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] expand: Fix typo in pmatch for wildcard search

[reilly]

I can confirm that that patch works for all of the builds that formerly failed, thanks!

On 9/23/25 10:00 AM, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Tue, Sep 23, 2025 at 12:03:20PM +0100, Harald van Dijk wrote:
> >
> > configure did/does prefer bash but can run with dash, either on systems
> > where bash is not available or when CONFIG_SHELL is set to bypass the
> > automatic switch to bash. This has been working for years, and I very much
> > suspect that if you run with a slightly older version of dash, you will see
> > that it also works for you.
> 
> Thanks, you're right.
> 
> And Reilly had already isolated the buggy commit through bisection:
> 
> ---8<---
> Skip the optimisation for * for only if the next character is
> ? and [, rather than ? and anything but [.
> 
> Reported-by: Reilly Brogan <reilly@reillybrogan.com>
> Fixes: e878137f63e6 ("expand: Move stop array closer to strpbrk call")
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> 
> diff --git a/src/expand.c b/src/expand.c
> index 992cbe8..1fab394 100644
> --- a/src/expand.c
> +++ b/src/expand.c
> @@ -1911,7 +1911,7 @@ static int pmatch(char *pattern, const char *string)
>   				c = *++p;
>   			if (!c)
>   				return 1;
> -			if (c == '?' || c != '[')
> +			if (c == '?' || c == '[')
>   				c = CTLESC;
>   			for (;;) {
>   				if (c != CTLESC) {
>