[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#20542: Differences between q and Q

From: Daniel Goldman
Subject: bug#20542: Differences between q and Q
Date: Mon, 11 May 2015 15:12:55 -0700
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0

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?


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

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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]