Bug 57911 - fnmatch ("[[:alpha:]]","x", FNM_PATHNAME) returns FNM_NOMATCH
Summary: fnmatch ("[[:alpha:]]","x", FNM_PATHNAME) returns FNM_NOMATCH
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: standards (show other bugs)
Version: 4.8-RELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-standards (Nobody)
Depends on:
Reported: 2003-10-12 21:10 UTC by David Gardner
Modified: 2018-05-28 19:46 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description David Gardner 2003-10-12 21:10:23 UTC

The fnmatch function doesn't seem to like any of the character classes that are listed in the re_format man page. I ssh'ed to a linux box to check this and the character classes behaved the way I expected them to.


fnmatch seems to like the expression "[A-Za-z]" which is equivelent to "[[:alpha:]]".

#include <iostream>
#include <fnmatch.h>
void main () {  
  int result = fnmatch ("[[:alpha:]]","x", FNM_PATHNAME);
  if (result == FNM_NOMATCH)
    cout << "failed" << endl;
    cout << "passed" << endl;
Comment 1 Tim Robbins freebsd_committer 2004-07-18 07:57:01 UTC
State Changed
From-To: open->analyzed

I agree that this behaviour is incorrect and have documented it in the 
fnmatch(3) manual page.
Comment 2 Tim Robbins freebsd_committer 2004-07-18 07:59:56 UTC
Responsible Changed
From-To: freebsd-standards->tjr

I'll take care of this one.
Comment 3 Mark Linimon freebsd_committer freebsd_triage 2007-03-09 00:26:29 UTC
Responsible Changed
From-To: tjr->freebsd-bugs

tjr has returned his commit bit for safekeeping.
Comment 4 Eitan Adler freebsd_committer freebsd_triage 2012-07-01 17:10:40 UTC
State Changed
From-To: analyzed->open

unowned PRs must not be in analyzed state
Comment 5 Mark Linimon freebsd_committer freebsd_triage 2014-04-20 23:23:27 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-standards

Canonicalize assignment.
Comment 6 Jörg Schilling 2017-08-03 17:12:03 UTC
It is more than [:alpha:]....

it is:
  [: :] character class 
  [= =] equivalence character class 
  [. .] collation symbol 

Given that the bugreport is 14 years old, is there a chance that this will be implemented in a predictable time?

I am asking this because I am currently taking the FreeBSD libc i18n code and integrating it into libc from OpenSolaris (SchilliX) and I would like to get something that could pass the POSIX certification tests.
Comment 7 Jörg Schilling 2017-08-04 16:22:42 UTC
BTW: bin/sh/expand.c implements [:alpha:] but not the equivalence class and not the collation symbol.

It may still help how to implement things...
Comment 8 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:46:16 UTC
batch change:

For bugs that match the following
-  Status Is In progress 
- Untouched since 2018-01-01.
- Affects Base System OR Documentation


Reset to open status.

I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.