Subject: Re: [nb]make variable expansion bug [usr.bin/file] ?
To: None <current-users@netbsd.org>
From: Thierry Laronde <tlaronde@polynum.org>
List: current-users
Date: 10/06/2002 21:53:44
On Sun, Oct 06, 2002 at 01:00:28AM +0200, Thierry Laronde wrote:
> Hello,
>
> I'm compiling current (actually a 21/09/02 snapshot) and a weird problem
> occurs with the compilation of `file'.
>
> The following variable assignment in the Makefile:
>
> MAGDIRF:sh= echo ${.CURDIR}/magdir/[0-9a-z]*
>
> causes ./magdir/CVS to be included in the list and thus:
>
> magic: ${MAGFILES}
> cat ${MAGFILES} > ${.TARGET}
>
> fails, `cat' grumbling that ./magdir/CVS is a directory.
>
> Since the substitution of magdir/[0-9a-z]* behaves normally under my
> Bourne Shells (ash, pdksh and bash) is the substitution handled directly
> by make and is this a known bug? Or Am I missing something obvious?
>
After looking at the sources for pmake, pmake is not at fault. The
substitution is invoked via "/bin/sh -c '<string>'" and here is the
"funny" result:
$ ls -al /bin/sh
lrwxrwxrwx 1 root root 4 sep 5 2001 /bin/sh -> bash
$ pwd
/home/tlaronde/cvs/NetBSD/src/usr.bin/file
$ echo ./magdir/[a-z0-9]*
./magdir/acorn ./magdir/adi ./magdir/adventure [..] ./magdir/ctags ./magdir/cvs ./magdir/database [..] ./magdir/zilog ./magdir/zyxel
So OK everything fine. Now invoking `bash' (aka /bin/sh on the
Debian/GNU/Linux system) non interactively:
$ /bin/sh -c 'echo ./magdir/[a-z0-9]*'
./magdir/acorn [..] ./magdir/ctags ./magdir/CVS ./magdir/cvs ./magdir/database [..] ./magdir/zyxel
Uh!!! `bash' now do it case insensitive!!!
Invoking ash:
$ /bin/ash -c 'echo ./magdir/[a-z0-9]*'
./magdir/acorn [..] ./magdir/ctags ./magdir/cvs ./magdir/database [..] ./magdir/zyxel
correct... and the same with pdksh.
`bash' is definitively not a system shell!
The bash version:
$ bash --version
GNU bash, version 2.03.0(1)-release (i386-pc-linux-gnu)
Copyright 1998 Free Software Foundation, Inc.
So I have now set my system shell to a system shell (i.e. ash) and maybe
could someone add a caveat somewhere.
Thanks and sorry for the wrong initial assertions.
--
Thierry Laronde (Alceste) <tlaronde@polynum.org>
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C