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" Regards, Sheri -- ## List details at http://lists.exim.org/mailman/listinfo/pcre-dev
