Hi Scott,
Scott Cheloha wrote on Mon, Dec 03, 2018 at 08:47:23PM -0600:
> This diff makes it an error to invoke sed(1) without any command
> or script.
I'm not convinced this makes anything better for anybody.
For people who do not currently call sed(1) without giving
a script, it makes no difference.
People who currently do call sed(1) without a script (for
example in some obscure corner of some shell script) may
get into trouble.
> In POSIX.1-2008 the sed(1) synopsis changed from this:
>
> sed [-n] script[file...]
> sed [-n][-e script]...[-f script_file]...[file...]
>
> to this:
>
> sed [-n] script [file...]
> sed [-n] -e script [-e script]... [-f script_file]... [file...]
> sed [-n] [-e script]... -f script_file [-f script_file]... [file]
>
> which makes the empty invocation, i.e.
>
> $ sed
> or
>
> $ ... | sed | ...
>
> unambiguously an unrecognized form; you have to specify some sort of
> script, somehow, or the behavior is undefined.
Right. And undefined behaviour (in POSIX) means we are allowed to
define what we want to do, as an extension. If some traditional
behaviour exists, it may be reasonable to stick to that, unless
there are real reasons to change it. Currently, our sed(1) manual
page implicitly already defines our extension: it implicitly says
that sed(1) is a cat(1) by default:
The sed utility reads the specified files, or the standard input if no
files are specified, modifying the input as specified by a list of
commands. The input is then written to the standard output.
[...]
Normally, sed cyclically copies a line of input, not including
its terminating newline character, into a pattern space, (unless
there is something left after a D function), applies all of
the commands with addresses that select that pattern space,
copies the pattern space to the standard output, appending a
newline, and deletes the pattern space.
A list can be empty. When there are no commands, the pattern space
simply gets copied unchanged.
> Yes, the standard was silent regarding the behavior in this case in
> earlier versions, but now that the synopsis doesn't even allow for it
> *and* we claim conformance to the newer standard I think we ought to
> document how our implementation behaves in this case (probably note it
> in STANDARDS) or drop it. I'd like to drop it.
>
> What do other implementations do? FreeBSD/NetBSD/Solaris/illumos sed(1)
> all (like us) descend from the Spinellis rewrite for 4.4BSD and all of
> them have preserved this behavior and left it undocumented.
Seems like a real reason to keep the current behaviour.
> GNU sed and AIX sed error out in this case.
So the GNU looks like the odd wildebeest here. AIX is not terribly
important, i think.
> Aside from it being undocumented, I'd like to drop this because:
>
> 1. The empty invocation is not useful. If you want sed to do
> nothing you can very easily do so explicitly, i.e.
>
> $ sed ""
>
> Allowing the empty invocation just makes more room for user
> error without enhancing the tool.
I consider it logical that, if you can build a list of cammands by
specifying an arbitrary number of -e and an arbitrary number of -f
options, and both numbers can be zero, that both can also be zero
at the same time.
[...]
> 2. Requiring a command is consistent, usage-wise, if you think of
> sed(1) as a successor to grep(1).
I don't think that is a very good analogy. It is clear what it means
to apply an empty list of commands: nothing happens. Is is not
clear what it means to pick lines that match an empty list of patterns.
If anything, "nothing is selected" would seem more logical than
"everything is selected" because how can something match when there
isn't even a pattern? So the analogy doesn't really work.
> grep(1) supports matching the null pattern, i.e.
>
> $ grep ""
The null pattern is not the same as an empty list of patterns.
It is logical what an empty list of commands does, and it reasonable
that an empty command does the same.
Yours,
Ingo
