Mail Archives: djgpp/2006/12/01/07:15:15
Brian Inglis wrote:
> On Thu, 30 Nov 2006 00:20:00 -0800 in comp.os.msdos.djgpp, "Alexei A.
> Frounze" <alexfru AT chat DOT ru> wrote:
>
>> One more thing to consider, closing bracket as first character in the
>> list/range inside the bracket expression:
>> fnmatch("[]]", "]", 0) must return 0, doesn't
>> fnmatch("[!]]", "]", 0) must return 1, does (by luck)
>> fnmatch("[!]]", "a", 0) must return 0, doesn't
>
> rangematch() for should be a do ... while.
There're many ways to skin the cat. I changed it to for(;;) and added a flag
to look for ] at first execution of the body.
>> And one more, which seems to be partially wrong even in that same
>> RH9 linux distro:
>> fnmatch("\ab\c","abc",0) must return 0, does in linux, doesn't in
>> DJGPP fnmatch("\[abc\]","[abc]",0) must return 0, doesn't in both
>> linux and
>> DJGPP -- the spec doesn't make an exception for the escaped opening
>> bracket, \[ when describes the escaping option. Dunno, maybe it
>> would be wise not to escape the bracket, but other characters should
>> be made escapable w/o a problem.
>
> Fixing escape handling and range handling should fix those.
Yep.
>> P.S. all the details obtained from fnmatch()'s description in The
>> Single Unix Specification V3 2004 issue 6.
>> P.P.S. of course there's a ton of what DJGPP's fnmatch() doesn't
>> support, but the above things are pretty basic and it would be nice
>> to have them handled properly, unless I overlook some major
>> DOS-related issue for which it would be desirable to deviate from
>> the spec.
>
> Notice that escapes aren't handled in ranges; should they be?
No, they shouldn't. That's what the spec says. Also, if FNM_PATHNAME is set,
slashes in ranges must not match slashes in the name, but this check is
there already.
> Should escaped control characters be allowed?
They shouldn't because the spec says that when escaping is enabled back
slash followed by a char is that char. So, if you mean \n, \r, \t with their
C meaning - those aren't possible because there already exist another rule
for them. However, I don't think there's any harm in treating a single back
slash at the end of the pattern as nul char when escaping is on. I'd
consider this a programmatical error anyway.
> Shouldn't all \ use in paths be conditional on FNM_NOESCAPE?
Well, here's a twist... Back slashes (\) aren't normally subdirectory/file
name separators. Normally, the forward slash (/) serves the role of such a
separator and the backward slash(\) is used for escaping. That's what SUS
has. In DJGPP because of DOS conventions an attempt was made to make it
possible to use both types of slashes as name separators. So, this gives in
DJGPP 2 functions to the back slash (\): the separator and escape char and
those have to be distinguished appropriately. That's why I commented on the
existence of 3 possible options for a slash following an asterisk.
> I'll need to checkout my SUS.
Sure.
Alex
- Raw text -