Philip Hazel wrote: > On Fri, 17 Apr 2009, Sheri wrote:
>
>
>>> in = fopen(pathname, "rb");
>>>
>>> ? It won't make any difference in Unix/Linux, but it might in your
>>> environment. I notice that pcretest uses this. Can you try this, please?
>>>
>>> Philip
>>>
>>>
>>>
>> Yes! No more discrepancies.
>>
>
> OK, noted to be changed for the next release, whenever that is.
>
>
>> Suggested enhancement for pcregrep: argument where user can specify the
>> output separator (defaults to "\n" but could be any string, e.g., "\r\n"
>> or "Custom string")
>>
>
> Just to be sure I've got this right: you mean the ability to define a
> string that is used as the line terminator for all output lines?
> Whatever you specify will be used literally, I guess, so there will have
> to be processing of \n and similar escapes somewhere. There is no such
> processing anywhere in pcregrep at present, so it would have to be
> added, unless we tell people to use printf in commands like
>
> pcregrep -O `printf "\r\n"` <whatever...>
>
> but that's a bit cumbersome, don't you think? OTOH, adding a full
> backslash processing function just for this seems a bit heavyweight.
> Hmm.
>
> Philip
>
> If it presupposes the shell would do the printf'ing, I don't think that
would work in the Windows command environment.
Without the custom string, just 3 choices for line terminators mapped to
"\n", "\r\n" or "\r", would be an improvement.
If you felt like making a heavyweight enhancement to pcregrep, you could
invite a format string for the entire match plus the line break. The
string could include escapes and tokens for pcre whole match ($0) and/or
numbered or named substrings (e.g., $1 or $<name>). "Hello $1: $3\r\n"
