(Readers beware: there is approximately zero useful information in this
particular email. It's just clarifying what I meant in the previous one.)
Charles Levert wrote:
* On Sunday 2005-11-13 at 23:46:09 +0000, Julian Foad wrote:
Charles Levert wrote:
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. [...]
Yikes. There's some kind of logic to that line of reasoning, but it
strikes me as very arcane. I have never thought of wanting such output. I
can't imagine any meaningful use for it. Sorry. That logic involves Grep
doing two different kinds of search (conceptually, not just
implementation-wise which it currently does anyway).
Implementation-wise, it's no more, no less than
what -o introduced to begin with, -v or no -v.
My parenthesis was intended to emphasise that I'm concerned about Grep's
conceptual behaviour and don't care about the implementation. (I will care
about the implementation AFTER we have decided what
functionality/concepts/behaviours need to be implemented.)
That effect is much
better and more flexibly obtained with two successive Greps: "grep -C -v |
grep -o".
But loosing the ability to keep any line prefix
from the first one.
Oh, OK, two successive Greps can't easily do quite everything that you might
want. But then neither can one Grep command. (Sp.: "losing")
I think "-v" and "-o" are mutually exclusive:
-v: "show only the lines that have no matches"
(possibly with a few lines of context)
-o: "show only the matches"
(it would make some kind of logical sense to show possibly a few
_characters_ of context around each match, but nobody has asked for that)
That last thing would introduce more
implementation code. (There _is_ a simple way
to implement it: [...]
I think you're missing the point. When I mention ideas like showing a few
characters of context, I'm not trying to formulate a precise functional
description of a potential new feature, nor suggest that we want such a
feature, so implementation details are completely irrelevant.
In this case I was just trying to illustrate how "-o" can be thought of as a
character-based alternative to the normal or inverse line-based modes, with a
correspondingly character-based interpretation of "context" ("context
characters" instead of "context lines").
This shows that the interaction of "context" with "only-matching" does not have
a single, obvious interpretation: there are many possible designs and none of
them have yet been demonstrated to be useful enough to be worth specifying and
implementing.
Hey, there's another example of keeping it free of unneeded functionality
and future-proof: we don't support context lines with "-o".
Not quite. Previously, we only thought
of considering the non -v cases. For them,
whether or not we say we support context lines
with -o is just rhetoric, because the output
is the same since the context (non-matching)
lines don't provide any matching parts for -o.
No, no: the output is only "the same" (as it would be with context lines
specified) in one particular conceptual design. You're assuming that we have
designed it that way, and I don't think we have designed it much at all; I
think it has just never been discussed sufficiently.
We can easily think of more than one way to implement some sort of context for
"-o". There's the idea you are thinking of here, where "-o" searches for words
in selected lines and their context lines; and you mention a different idea
below. The fact that the idea below is a "very twisted mix" is not the point;
the point is that there ARE different ideas and ways that it could be done. My
point was that, unless we are very sure that one particular way is really
useful and wanted, it is better not to implement any of them.
However, if by "context lines with -o" you rather
meant something like
filename-full context line
filename-full context line
filename:matching part only
filename-full context line
filename-full context line
then that's also a very twisted mix.
If we were to
make "-C" work with "-o" in some arbitrary line-based way now, we'd lock
ourselves out of the possibility of making it show the specified number of
_characters_
I'm not sure what you mean here by line-based
(I meant something like whole lines of context, like you wrote above.)
way, or what you mean next by showing a number
of characters. By number, do you mean an offset
or a count (within a match)?
(I meant "a few characters", the number (count) of them being specified by the
arguments to -A/-B/-C etc. But it doesn't matter.)
Also, which kind of characters is it?
That's completely irrelevant unless and until we ever consider designing such a
feature.
if and when people do start to expect that. (I'd never
thought of that "characters of context" idea until now, and I don't know if
it will ever be wanted, and don't suggest we even consider implementing it,
but it illustrates a point.)
Understood.
Good. That means all the stuff above is irrelevant.
I'm not even sure I would have introduced -o in
the first place, since grep is by tradition one
of the Unix line-oriented tools. We wouldn't
be having this discussion then.
Yes, but I have long wanted a search tool that reports the matched text only.
Maybe that functionality should have been put into a new program instead of
into Grep. On the other hand, I have a grand vision in which Grep is based on
a search algorithm that doesn't know or care about lines or newline characters,
and all the line-based behaviour including the default mode of displaying the
whole line in which a match is found would be implemented on top of that
general algorithm. The "only-matching" mode would be closer to the fundamental
behaviour of the underlying search algorithm.
Come to think of it, I don't care that much
about -o in general. It's more the challenge
of the logical problem that attracted me
towards the implementation of an orthogonal
and unambiguously specified solution. Beauty,
in math as in everything, is very much in the
eye of the beholder. Useful in practice?
Well, logical beauty certainly helps a lot in designing these sorts of tools.
I just don't think this particular way you chose to think of "-o" was the right
logic. ("Right" meaning "gives the most useful set of behaviour combinations".)
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?
Their original purpose, as I mentioned, was to check that Grep doesn't
crash.
Let's just keep them and adjust their expected
output, then. That's the simpler thing to do.
OK.
- Julian
