bug#20542: Differences between q and Q

[Daniel Goldman]

On 5/11/2015 1:07 AM, Paolo Bonzini wrote:
> Interesting.  I would have thought that "d" suppresses the scheduled
> text and "D" doesn't.  But I was remembering wrong.
>
> In retrospect, "Q" should then _not_ have suppressed the scheduled text.
>   The idea of "Q" was basically "same as d, but quit instead of starting
> the next cycle".  I guess horses are out here, or do you think that "Q"
> should be fixed?
>
> Paolo

When Anders Granlund wrote me, I also remembered some things wrong. But 
I think I was remembering things the way that made sense to me.

--------- Should Q suppress scheduled output?

One could argue that Q means "Bail out immediately". That is what it 
does right now, including suppressing scheduled output.

Or one could argue that the decision to schedule output was already made 
and should be honored.

If Q was indeed modeled after d, then that is a good reason not to 
suppress scheduled output, assuming that d works "correctly".

--------- Does d work correctly?

The original paper by Lee McMahon said - The d function deletes from the 
file (does not write to the output) all those lines matched by  its 
address(es). It also has the side effect that no further commands are 
attempted on the corpse of a deleted line; as soon as the d function is 
executed, a new line is read from the input, and the list of  editing 
commands is re-started from the beginning on the new line.

Read literally, "as soon as the d function is executed, a new line is 
read from the input" argues that d should suppress scheduled output. 
There is no room in that statement for scheduled output to be printed.

On the other hand, I kind of doubt that Lee McMahon had a grand scheme 
for everything, had everything planned out.

--------- Maybe i should be scheduled?

I always thought of i and a being closely related. But i does not 
schedule output, so is not that close.

Again from the McMahon paper - The i function  behaves identically to 
the a  function, except  that <text> is written to the output before the 
matched line.  All other comments about the a  function apply to the i 
function as well.

Well, "identically" and "all other comments apply" suggest to me that i 
should also schedule output for later. If I was designing the language, 
that's how I would do it. Currently, we have:

$ echo y | sed -e ix -e p
x
y
y

So currently, i prints immediately, just like the GNU sed manual says. 
But I think it should be like this:

$ echo y | sed -e ix -e p
y
x
y

The proposed alternate would have i schedule to print before AutoPrint 
("before the matched line"), analogous to a, and in accord with what was 
originally written by McMahon.

------------------- My opinions

I think scheduled output should always get printed. So I think Q should 
be "fixed" so that scheduled output is printed.

I think d should stay as it is (print scheduled output), regardless of 
possibly mistaken wording by Lee McMahon.

I think i should schedule (not immediately print) output, analogous to 
a, and in accord with how the language was apparently intended.

--------------

I have never used Q and probably never will. I do use the i command. But 
the suggested change to schedule i output would probably never affect 
me, due to the utilitarian way I normally use sed.

In other words, if things stayed as they are right now, as the horses 
are already out there, I would be fine with that. I wouldn't want to 
break anybody's incredibly imaginative existing sed script.

Thanks,
Daniel