Re: dash 0.5.12 parameter expansion using classes not working

[Brian Inglis <Brian.Inglis@Shaw.ca>]

On 2023-02-08 01:43, Harald van Dijk wrote:
> On 08/02/2023 05:14, Brian Inglis wrote:
>> Under dash 0.5.12 parameter expansion using regexp classes [[:space:]] to trim 
>> no longer works, but releases up to 0.5.11.5 still work correctly with the 
>> same environment and default config options.
>>
>> In the attached dash script and logs, one of our users has an abstruse string 
>> they use to clean up build command lines, but I trimmed that down to the 
>> locale-dependent [[:space:]] regexp, then to the ASCII whitespace characters 
>> generated by echo, and only the last still works with 0.5.12, all work under 
>> 0.5.11.5.
>>
>> Nothing obvious jumps out from the commitdiffs between then and now, so I am 
>> hoping some possible cause occurs to you.
>>
>> Build environment was Cygwin+newlib autoreconf with autoconf 2.71, autogen 
>> 5.18.16, automake 1.16.5, gcc 11.3, binutils 2.29, coreutils 9.0, dash 
>> 0.5.11.5 as sh.

> dash 0.5.12 includes commit 7638476c 
> <https://git.kernel.org/pub/scm/utils/dash/dash.git/commit/?id=7638476c18f2a8451b05d49f4e767ee1f98cfc17>
> which enables the use of libc's fnmatch() by default. Looking at newlib 
> sources,
> <https://github.com/eblot/newlib/blob/master/newlib/libc/posix/fnmatch.c>,
> it appears that newlib's fnmatch() does not support character classes and
> should not be used for dash. Would you be able to check that explicitly
> passing --disable-fnmatch to the configure options gets it working properly
> again?
Thanks very much Harald,

That indeed was the cause and solution - test release on its way to mirrors.

Cygwin/newlib is tricky in that it may extend newlib with hosted features, some 
implemented with C++, so there is sometimes another source to check for on the 
same servers hosting automake, binutils, gdb, glibc, valgrind, etc.:

https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/libc/fnmatch.c
https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=newlib/libc/posix/fnmatch.c
https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/glob.cc
https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=newlib/libc/posix/glob.c

Also tricky is that newlib is mainly BSD or similarly licensed for use by and in 
commercial embedded tool chains and RTOSes whereas Cygwin is mainly LGPL and 
packages GPL licensed.

[I noticed that dash src/compile sets up Cygwin to use cygpath -m to produce 
Windows file names, and patched that out in our build.
If anyone reports anything under Cygwin being non-POSIX conforming, or behaving 
differently to any most Unix platforms, please have them report that to the 
cygwin@cygwin.com public mailing list (no subscription required) or possibly 
discuss on the Libera.Chat IRC channel #cygwin, where it may be addressed.
This does not apply to Cygwin hosted Mingw64 or Msys2 cross-build toolchains.

Few Cygwin packages now have any support for using Windows features or file names.
That handling is hidden way down in the emulation shared library where possible.
All sources and tests should build and run identically to Linux,  *BSDs, Solaris.
Features like Windows text files and file path names now mostly cause grief, 
unless they happen to end up being passed down verbatim to the correct part of 
the emulation library where they are taken care of.]

-- 
Take care. Thanks, Brian Inglis			Calgary, Alberta, Canada

La perfection est atteinte			Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter	not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer	but when there is no more to cut
			-- Antoine de Saint-Exupéry