sed-devel
[Top][All Lists]
Advanced

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

Re[2]: Command to terminate current stream processing


From: Konstantin Andreev
Subject: Re[2]: Command to terminate current stream processing
Date: Wed, 10 Apr 2019 12:26:53 +0300
User-agent: Mozilla/5.0 (X11; SunOS i86pc; rv:31.0) Gecko/20100101 Thunderbird/31.6.0

Hello,

Assaf Gordon, 09 April 2019 18:14 MSK:

If I understand correctly, the option "-s" has evolved as a side effect of "-i" 
option, and, as such, ...

I do not know if "-s/--separate" evolved as a side-effect of "-i" - it works 
independently of "-i" (as in your examples above). It was added sometime between sed 3.02 and sed 
3.95 (circa 1999-2002), I do no have exact details about it.

That is rather transparent story:

    * "-i" was motivated by perl "-i" (NEWS, Sed 3.95)
    * "-i" has forced the multi-stream semantic
    * having multi-stream semantic, it was so naturally to make a step ahead and to 
support multi-stream w/o "-i"

Changelog records support this deduction:

    | 2002-10-08  Paolo Bonzini
    |         *** Version 3.95 released
    | ...
    | 2002-04-23  Paolo Bonzini
    |         * src/sed.c (usage, main): parse -s
    | ...
    | 2001-09-25  Paolo Bonzini
    |         * sed/main.c (usage, main): parse -i.

It is important to realize (and perhaps we should document it better), that 
"-s" only affects address matching. It does not affect commands at all.

That's not correct. sed also clears hold space between streams.

Looking wider, sed reinitializes internal state so, that each stream could be viewed as processed 
in a standalone sed run. This is mandated by "-i", and so applies to "-s".


While sed has no such built-in command, it is easy to achieve this using the 
following sequence, which consumes and discards all input until ...

Sure, I can consume and discard the input, and that is what I have already been 
doing for no other way.

But the whole point of "q/Q" is to NOT consume that input. E.g. on large one

    | $ grep ... | head

may be slow and painful, whereas

    | $ sed -n '/.../{p;q}'

is a way better, and is what I use routinely.

Unfortunately, this approach fails to work in multi-stream mode.

It seems to be overlooked when implementing multi-stream, and, indeed, it was 
very easy to overlook.

But new command (a la "awk's nextfile") could make multi-stream mode more 
complete.

Regards,
Konstantin Andreev.


Konstantin Andreev, 09 April 2019 10:00 MSK:

sed has convenient commands "q" and "Q" that allow to break stream processing, 
if you are not interested in the stream any more. E.g., looking for C header inclusion guard may be

| $ sed -n '/^#ifndef\>/{p;q}' path/to/some.h

Let notice how "q/Q" interact with "-s" (multiple stream processing) option.

If I understand correctly, the option "-s" has evolved as a side effect of "-i" 
option, and, as such, is assumed to work as shortcut that turns iterators like

| $ for j in A B C; do sed SCRIPT $j; done

into the

| $ sed -s SCRIPT A B C

However, "-s" does not work this way if SCRIPT encounters q/Q command: sed just quits 
without processing further streams. Formally correct and agreed with documentation, this breaks 
"-s" option idea.

I believe this is because in past times, when sed was able to process only one stream at one run, 
"terminate stream" and "terminate sed" were the same, and documentation for 
"q/Q" didn't care about the difference.

Anyway, the action of "q/Q" in multi-stream environment is now beyond changing.

But, ... may we introduce a new command, that behaves identically to "q" in a 
single-stream environment, but just breaks current stream processing in a multi-stream 
environment?



reply via email to

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