Roland Mainz wrote:
> Stephen Lau wrote:
>> Roland Mainz wrote:
>>> Peter Memishian wrote:
> [snip]
>>> If you do that please please follow the AST/ksh syntax (e.g. it wouldn't
>>> be good to have several variants of the same syntax), e.g. "~(" as
>>> prefix to indicate alternative pattern method, "<name>" as name of the
>>> method (currently supported by libast&&ksh93 are AFAIK "F"/"G"/"E" for
>>> fgrep/grep/egrep-like pattern (which support modifers "i" for
>>> case-insensitive matching and "l" and "r" for left and right anchors),
>>> "S" for shell pattern, "K" for korn shell pattern (both are the same),
>>> "P" for perl regular expressions and AFAIK there are a few undocumented
>>> methods, too ("A" is reversed for AmigaOS-like pattern)) and a closing
>>> ")" before the pattern itself.
>> As meem noted, findunref will be a Python script after we do the SCM
>> Migration tools putback, but we won't be implementing this extended
>> shell pattern matching as part of our project.
>
> A more generic idea... which function does "python" use for shell
> pattern matching ? If the "python" functionality is based on
> |libc::regex()| we could switch it over to use |libast::regex()| instead
> of (and get that functionality "for free"... :-) ) ...
We use fnmatch() from the fnmatch module. I don't know what that uses
underneath. But in any case, if it *did* use libc::regex(), I certainly
wouldn't want to switch it underneath since that would change the
semantics of fnmatch() for all Python programs.
cheers,
steve
--
stephen lau // [EMAIL PROTECTED] | 650.786.0845 | http://whacked.net
opensolaris // solaris kernel development
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
