Stephen Lau wrote:
> 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.
Erm, aren't these patterm platform-specific anyway (e.g. shell pattern
for Unix/Linux differ from Windows shell pattern etc.) ?
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [EMAIL PROTECTED]
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
