Re: tests/yesno.sh, kinds of line (matching/non-matching, selected/rejected)

[Charles Levert]

* On Sunday 2005-11-13 at 18:44:57 +0000, Julian Foad wrote:
> CONTEXT LINES AND MAX-COUNT
> 
> Charles Levert wrote:
> > Test #28:  { ../src/grep -F -n -b -m 2 -v -C 1 -o yes; echo "?$?"; sed 
> 
> We'll discuss the interaction between "-v" and "-o" separately.

Test #28 still involves a context line (albeit
here a matching one, since -v), so whatever
decision is made for the other two tests should
equally apply here (regarding -C/-m).

As for -C/-v/-o and the warning issue, I think
we do disagree.  With -o, I see a line-group
(including selected and context lines) as a
pool of _printable_ content, i.e., lines to scan
for -o parts.  Hence, I see no special case or
need for a warning then, and I see the group
separator remaining.   -C/-v/-o means "find all
matching parts in the vicinity of a non-matching
line (or lines) and collect them as a group".


> >They all seem to have this in common: with -m,
> >a rejected line from stdin (regular file) is
> >both printed as context and left as unread (or
> >seeked-back) input for the next process to read:
> >
> >========================================
> >10-90-[J10 no ]/?0/X[J10 no ]/
> >3-20-[C03 yes]/?0/X[C03 yes]/
> >3-25-yes/?0/X[C03 yes]/
> >========================================
> >
> >This opportunity for repeated processing appears
> >to go against the principles behind the design of
> >-m, as detailed in grep's TeXinfo documentation.
> 
> I disagree: I think the documentation says this is done on purpose:
> 
> >`--max-count=NUM'
> >     Stop reading a file after NUM matching lines.  If the input is
> >     standard input from a regular file, and NUM matching lines are
> >     output, `grep' ensures that the standard input is positioned to
> >     just after the last matching line before exiting, regardless of the
> >     presence of trailing context lines.
> 
> "Regardless of the presence..." is perhaps a little unclear, but from 
> observation of the behaviour and from this later text:
> 
> >     When `grep' stops after NUM matching lines, it outputs any
> >     trailing context lines.
> 
> ... I find it means "even when trailing context lines have been printed."

Then I'd like to see an explicit "some context
lines may be processed twice by this combined
-m/while approach", or similar, appear somewhere.

I also would like the original tests to be
collected in a comment when they are corrected,
with an explanation.  Future maintainers, or
we in a few months, may be driven to rehash the
same forgotten questions.


> The kind of use I can envisage for this is, with --max-count=1, to invoke 
> Grep[*] repeatedly on the same input stream, displaying a match (in 
> context) and asking for some user input in response before moving on to the 
> next match. The "example" given in the "info" document is rather poor and 
>  doesn't make its purpose clear but it does this kind of thing.

The only drawback is that someone who wishes
to not have repeated context line has no simple
way to infer that information (a context line's
repeated status).


> * "Grep": the program/utility/functionality/software, one of whose 
> executables is normally called "grep" - sorry if my capitalisation is 
> annoying anybody.

It's ok.

But I must insist on capitali_z_ation!  ;-)


> That means those "4/..." tests are wrong.

Since yesno.sh specializes in exactly this
kind of issues, should we now just remove those
from foad1.sh?  Or do still they do something
for anchors that nothing else does?