Apologies if this gets posted twice. I posted it to some random news server
hours ago but it hasn't shown up, so I'm doing it on groups.google.com now.

What about:

re = /((?@<paths>(\/\w+)+\/)(?@<filenames>\w+),?)+/

m = re.match("/usr/local/bin/ruby,/bin/bash,/sbin/reboot")

m['paths']     # => ["/usr/local/bin/", "/bin/", "/sbin/"]
m['filenames'] # => ["ruby", "bash", "reboot"]

My regexps may be off (didn't test :)), but you get the idea.
Wouldn't that require multiple regexps with scan? This could be
moderately useful, I'd imagine.

- Dan (posting from google because the blackout killed his mail server :( ) 

dblack / superlink.net wrote
> Hi --
> 
> On Fri, 15 Aug 2003, Minero Aoki wrote:
> 
> >   TANAKA Akira suggested a new function, to capture all matchings for
> >   the one expression.  e.g.
> >
> >     m = /(?@<name>\/\w+)+/.match("/usr/local/bin/ruby")
> >     p m['name']   #=> ["/usr", "/local", "/bin", "/ruby"]
> 
> Question:
> 
> Would this also be captured in the numerically indexed submatches?
> (So, in the above, m[1] would still be "/ruby".)
> 
> Comment:
> 
> The first thing I thought was that this looks like an alternative way
> (or very close) of doing this:
> 
>   name = "/usr/local/bin/ruby".scan(/\/\w+/)
> 
> and I still kind of think that :-)  Is there a big advantage to making
> this kind of result-naming a regex extension, rather than just using
> regexes to generate the results and saving/naming the results
> separately (the way #scan does)?