On Fri, Jun 15, 2012 at 10:59 PM, Josh Hurst <[email protected]> wrote:
> Sending it to ast-users because ast-developers doesn't let me subscribe.
[snip]
> On Fri, Jun 8, 2012 at 5:33 PM, Lionel Cons
> <[email protected]> wrote:
>> On 8 June 2012 16:38, Clark WANG <[email protected]> wrote:
>>> On Fri, Jun 8, 2012 at 10:06 PM, Dan Shelton
>>> <[email protected]> wrote:
>>>> On 30 May 2012 01:31, David Korn <[email protected]> wrote:
>>>>> cc: [email protected] [email protected]
>>>>> [email protected]
>>>>> Subject: Re: Re: Re: [ast-developers] RFE: Extend ksh93 printf %q to
>>>>> accept modifiers
>>>>> --------
>>>>>
>>>>> I have added %(html)q and %(url)q to the next release.
>>>>
>>>> I think there was a misunderstanding for using %(...)q for egrep
>>>
>>> There's not a standard or specification for %(...)q so there's no
>>> misunderstanding here. I personally like the way %(ere)q and
>>> %(pattern)q work. :)
>>>
>>>> expressions and similar things. The goal was to QUOTE strings that
>>>> they retain any all characters in the target format in their literal
>>>> meaning and not to CONVERT them like the current implementation for
>>>> %(ere)q does.
>>>> As an example, %(ere)q should quote special characters like (, ), [,
>>>> ], {, }, \ with a preceding backslash so they are retain their literal
>>>> meaning:
>>>>
>>>> printf '%(ere)q' 'hello(world)'
>>>> hello\(world\)
>>>>
>>>> %(csv)q, %(html)q and %(url)q work as expected but %(pattern)q and
>>>> %(ere)q need to be changed to just quote the values and not convert
>>>> them into something different.
>>>
>>> They're not converted to something different. They're converted to
>>> another form which means the same.
>>
>> Clark, %q means 'quoting', not conversion. So I agree with Dan that
>> from the spirit of naming plain quoting actions belong into %()q while
>> whole conversions into a completely different pattern syntax should
>> fall into something like %()C.
>
> I agree with Lionel on that. Besides, we have %R/%P for that. I like
> the Olga's original proposal because it made it easy to insert file
> names (or other strings) into a extended regular expression pattern
> without worrying that they change the meaning or cause corruptions
> because their characters were not quoted.
> As example: I have two files (from Windows) with the name 'Document
> copy(1).doc' and 'Document copy(2).doc'. If %(ere)q would work as I
> would expect it it would allow to create a OR pattern simply by doing
> a printf "(%(ere)q|%(ere)q)" 'Document copy(1).doc' 'Document
> copy(2).doc' and get the properly quoted '(Document
> copy\(1\)\.doc|Document copy\(2\)\.doc)' from that.
>
> So back to the original proposal from Olga:
> ---------------
> %(egrep)q convert string into a literal accepted plainly by egrep
> (e.g. things like '[', ']', '(', ')' etc. are quoted)
> %(grep)q convert string into a literal accepted plainly by grep (e.g.
> things like '[', ']', etc. are quoted)
> %(agrep)q, %(xgrep)q convert string into a literal accepted plainly by
> grep -X/-A (e.g. things like '[', ']', '(', ')' etc. are quoted)
> ---------------
> Can we get %()q changed that egrep/grep/agrep quote the strings as
> Olga proposed for the next beta, please? IMO this is more practical
> than just having new names for %R/%P
Erm... we can have the cake and eat it too... :-)
My proposal would be likt this:
1. %(foo)q, e.g. operations with a single word ("foo" in this case)
define plain quoting operations to quote the given string to make it's
meaning "literal", e.g. all characters which may be special in the
target syntax are escaped/quoted. These operations do not throw any
errors regardless what's being fed in
2. %(foo2bar)q, e.g. operations with two worlds with a "2" in the
middle define conversion operations (from/to), e.g. from egrep syntax
to shell shell pattern expressions would be "egrep2shellre".
Conversion operations are allowed to trigger errors
David... what do you think ?
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [email protected]
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
_______________________________________________
ast-users mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-users
