[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#66434: Solved/Closed: No error but -H GNU extension/default + effect
From: |
Joerg M. Sigle |
Subject: |
bug#66434: Solved/Closed: No error but -H GNU extension/default + effect of HL7 using CR only - Re: bug#66434: grep recently shows the filename with -o , but it, shouldn't. |
Date: |
Tue, 10 Oct 2023 23:11:42 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 |
Gary, thank you very much for your helpful response.
Sorry I failed to see this GNU extension/default and the -H and -h switches
even though I looked :-)
Maybe a hint in the man entry for -o might be good; e.g. "Also see: -h, -H".
In hindsight, I also understand the effect of a peculiarity of HL7 files in
this context:
I was grepping HL7 files. The HL7 standard uses only CR (hex 0D) to separate
HL7 segments.
WITHOUT -o, grep results typically span multiple HL7 segments.
And CR means carriage return, so a filename displayed by grep would immediately
be covered by content from the next segment.
WITH -o and a short search string, however, grep results remain within one HL7
segment.
So NO CR appears in the output. So the filename displayed by grep remains
visible.
This caused my (false) impression that in GNU grep, the -o would also trigger
the -H with it.
And left me sufficiently puzzled to send this error report.
Of course, a closer inspection of grep output without -o could have revealed
this!
I hope that documenting this here might help others avoid the same little trap
:-)
Thanks & kind regards! Joerg