File.fnmatch's behavior


(H.Yamamoto) #1

Hi, rubyists.

I’m now thinking of File.fnmatch’s behavior.
I’ve read [ruby-dev:16555] and agreed the point

“It sounds good to me that FNM_PATHNAME behavior is default (and introduce oposite flag like FNM_SLASHMATCH),
and ‘**/’ is implemented.”

Is this change acceptable?

And current bracket expression’s behavior is similer to ruby’s regular expression and differs from SUSv3.

Current:
File.fnmatch("[a/c]", “a”, FNM_PATHNAME) # => true (ignore ‘/’ in bracket expression)
File.fnmatch("[\]", “\”) # => false (\ is escaping character)
File.fnmatch("[\
]", “*”) # => true

SUSv3:
File.fnmatch("[a/c]", “a”, FNM_PATHNAME) # => false (’/’ has supiority over bracket expression)
File.fnmatch("[a/c]", “[a/c]”, FNM_PATHNAME) # => true (so, ‘[a’ is handled like ordinary character)
File.fnmatch("[\]", “\”) # => true (\ is ordinary character)
File.fnmatch("[\
]", “*”) # => true

Which one is prefered?

Any comments will be appreciated.

Regards,

Yamamoto.


(Gavin Sinclair) #2

Hi, rubyists.

I’m now thinking of File.fnmatch’s behavior.
I’ve read [ruby-dev:16555] and agreed the point

“It sounds good to me that FNM_PATHNAME behavior is default (and
introduce oposite flag like FNM_SLASHMATCH),
and ‘**/’ is implemented.”

Is this change acceptable?

I like it. fnmatch is one of those few methods whose documentation I have
to look up every time I use it. And then it doesn’t do what I want, so I
need to experiment with irb.

Your proposal seems a step in the right direction. I’d like to see some
"real-world" examples, rather than the “a/b” stuff, though.

Cheers,
Gavin


(H.Yamamoto) #3

Thanks, Gavin.

Hi, rubyists.

I’m now thinking of File.fnmatch’s behavior.
I’ve read [ruby-dev:16555] and agreed the point

“It sounds good to me that FNM_PATHNAME behavior is default (and
introduce oposite flag like FNM_SLASHMATCH),
and ‘**/’ is implemented.”

Is this change acceptable?

I like it. fnmatch is one of those few methods whose documentation I have
to look up every time I use it. And then it doesn’t do what I want, so I
need to experiment with irb.

I’m glad to here that.

Your proposal seems a step in the right direction. I’d like to see some
"real-world" examples, rather than the “a/b” stuff, though.

I’ve already written dir.c to replace “ruby-1.9.0(2004-02-23) Rev1.107”.
Maybe this can help you.

Regards,
Yamamoto


(H.Yamamoto) #4

Sorry, I fogot to tell you where it is…

http://www.ccsnet.ne.jp/~ocean/23007/dir.c

Regards,
Yamamoto


(H.Yamamoto) #5

Hi, rubyists.

I implemented fnmatch. I did some change to behavior, so I want to know whether
this is acceptable as File.fnmatch in ruby1.9 or not.

Changed feature is…

  • Followed SUSv3 pattern handling.

  • Undefine FNM_PATHNAME and define oposite flag FNM_SEPMATCH.

  • ‘**/’ is supported when FNM_SEPMATCH is not set.

  • Only ‘/’ is accepted as path separator.

  • Faster ‘*’ expansion.

Still open issue is… [ruby-dev:23029]

  • Should File.fnmatch(’**/test/’, ‘/b/c/test/’) match or not?
  • Should File.fnmatch(’**/test/’, ‘…/test/’) match or not?

C file’s location is

http://www.ccsnet.ne.jp/~ocean/23030/fnmatch.c

Please try it and comment about it.

Regards,

Yamamoto.


(H.Yamamoto) #6

Hi.

**/ is not implemented yet. I’ll implement it soon.

Regard.
Yamamoto