Bug#243885: Bug#240887: Package building problem.
Kurt Roeckx <[EMAIL PROTECTED]> wrote:
>
>> Not quite. In the context of case patterns and fnmatch, quote removal
>> is not performed.
>
> You mean fnmatch() gets called with the FNM_NOESCAPE flag?
No. I mean that on the input path to fnmatch(), the escape characters
have to be there.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#243885: Bug#240887: Package building problem.
Kurt Roeckx <[EMAIL PROTECTED]> wrote:
>
>> Not quite. In the context of case patterns and fnmatch, quote removal
>> is not performed.
>
> You mean fnmatch() gets called with the FNM_NOESCAPE flag?
No. I mean that on the input path to fnmatch(), the escape characters
have to be there.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#243885: Bug#240887: Package building problem.
On Sat, Apr 17, 2004 at 10:44:27PM +0200, Kurt Roeckx wrote:
>
> If I understand Herbert Xu correctly, he's saying the regex
> should be written as:
> *[][~#$^&*(){}\|;<>?]*
No, the way it's written currently is fine.
It's glibc's fnmatch(3) implementation that's broken.
Cheers,
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#243885: Bug#240887: Package building problem.
On Sat, Apr 17, 2004 at 10:44:27PM +0200, Kurt Roeckx wrote:
>
> If I understand Herbert Xu correctly, he's saying the regex
> should be written as:
> *[][~#$^&*(){}\|;<>?]*
No, the way it's written currently is fine.
It's glibc's fnmatch(3) implementation that's broken.
Cheers,
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#243885: Bug#240887: Package building problem.
On Sat, Apr 17, 2004 at 12:14:39PM -0700, Ben Pfaff wrote:
> Herbert Xu <[EMAIL PROTECTED]> writes:
>
> >> Accordingly, I believe that the pattern in your example means
> >> "backslash, followed by a, followed by closing square bracket", not what
> >> you think it means.
> >
> > You're quite right. This is reaffirmed by the POSIX document for
> > basic regular expressions, which is what POSIX uses to define
> > shell patterns.
> >
> > Therefore tetex-bin and autoconf will need to be fixed instead to
> > not use backslashes in [] expressions.
>
> I read through the entire bug log for 240887 and couldn't figure
> out what actual bug in Autoconf is being pointed out. Can anyone
> help me out? I can't fix a bug if no one tells me what the bug
> is.
configure calls itself in subdirs and tries to pass the
same arguments again.
In configure there is this code:
# Strip out --no-create and --no-recursion so they do not pile
# up.
# Also quote any args containing shell metacharacters.
ac_configure_args=
for ac_arg
do
case "$ac_arg" in
-no-create | --no-create | --no-creat | --no-crea | --no-cre \
| --no-cr | --no-c) ;;
-no-recursion | --no-recursion | --no-recursio | --no-recursi \
| --no-recurs | --no-recur | --no-recu | --no-rec | --no-re |
--no-r) ;;
*" "*|*" "*|*[\[\]\~\#\$\^\&\*\(\)\{\}\\\|\;\<\>\?]*)
ac_configure_args="$ac_configure_args '$ac_arg'" ;;
*) ac_configure_args="$ac_configure_args $ac_arg" ;;
esac
done
Using dash it's not properly requoting
'--mandir=${prefix}/share/man', it gets turned into
--mandir=${prefix} at the first level and --mandir=/usr/share/man
at the next level.
Using bash it stays '--mandir=${prefix}/share/man'.
I'm not really sure who's to blame for it not working. I think
there is atleast a bug in glibc's fnmatch(). That regex might
also need fixing. But I really don't know what needs to be done.
If I understand Herbert Xu correctly, he's saying the regex
should be written as:
*[][~#$^&*(){}\|;<>?]*
Kurt
Bug#243885: Bug#240887: Package building problem.
Herbert Xu <[EMAIL PROTECTED]> writes: >> Accordingly, I believe that the pattern in your example means >> "backslash, followed by a, followed by closing square bracket", not what >> you think it means. > > You're quite right. This is reaffirmed by the POSIX document for > basic regular expressions, which is what POSIX uses to define > shell patterns. > > Therefore tetex-bin and autoconf will need to be fixed instead to > not use backslashes in [] expressions. I read through the entire bug log for 240887 and couldn't figure out what actual bug in Autoconf is being pointed out. Can anyone help me out? I can't fix a bug if no one tells me what the bug is. -- "Mon peu de succÃs prÃs des femmes est toujours venu de les trop aimer." --Jean-Jacques Rousseau
Bug#243885: Bug#240887: Package building problem.
On Sat, Apr 17, 2004 at 12:14:39PM -0700, Ben Pfaff wrote:
> Herbert Xu <[EMAIL PROTECTED]> writes:
>
> >> Accordingly, I believe that the pattern in your example means
> >> "backslash, followed by a, followed by closing square bracket", not what
> >> you think it means.
> >
> > You're quite right. This is reaffirmed by the POSIX document for
> > basic regular expressions, which is what POSIX uses to define
> > shell patterns.
> >
> > Therefore tetex-bin and autoconf will need to be fixed instead to
> > not use backslashes in [] expressions.
>
> I read through the entire bug log for 240887 and couldn't figure
> out what actual bug in Autoconf is being pointed out. Can anyone
> help me out? I can't fix a bug if no one tells me what the bug
> is.
configure calls itself in subdirs and tries to pass the
same arguments again.
In configure there is this code:
# Strip out --no-create and --no-recursion so they do not pile
# up.
# Also quote any args containing shell metacharacters.
ac_configure_args=
for ac_arg
do
case "$ac_arg" in
-no-create | --no-create | --no-creat | --no-crea | --no-cre \
| --no-cr | --no-c) ;;
-no-recursion | --no-recursion | --no-recursio | --no-recursi \
| --no-recurs | --no-recur | --no-recu | --no-rec | --no-re |
--no-r) ;;
*" "*|*" "*|*[\[\]\~\#\$\^\&\*\(\)\{\}\\\|\;\<\>\?]*)
ac_configure_args="$ac_configure_args '$ac_arg'" ;;
*) ac_configure_args="$ac_configure_args $ac_arg" ;;
esac
done
Using dash it's not properly requoting
'--mandir=${prefix}/share/man', it gets turned into
--mandir=${prefix} at the first level and --mandir=/usr/share/man
at the next level.
Using bash it stays '--mandir=${prefix}/share/man'.
I'm not really sure who's to blame for it not working. I think
there is atleast a bug in glibc's fnmatch(). That regex might
also need fixing. But I really don't know what needs to be done.
If I understand Herbert Xu correctly, he's saying the regex
should be written as:
*[][~#$^&*(){}\|;<>?]*
Kurt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#243885: Bug#240887: Package building problem.
Herbert Xu <[EMAIL PROTECTED]> writes: >> Accordingly, I believe that the pattern in your example means >> "backslash, followed by a, followed by closing square bracket", not what >> you think it means. > > You're quite right. This is reaffirmed by the POSIX document for > basic regular expressions, which is what POSIX uses to define > shell patterns. > > Therefore tetex-bin and autoconf will need to be fixed instead to > not use backslashes in [] expressions. I read through the entire bug log for 240887 and couldn't figure out what actual bug in Autoconf is being pointed out. Can anyone help me out? I can't fix a bug if no one tells me what the bug is. -- "Mon peu de succÃs prÃs des femmes est toujours venu de les trop aimer." --Jean-Jacques Rousseau
Bug#243885: Bug#240887: Package building problem.
On Sat, Apr 17, 2004 at 07:58:21AM +1000, Herbert Xu wrote: > On Fri, Apr 16, 2004 at 08:49:14PM +0200, Kurt Roeckx wrote: > > > > After reading all that you have to get confused about what "[\[\]\\]" means. > > At the "highest level" it says that the '\' should be discarded, > > Not quite. In the context of case patterns and fnmatch, quote removal > is not performed. You mean fnmatch() gets called with the FNM_NOESCAPE flag? Kurt
Bug#243885: Bug#240887: Package building problem.
On Fri, Apr 16, 2004 at 08:49:14PM +0200, Kurt Roeckx wrote:
>
> After reading all that you have to get confused about what "[\[\]\\]" means.
> At the "highest level" it says that the '\' should be discarded,
Not quite. In the context of case patterns and fnmatch, quote removal
is not performed.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#243885: Bug#240887: Package building problem.
On Sat, Apr 17, 2004 at 07:58:21AM +1000, Herbert Xu wrote: > On Fri, Apr 16, 2004 at 08:49:14PM +0200, Kurt Roeckx wrote: > > > > After reading all that you have to get confused about what "[\[\]\\]" means. > > At the "highest level" it says that the '\' should be discarded, > > Not quite. In the context of case patterns and fnmatch, quote removal > is not performed. You mean fnmatch() gets called with the FNM_NOESCAPE flag? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#243885: Bug#240887: Package building problem.
On Fri, Apr 16, 2004 at 08:49:14PM +0200, Kurt Roeckx wrote:
>
> After reading all that you have to get confused about what "[\[\]\\]" means.
> At the "highest level" it says that the '\' should be discarded,
Not quite. In the context of case patterns and fnmatch, quote removal
is not performed.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#240887: Package building problem.
On Fri, Apr 16, 2004 at 12:54:03PM +1000, Herbert Xu wrote:
>
> On Fri, Apr 16, 2004 at 08:09:05AM +1000, herbert wrote:
> >
> > On Thu, Apr 15, 2004 at 03:10:58PM +0100, Colin Watson wrote:
> >
> > > Accordingly, I believe that the pattern in your example means
> > > "backslash, followed by a, followed by closing square bracket", not what
> > > you think it means.
> >
> > You're quite right. This is reaffirmed by the POSIX document for
> > basic regular expressions, which is what POSIX uses to define
> > shell patterns.
For fnmatch it says:
The fnmatch() function shall match patterns as described in the
Shell and Utilities volume of IEEE Std 1003.1-2001, Section 2.13.1,
Patterns Matching a Single Character, and Section 2.13.2, Patterns
Matching Multiple Characters.
Which says:
The pattern matching notation described in this section is used to
specify patterns for matching strings in the shell. Historically,
pattern matching notation is related to, but slightly different from,
the regular expression notation described in the Base Definitions
volume of IEEE Std 1003.1-2001, Chapter 9, Regular Expressions. For
this reason, the description of the rules for this pattern matching
notation are based on the description of regular expression notation,
modified to include backslash escape processing.
[...]
A backslash character shall escape the following character.
The escaping backslash shall be discarded.
[...]
The description of basic regular expression bracket expressions in the
Base Definitions volume of IEEE Std 1003.1-2001, Section 9.3.5, RE
Bracket Expression shall also apply to the pattern bracket expression
That says:
The
right-bracket ( ']' ) shall lose its special meaning and represent
itself in a bracket expression if it occurs first in the list
(after an initial circumflex ( '^' ), if any).
[...]
The special characters '.' , '*' , '[' , and '\' (period, asterisk,
left-bracket, and backslash, respectively) shall lose their
special meaning within a bracket expression.
After reading all that you have to get confused about what "[\[\]\\]" means.
At the "highest level" it says that the '\' should be discarded,
so you end up with "[[]\]" and look at that as a normal regular
expression? Atleast that is how I interpret things.
But testing this shows that this program:
#include
int main()
{
printf("%d\n", fnmatch("[\\]a]", "a", 0));
printf("%d\n", fnmatch("[\\]a]", "\\", 0));
printf("%d\n", fnmatch("[\\]a]", "]", 0));
printf("%d\n", fnmatch("[]a]", "a", 0));
printf("%d\n", fnmatch("[]a]", "]", 0));
return 0;
}
returns:
1
1
0
0
0
This does _not_ make sense to me in any way. If the 3rd line says
there is a match, I would think it's interpreting it as "[]a]",
but then the first line should match too.
Ps: On other platforms I get:
0
1
0
0
0
One returned:
1
1
1
0
0
Which atleast make a little more sense.
Kurt
Re: Bug#240887: Package building problem.
On Fri, Apr 16, 2004 at 12:54:03PM +1000, Herbert Xu wrote:
>
> On Fri, Apr 16, 2004 at 08:09:05AM +1000, herbert wrote:
> >
> > On Thu, Apr 15, 2004 at 03:10:58PM +0100, Colin Watson wrote:
> >
> > > Accordingly, I believe that the pattern in your example means
> > > "backslash, followed by a, followed by closing square bracket", not what
> > > you think it means.
> >
> > You're quite right. This is reaffirmed by the POSIX document for
> > basic regular expressions, which is what POSIX uses to define
> > shell patterns.
For fnmatch it says:
The fnmatch() function shall match patterns as described in the
Shell and Utilities volume of IEEE Std 1003.1-2001, Section 2.13.1,
Patterns Matching a Single Character, and Section 2.13.2, Patterns
Matching Multiple Characters.
Which says:
The pattern matching notation described in this section is used to
specify patterns for matching strings in the shell. Historically,
pattern matching notation is related to, but slightly different from,
the regular expression notation described in the Base Definitions
volume of IEEE Std 1003.1-2001, Chapter 9, Regular Expressions. For
this reason, the description of the rules for this pattern matching
notation are based on the description of regular expression notation,
modified to include backslash escape processing.
[...]
A backslash character shall escape the following character.
The escaping backslash shall be discarded.
[...]
The description of basic regular expression bracket expressions in the
Base Definitions volume of IEEE Std 1003.1-2001, Section 9.3.5, RE
Bracket Expression shall also apply to the pattern bracket expression
That says:
The
right-bracket ( ']' ) shall lose its special meaning and represent
itself in a bracket expression if it occurs first in the list
(after an initial circumflex ( '^' ), if any).
[...]
The special characters '.' , '*' , '[' , and '\' (period, asterisk,
left-bracket, and backslash, respectively) shall lose their
special meaning within a bracket expression.
After reading all that you have to get confused about what "[\[\]\\]" means.
At the "highest level" it says that the '\' should be discarded,
so you end up with "[[]\]" and look at that as a normal regular
expression? Atleast that is how I interpret things.
But testing this shows that this program:
#include
int main()
{
printf("%d\n", fnmatch("[\\]a]", "a", 0));
printf("%d\n", fnmatch("[\\]a]", "\\", 0));
printf("%d\n", fnmatch("[\\]a]", "]", 0));
printf("%d\n", fnmatch("[]a]", "a", 0));
printf("%d\n", fnmatch("[]a]", "]", 0));
return 0;
}
returns:
1
1
0
0
0
This does _not_ make sense to me in any way. If the 3rd line says
there is a match, I would think it's interpreting it as "[]a]",
but then the first line should match too.
Ps: On other platforms I get:
0
1
0
0
0
One returned:
1
1
1
0
0
Which atleast make a little more sense.
Kurt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#240887: Package building problem.
Processing commands for [EMAIL PROTECTED]: > reopen 243885 Bug#243885: fnmatch breaks on [\]] Bug reopened, originator not changed. > reassign 240887 dash Bug#240887: backslashes are literal in shell bracket expressions Bug reassigned from package `tetex-bin' to `dash'. > retitle 240887 fnmatch(3) is broken Bug#240887: backslashes are literal in shell bracket expressions Changed Bug title. > quit Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Re: Bug#240887: Package building problem.
reopen 243885
reassign 240887 dash
retitle 240887 fnmatch(3) is broken
quit
On Fri, Apr 16, 2004 at 08:09:05AM +1000, herbert wrote:
>
> On Thu, Apr 15, 2004 at 03:10:58PM +0100, Colin Watson wrote:
>
> > Accordingly, I believe that the pattern in your example means
> > "backslash, followed by a, followed by closing square bracket", not what
> > you think it means.
>
> You're quite right. This is reaffirmed by the POSIX document for
> basic regular expressions, which is what POSIX uses to define
> shell patterns.
Sorry guys, but this turns out to be wrong. POSIX has an additional
paragraph which I skipped earlier:
: When pattern matching is used where shell quote removal is not performed
: (such as in the argument to the find -name primary when find is being
: called using one of the exec functions as defined in the System
: Interfaces volume of IEEE Std 1003.1-200x, or in the pattern argument
: to the fnmatch( ) function), special characters can be escaped to remove
: their special meaning by preceding them with a backslash character. This
: escaping back slash is discarded. The sequence "\\" represents one literal
: backslash. All of the requirements and effects of quoting on ordinary,
: shell special, and special pattern characters shall apply to escaping
: in this context.
This clearly says that backslashes must be interpreted.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Processed: Re: Bug#240887: Package building problem.
Processing commands for [EMAIL PROTECTED]: > reopen 243885 Bug#243885: fnmatch breaks on [\]] Bug reopened, originator not changed. > reassign 240887 dash Bug#240887: backslashes are literal in shell bracket expressions Bug reassigned from package `tetex-bin' to `dash'. > retitle 240887 fnmatch(3) is broken Bug#240887: backslashes are literal in shell bracket expressions Changed Bug title. > quit Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#240887: Package building problem.
reopen 243885
reassign 240887 dash
retitle 240887 fnmatch(3) is broken
quit
On Fri, Apr 16, 2004 at 08:09:05AM +1000, herbert wrote:
>
> On Thu, Apr 15, 2004 at 03:10:58PM +0100, Colin Watson wrote:
>
> > Accordingly, I believe that the pattern in your example means
> > "backslash, followed by a, followed by closing square bracket", not what
> > you think it means.
>
> You're quite right. This is reaffirmed by the POSIX document for
> basic regular expressions, which is what POSIX uses to define
> shell patterns.
Sorry guys, but this turns out to be wrong. POSIX has an additional
paragraph which I skipped earlier:
: When pattern matching is used where shell quote removal is not performed
: (such as in the argument to the find -name primary when find is being
: called using one of the exec functions as defined in the System
: Interfaces volume of IEEE Std 1003.1-200x, or in the pattern argument
: to the fnmatch( ) function), special characters can be escaped to remove
: their special meaning by preceding them with a backslash character. This
: escaping back slash is discarded. The sequence "\\" represents one literal
: backslash. All of the requirements and effects of quoting on ordinary,
: shell special, and special pattern characters shall apply to escaping
: in this context.
This clearly says that backslashes must be interpreted.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#240887: Package building problem.
On Thu, Apr 15, 2004 at 09:40:05PM +1000, Herbert Xu wrote:
> On Wed, Apr 14, 2004 at 01:59:01PM +0200, Frank K?ster wrote:
> > This is how dash calls it in _some_ subdirectories:
> >
> > configuring in tetex
> > running /bin/sh ./configure --prefix=/usr --enable-ipc --without-dialog\
> > --without-texinfo --with-system-ncurses --with-x --with-system-zlib \
> > --with-system-pnglib --with-system-tifflib --with-system-wwwlib \
> > --with-system-t1lib --disable-multiplatform --enable-shared \
> > --mandir=/usr/share/man --infodir=${prefix}/share/info \
> > --cache-file=.././config.cache --srcdir=.
> > loading cache .././config.cache
> >
> > That is, dash replaced the first occurence of ${prefix} by the variable
> > expansion. This shouldn't happen, because it is enclosed in single
> > quotes.
>
> This is caused by dash's use of fnmatch(3) which appears to break
> on patterns containing [\]...].
>
> Here is a sample program to demonstrate it.
>
> #include
> #include
>
> int main(int argc, char **argv)
> {
> printf("%d\n", fnmatch("[\\]a]", "a", 0));
> return 0;
> }
fnmatch(3) references glob(7), which says:
Character classes
An expression `[...]' where the first character after the lead-
ing `[' is not an `!' matches a single character, namely any of
the characters enclosed by the brackets. The string enclosed
by the brackets cannot be empty; therefore `]' can be allowed
between the brackets, provided that it is the first character.
(Thus, `[][!]' matches the three characters `[', `]' and `!'.)
...
One can remove the special meaning of `?', `*' and `[' by pre-
ceding them by a backslash, or, in case this is part of a shell
command line, enclosing them in quotes. Between brackets these
characters stand for themselves. Thus, `[[?*\]' matches the
four characters `[', `?', `*' and `\'.
Accordingly, I believe that the pattern in your example means
"backslash, followed by a, followed by closing square bracket", not what
you think it means.
--
Colin Watson [EMAIL PROTECTED]
Re: Bug#240887: Package building problem.
On Thu, Apr 15, 2004 at 09:40:05PM +1000, Herbert Xu wrote:
> On Wed, Apr 14, 2004 at 01:59:01PM +0200, Frank K?ster wrote:
> > This is how dash calls it in _some_ subdirectories:
> >
> > configuring in tetex
> > running /bin/sh ./configure --prefix=/usr --enable-ipc --without-dialog\
> > --without-texinfo --with-system-ncurses --with-x --with-system-zlib \
> > --with-system-pnglib --with-system-tifflib --with-system-wwwlib \
> > --with-system-t1lib --disable-multiplatform --enable-shared \
> > --mandir=/usr/share/man --infodir=${prefix}/share/info \
> > --cache-file=.././config.cache --srcdir=.
> > loading cache .././config.cache
> >
> > That is, dash replaced the first occurence of ${prefix} by the variable
> > expansion. This shouldn't happen, because it is enclosed in single
> > quotes.
>
> This is caused by dash's use of fnmatch(3) which appears to break
> on patterns containing [\]...].
>
> Here is a sample program to demonstrate it.
>
> #include
> #include
>
> int main(int argc, char **argv)
> {
> printf("%d\n", fnmatch("[\\]a]", "a", 0));
> return 0;
> }
fnmatch(3) references glob(7), which says:
Character classes
An expression `[...]' where the first character after the lead-
ing `[' is not an `!' matches a single character, namely any of
the characters enclosed by the brackets. The string enclosed
by the brackets cannot be empty; therefore `]' can be allowed
between the brackets, provided that it is the first character.
(Thus, `[][!]' matches the three characters `[', `]' and `!'.)
...
One can remove the special meaning of `?', `*' and `[' by pre-
ceding them by a backslash, or, in case this is part of a shell
command line, enclosing them in quotes. Between brackets these
characters stand for themselves. Thus, `[[?*\]' matches the
four characters `[', `?', `*' and `\'.
Accordingly, I believe that the pattern in your example means
"backslash, followed by a, followed by closing square bracket", not what
you think it means.
--
Colin Watson [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#240887: Package building problem.
Processing commands for [EMAIL PROTECTED]: > clone 240887 -1 Bug#240887: dash expands variable between '...' Bug 240887 cloned as bug 243885. > retitle -1 fnmatch breaks on [\]] Bug#243885: dash expands variable between '...' Changed Bug title. > submitter -1 [EMAIL PROTECTED] Bug#243885: fnmatch breaks on [\]] Changed Bug submitter from Kurt Roeckx <[EMAIL PROTECTED]> to [EMAIL PROTECTED] > reassign -1 libc6 Bug#243885: fnmatch breaks on [\]] Bug reassigned from package `dash' to `libc6'. > tags 240887 pending Bug#240887: dash expands variable between '...' There were no tags set. Tags added: pending > quit Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Re: Bug#240887: Package building problem.
clone 240887 -1
retitle -1 fnmatch breaks on [\]]
submitter -1 [EMAIL PROTECTED]
reassign -1 libc6
tags 240887 pending
quit
On Wed, Apr 14, 2004 at 01:59:01PM +0200, Frank K?ster wrote:
>
> This is how dash calls it in _some_ subdirectories:
>
> configuring in tetex
> running /bin/sh ./configure --prefix=/usr --enable-ipc --without-dialog\
> --without-texinfo --with-system-ncurses --with-x --with-system-zlib \
> --with-system-pnglib --with-system-tifflib --with-system-wwwlib \
> --with-system-t1lib --disable-multiplatform --enable-shared \
> --mandir=/usr/share/man --infodir=${prefix}/share/info \
> --cache-file=.././config.cache --srcdir=.
> loading cache .././config.cache
>
> That is, dash replaced the first occurence of ${prefix} by the variable
> expansion. This shouldn't happen, because it is enclosed in single
> quotes.
This is caused by dash's use of fnmatch(3) which appears to break
on patterns containing [\]...].
Here is a sample program to demonstrate it.
#include
#include
int main(int argc, char **argv)
{
printf("%d\n", fnmatch("[\\]a]", "a", 0));
return 0;
}
I will disable fnmatch(3) in dash for now.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Processed: Re: Bug#240887: Package building problem.
Processing commands for [EMAIL PROTECTED]: > clone 240887 -1 Bug#240887: dash expands variable between '...' Bug 240887 cloned as bug 243885. > retitle -1 fnmatch breaks on [\]] Bug#243885: dash expands variable between '...' Changed Bug title. > submitter -1 [EMAIL PROTECTED] Bug#243885: fnmatch breaks on [\]] Changed Bug submitter from Kurt Roeckx <[EMAIL PROTECTED]> to [EMAIL PROTECTED] > reassign -1 libc6 Bug#243885: fnmatch breaks on [\]] Bug reassigned from package `dash' to `libc6'. > tags 240887 pending Bug#240887: dash expands variable between '...' There were no tags set. Tags added: pending > quit Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#240887: Package building problem.
clone 240887 -1
retitle -1 fnmatch breaks on [\]]
submitter -1 [EMAIL PROTECTED]
reassign -1 libc6
tags 240887 pending
quit
On Wed, Apr 14, 2004 at 01:59:01PM +0200, Frank K?ster wrote:
>
> This is how dash calls it in _some_ subdirectories:
>
> configuring in tetex
> running /bin/sh ./configure --prefix=/usr --enable-ipc --without-dialog\
> --without-texinfo --with-system-ncurses --with-x --with-system-zlib \
> --with-system-pnglib --with-system-tifflib --with-system-wwwlib \
> --with-system-t1lib --disable-multiplatform --enable-shared \
> --mandir=/usr/share/man --infodir=${prefix}/share/info \
> --cache-file=.././config.cache --srcdir=.
> loading cache .././config.cache
>
> That is, dash replaced the first occurence of ${prefix} by the variable
> expansion. This shouldn't happen, because it is enclosed in single
> quotes.
This is caused by dash's use of fnmatch(3) which appears to break
on patterns containing [\]...].
Here is a sample program to demonstrate it.
#include
#include
int main(int argc, char **argv)
{
printf("%d\n", fnmatch("[\\]a]", "a", 0));
return 0;
}
I will disable fnmatch(3) in dash for now.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
