Re: [9fans] echo -n

["Russ Cox" <rsc@swtch.com>]

Notice the wording.  "If you're preserving message boundaries..."

If you want to do away with mid-stream zero-length reads from pipes,
then don't have them preserve message boundaries anymore.
Probably nothing will break.  As I said, it used to be very important,
but it's not as important anymore (as of 9P2000).
However, some programs do depend on writes not getting coalesced;
for example, kfs reads /srv/kfs.cmd and expects one command per read.
It's a two-line change to devpipe.c: change qopen's second argument
from 0 to Qcoalesce.  Try it and see what breaks.

That said, in the absence of any compelling argument to change it,
I am inclined to leave it alone.

Changing devpipe is very different from defining that a zero-length write
system call gets dropped from the kernel (which it sounds like you
are proposing).  That would definitely be a mistake.
Other file servers might still want to preserve message boundaries
or otherwise imbue zero-length writes (or reads) with special meaning.
As Federico pointed out, wikifs does use zero-length writes for
its own purposes; Charles once pointed out that USB does as well;
and in fact even HTTP/1.1 uses (framed) zero-length messages.
In all these cases if you had a pipe to a translator, being able to
send an empty message along that pipe could come in handy.

> Isn't it more clean to let zero bytes mean eof?

Okay.  Let's call a zero-byte message an eof.
If you can read an eof, why can't you write one?

One could view the zero-length message on a pipe as an eof,
and then the question is whether echo -n should send an eof.

Russ