I think we were still waiting for Glenn's reply that he was satisfied.
We still have not received a +1 from another member.
Glenn, are you satisfied with responses to your concerns?
Alternatively, at this point, a response from any other member would work.
- Garrett
On 03/17/10 09:10 AM, ????? ???????????? wrote:
> Is this case now approved?
>
> Olga
>
> 2010/3/5 ????? ????????????<olga.kryzhanovska at gmail.com>:
>
>> 2010/3/2 ????? ????????????<olga.kryzhanovska at gmail.com>:
>>
>>> On Tue, Mar 2, 2010 at 10:44 PM, Glenn Skinner<glenn.skinner at covad.net>
>>> wrote:
>>>
>>>> On Mar 2, 2010, at 12:55 PM, Garrett D'Amore - sun microsystems wrote:
>>>>
>>>>
>>>>> This project is an amendment to the Korn Shell 93 Integration project
>>>>> (PSARC/2006/550 and PSARC/2007/035, PSARC/2008/094, PSARC/2008/344
>>>>> and PSARC/2008/589) specifying the following additional
>>>>> interfaces:
>>>>> Addition of /usr/bin/xgrep
>>>>>
>>>>> Bug/RFE Number(s):
>>>>>
>>>>> 6929154 RFE: Add /usr/bin/xgrep (Augmented regular expressions
>>>>> (conjunction, negation.))
>>>>>
>>>>>
>>>>> Interface Stability Description
>>>>> --------- --------- -----------
>>>>> /usr/bin/xgrep Committed xgrep command
>>>>> ksh93 'xgrep' built in Committed xgrep command
>>>>>
>>>> Before I give this case my +1, I have some questions:
>>>>
>>>> The case's specification should define the syntax of the regular
>>>> expressions
>>>> the utility accepts. I suspect that the variants requested by the -E, -F,
>>>> -G, and -P flags can be handled with references to the corresponding man
>>>> pages. But what is the specification for -X mode REs (including the
>>>> semantics of alternation and conjunction)?
>>>>
>>> -X is like POSIX grep -E (egrep) but adds& as AND operator and ! as
>>> NOT operator.
>>>
>>>
>>>> What is the difference between lenient and strict pattern interpretation?
>>>>
>>> Strict will print syntax errors if the pattern does not match the
>>> standard exactly. I leave the exact explanation to Glenn Fowler.
>>>
>> Glenn's replied this:
>> --------------------------------
>> -O, --lenient sets the regcomp(3) REG_LENIENT flag
>> in general if REG_LENIENT is on then certain constructs marked
>> "unspecified" in the standard will be accepted, otherwise they
>> may produce regcomp(3) errors
>>
>> e.g.
>>
>> invalid \char escape
>>
>> grep -S '\#'<<<'#'
>>
>> invalid [...] range endpoint
>>
>> grep -S '[a-q-z]'<<<'a'
>>
>> the intention (theory) is that RE's that make it through -S, --strict
>> will make it through all conformant implementations
>>
>> as counterexamples roll in I tweak libast/reg*.c to make pratice match theory
>> --------------------------------
>>
>> 'lenient' mode by default may be an option (i.e. look at Garrett
>> D'Amore proposal for moving /usr/xpg4/bin to /usr/bin, AST grep would
>> keep strong backwards compatibility sans the dreaded i18n bugs in the
>> current /usr/bin/grep) if we replace /usr/bin/grep and friends with
>> this grep implementation and use 'strict' mode for /usr/xpg4/bin/grep.
>>
>> Olga
>> --
>> , _ _ ,
>> { \/`o;====- Olga Kryzhanovska -====;o`\/ }
>> .----'-/`-/ olga.kryzhanovska at gmail.com \-`\-'----.
>> `'-..-| / Solaris/BSD//C/C++ programmer \ |-..-'`
>> /\/\ /\/\
>> `--` `--`
>>
>>
>
>
>
