[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?