[9fans] echo -n

[9fans] echo -n

[arisawa]

Hello,

I have a question:
echo -n
writes 0 length byte to stdout.
Is this intentional specification?

If it is, what is intended for the specification?

Output to pipe by a rc script such as
echo -n $foo
can close the pipe if $foo is empty.
Therefore we are obliged to write
if(~ $foo ?*)
	echo -n $foo

Kenji Arisawa

Re: [9fans] echo -n

[Martin Neubauer]

* arisawa@ar.aichi-u.ac.jp (arisawa@ar.aichi-u.ac.jp) wrote:
> Hello,
>
> I have a question:
> echo -n
> writes 0 length byte to stdout.
> Is this intentional specification?
>
> If it is, what is intended for the specification?

Hello,

As I see it, echo copies its arguments to stdout, followed by a newline. The
`-n' option suppresses this newline. Without looking at the source, it seems
echo initiates the write, writes the arguments (if any), writes a newline
(if not disabled), and ends the write resulting in a zero-length write for
`echo -n'. It could probably be possible to change echo to only do the write
if there is anything to output, but I'm not aware of any formal
specification of that case. Also, there might be scripts that rely on
exactly that behaviour. Maybe a shell function checking the arguments before
calling echo would be a cleaner solution.

	Martin

Re: [9fans] echo -n

[lucio]

> Maybe a shell function checking the arguments before
> calling echo would be a cleaner solution.

Or a distinct option to /bin/echo?

++L

Re: [9fans] echo -n

[Russ Cox]

> I have a question:
> echo -n
> writes 0 length byte to stdout.
> Is this intentional specification?

Yes.

> If it is, what is intended for the specification?

A zero-length write.

> Output to pipe by a rc script such as
> echo -n $foo
> can close the pipe if $foo is empty.

No, it doesn't close the pipe.  It sends a zero-length message,
causing the reader to get a zero-length message returned from read.
The pipe is still completely usable; the problem is that the reader
interprets this zero return as EOF, as is the convention.

It's too bad that both of these conditions are signaled the same way,
but the pipe is *not* closed.

There are two options available for dealing with this:
change your writer not to write empty messages (as you have),
or change the reader to ignore them.  For the latter, just
ignore a return value of 0 and read again.  If the pipe is
really closed, then after returning 0 three times, read will start
returning -1.

Russ

Re: [9fans] echo -n

[John Stalker]

UNIX variants seem to vary (yes, I know, that's why they are called
variants) in their behaviour.  On FreeBSD and NetBSD echo -n | wc
produces 0 0 0, agreeing with my intuition and the plan9 behaviour.
On Solaris, on the other hand, echo -n | wc produces 1 1 3.
--
John Stalker
School of Mathematics
Trinity College Dublin
tel +353 1 896 1983
fax +353 1 896 2282

Re: [9fans] echo -n

[Dave Lukes]

$ uname -a
SunOS mother 5.6 Generic_105181-35 sun4u sparc SUNW,Ultra-250
$ sh -c 'echo -n | wc'
       1       1       3
$ bash -c 'echo -n | wc'
       0       0       0
$

<snigger/>

DaveL

John Stalker wrote:
> UNIX variants seem to vary (yes, I know, that's why they are called
> variants) in their behaviour.  On FreeBSD and NetBSD echo -n | wc
> produces 0 0 0, agreeing with my intuition and the plan9 behaviour.
> On Solaris, on the other hand, echo -n | wc produces 1 1 3.
>

Re: [9fans] echo -n

[Axel Belinfante]

> UNIX variants seem to vary (yes, I know, that's why they are called
> variants) in their behaviour.  On FreeBSD and NetBSD echo -n | wc
> produces 0 0 0, agreeing with my intuition and the plan9 behaviour.
> On Solaris, on the other hand, echo -n | wc produces 1 1 3.

On my solaris (5.8) I see both behaviours, depending on the shell I use.
The  1 1 3 is produced by /usr/bin/echo.
its man page explains why we get this:

     If  any operand  is  "-n", it will be treated as a string, not
     an option. The following character sequences will  be
     recognized within any of the arguments:

  [...]
           \c    print line without new-line
  [...]

   USAGE
     Portable applications should not use -n (as the first  argu-
     ment) or escape sequences.

;  /usr/bin/echo '\c' |wc
       0       0       0
;


Axel.

Re: [9fans] echo -n

[ron minnich]

On 11/20/06, Axel Belinfante <Axel.Belinfante@cs.utwente.nl> wrote:

> On my solaris (5.8) I see both behaviours, depending on the shell I use.

so much of the OS world nowadays resembles senile dementia.

ron

Re: [9fans] echo -n

[erik quanstrom]

on unix this doesn't matter as much.  on plan 9, write boundaries were supposed to
be respected.

- erik
On Mon Nov 20 10:08:20 EST 2006, Axel.Belinfante@cs.utwente.nl wrote:
> > UNIX variants seem to vary (yes, I know, that's why they are called
> > variants) in their behaviour.  On FreeBSD and NetBSD echo -n | wc
> > produces 0 0 0, agreeing with my intuition and the plan9 behaviour.
> > On Solaris, on the other hand, echo -n | wc produces 1 1 3.

Re: [9fans] echo -n

[Joel Salomon]

> No, [a zero-length write] doesn't close the pipe.  It sends a
> zero-length message, causing the reader to get a zero-length message
> returned from read.  The pipe is still completely usable; the problem
> is that the reader interprets this zero return as EOF, as is the
> convention.
>
> It's too bad that both of these conditions are signaled the same way,
> but the pipe is *not* closed.
>
> There are two options available for dealing with this: change your
> writer not to write empty messages (as you have), or change the reader
> to ignore them.  For the latter, just ignore a return value of 0 and
> read again.  If the pipe is really closed, then after returning 0
> three times, read will start returning -1.

Why is read from a closed pipe not considered an error, though?
	close(fd[0]);
	for(int i=0; i<5; i++){
		n = read(fd[1], buf, 8);
		print("%d: read %ld bytes: %r\n", i, n);
	}
produces:
	0: read 0 bytes:
	1: read 0 bytes:
	2: read 0 bytes:
	3: read -1 bytes: i/o on hungup channel
	4: read -1 bytes: i/o on hungup channel
where I expected errstr to be set on the first read after pipe
closure.  Is there really no way to immediately determine that a
pipe has been closed?  Why would read be so implemented?

--Joel

Re: [9fans] echo -n

[maht]

>> Maybe a shell function checking the arguments before
>> calling echo would be a cleaner solution.
>>
> Or a distinct option to /bin/echo?
>
> ++L
>
why change echo when we have a perfectly cromulent system in place?

fn echo {
    if(~ $1?*)
            /bin/echo -n $1
}

Re: [9fans] echo -n

[Russ Cox]

> Why is read from a closed pipe not considered an error, though?

The same reason that reading from the end of a disk file is not an error.
Try running your program reading /dev/null instead of a pipe.

>         close(fd[0]);
>         for(int i=0; i<5; i++){
>                 n = read(fd[1], buf, 8);
>                 print("%d: read %ld bytes: %r\n", i, n);
>         }
> produces:
>         0: read 0 bytes:
>         1: read 0 bytes:
>         2: read 0 bytes:
>         3: read -1 bytes: i/o on hungup channel
>         4: read -1 bytes: i/o on hungup channel
> where I expected errstr to be set on the first read after pipe
> closure.

Errstr is only set when a system call returns -1.

> Is there really no way to immediately determine that a
> pipe has been closed?  Why would read be so implemented?

It's a clumsy hack to work around exactly this problem.
It's not read in general that is implemented this way,
just the read implementation for pipes and network data files.

The only real solution is to change the interface so that
end-of-file is not signaled by a zero-length read.  But that
convention is far too entrenched to go anywhere any time soon.

Russ

Re: [9fans] echo -n

[Francisco J Ballesteros]

Isn´t it that a write of zero bytes should just not write, instead
of meaning a write of zero bytes?

Or did I miss something?


On 11/20/06, Russ Cox <rsc@swtch.com> wrote:
> > Why is read from a closed pipe not considered an error, though?
>
> The same reason that reading from the end of a disk file is not an error.
> Try running your program reading /dev/null instead of a pipe.
>
> >         close(fd[0]);
> >         for(int i=0; i<5; i++){
> >                 n = read(fd[1], buf, 8);
> >                 print("%d: read %ld bytes: %r\n", i, n);
> >         }
> > produces:
> >         0: read 0 bytes:
> >         1: read 0 bytes:
> >         2: read 0 bytes:
> >         3: read -1 bytes: i/o on hungup channel
> >         4: read -1 bytes: i/o on hungup channel
> > where I expected errstr to be set on the first read after pipe
> > closure.
>
> Errstr is only set when a system call returns -1.
>
> > Is there really no way to immediately determine that a
> > pipe has been closed?  Why would read be so implemented?
>
> It's a clumsy hack to work around exactly this problem.
> It's not read in general that is implemented this way,
> just the read implementation for pipes and network data files.
>
> The only real solution is to change the interface so that
> end-of-file is not signaled by a zero-length read.  But that
> convention is far too entrenched to go anywhere any time soon.
>
> Russ
>
>

Re: [9fans] echo -n

[Joel Salomon]

> > Why is read from a closed pipe not considered an error, though?
>
> The same reason that reading from the end of a disk file is not an error.
> Try running your program reading /dev/null instead of a pipe.

At the end of a disc file, there is the possibility of something being
appended; not so with a closed pipe.  On second thought, down this
road lay the umpteen file types, each with special treatment by the
kernel, under lunix.  On third thought:

> It's not read in general that is implemented this way,
> just the read implementation for pipes and network data files.

…we're partway there already.  ☹

--Joel

Re: [9fans] echo -n

[Joel Salomon]

> > The only real solution is to change the interface so that
> > end-of-file is not signaled by a zero-length read.  But that
> > convention is far too entrenched to go anywhere any time soon.
> 
> Isn´t it that a write of zero bytes should just not write, instead
> of meaning a write of zero bytes?
> 
> Or did I miss something?

That seems to be the definition under the Unix.  From the Single UNIX
Specification, version 2 man page for write():
	If nbyte is 0, write() will return 0 and have no other results
	if the file is a regular file; otherwise, the results are
	unspecified.
SUS3 is more verbose, but seems to have the same intent.  Does Plan 9 use zero-length writes for something that shouldn’t be changed?

--Joel

Re: [9fans] echo -n

[Federico Benavento]

hola,

On 11/20/06, Joel Salomon <chesky@plan9.jp> wrote:
> > > The only real solution is to change the interface so that
> > > end-of-file is not signaled by a zero-length read.  But that
> > > convention is far too entrenched to go anywhere any time soon.
> >
> > Isn´t it that a write of zero bytes should just not write, instead
> > of meaning a write of zero bytes?
> >
> > Or did I miss something?
>
> That seems to be the definition under the Unix.  From the Single UNIX
> Specification, version 2 man page for write():
>         If nbyte is 0, write() will return 0 and have no other results
>         if the file is a regular file; otherwise, the results are
>         unspecified.
> SUS3 is more verbose, but seems to have the same intent.  Does Plan 9 use zero-length writes for something that shouldn't be changed?
>
> --Joel
>
>

I don't think this is the norm, but I've seen this.
you need a zero-length write to tell wikifs that you
finished writing to /mnt/wiki/new, I figured this out the
hard way, I couldn't understand why my script wasn't
working, after a "echo -n" at the end everything worked
just fine.

-- 
Federico G. Benavento

Re: [9fans] echo -n

[Russ Cox]

> That seems to be the definition under the Unix.  From the Single UNIX
> Specification, version 2 man page for write():
>         If nbyte is 0, write() will return 0 and have no other results
>         if the file is a regular file; otherwise, the results are
>         unspecified.
> SUS3 is more verbose, but seems to have the same intent.

You missed the part where it says "if the file is a regular file;
otherwise the results are unspecified."  Pipes are not regular files.

And even if the spec did say what you said it said, Plan 9 is not Unix.
Where Plan 9 and Unix differ, the solution is typically not to make
Plan 9 more like Unix.

This discussion is confusing lots of separate questions.

Q.  Should 9P permit a zero-length response to read?
A.  Yes.

Q.  Should 9P permit a non-zero-length response to read
    after a zero-length response?
A.  Yes.  How else could a file server implement /dev/cons?
    (Think about what happens when the user types ^D at the console.)

Q.  Should 9P permit a zero-length write?
A.  Yes.  I haven't seen a good argument not to.
    Certainly we don't want to make write(1, "", 0) an error.

Q.  Should pipes preserve message boundaries?
A.  Yes.  It is a useful convention, one that Plan 9 used to rely on heavily.
    (One 9P message per write, one 9P message per read,
    no need for inserting length headers in the messages.)
    Perhaps some other application will come along that will need it.

Q.  Should pipes preserve zero-length messages?
A.  Yes.  If you're preserving message boundaries, then it follows
    that zero-length writes on one end should result in zero-length
    reads on the other.

Q.  Should echo -n generate a zero length write?  (the original question)
A.  There are valid arguments for both answers, and once you're in
    the preserving-message-boundaries mindset, probably yes edges out no.
    But even if not, the code is written and just as many people would
    be upset if it were the other way, so it's not worth changing.

Q.  Does echo -n generate a zero length write?
A.  Yes.  Get over it.

Russ

Re: [9fans] echo -n

[Joel Salomon]

> Where Plan 9 and Unix differ, the solution is typically not to make
> Plan 9 more like Unix.

Not advocating change, just asking about design decisions—and
considering myself well answered.

--Joel

Re: [9fans] echo -n

[Francisco J Ballesteros]

> Q.  Should pipes preserve zero-length messages?
> A.  Yes.  If you're preserving message boundaries, then it follows
>     that zero-length writes on one end should result in zero-length
>     reads on the other.

But then, this goes against the convention that zero-length read means
eof. This reminds me of the discussion about white space in file names.
File names may have white space in their names, but that makes
it hard (despite quoting) to program using file names as different tokens.

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

As you say, there are reasons both for doing and not doing it, but how many
users would be really anoyed if write(X,X,0) did just nothing?
How many programs would really have to be changed?

Re: [9fans] echo -n

[Russ Cox]

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

Re: [9fans] echo -n

[Francisco J Ballesteros]

> 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.

You mean, it would be a mistake because there are programs that depend on it,
and there is no big reason to change the current behaviour, right?


I don´t see why that would be a mistake, and you seem to be pretty sure about
that. I´m just try to see why you are so sure.
Writing nothing always seemed weird to me.

thanks

Re: [9fans] echo -n

[Martin Neubauer]

* Francisco J Ballesteros (nemo@lsub.org) wrote:
> >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.
>
> You mean, it would be a mistake because there are programs that depend on
> it,
> and there is no big reason to change the current behaviour, right?
>
>
> I don??t see why that would be a mistake, and you seem to be pretty sure
> about
> that. I??m just try to see why you are so sure.
> Writing nothing always seemed weird to me.

That reminds of an algebra professor of mine ending the recurring debate
whether 0 is or is not a natural natural number (for that time at least):
``Either I have got money, or I haven't got money. That's completely
natural.''

>
> thanks

Re: [9fans] echo -n

[Gorka guardiola]

As I see it, the problem here is that of symmetry and special cases.

A 0 read means eof. The problem is that it also means a 0 sized message on a
pipe.

There are 0 reads which are not eofs because we want to conserve
the symmetry for pipes (n writes mean n reads) in order not add
special cases. But then we have a special case when eof does not mean
the pipe has been closed. Which is also an interpretation, because
eof means end of file, but that means end of pipe or end of session or what?.

So there is a compromise between the special case  of having zero
writes, and thus not eof 0 reads which are not necessary because you
can use a convention of a special character or something, versus
adding a special case on the other side for the closing of pipes.

So whatever you change, you are not better off so we stay put.
Am I reading right or is there something else I am missing?.

It is late and my english is fuzzy. Pardon my french.
--
- curiosity sKilled the cat

Re: [9fans] echo -n

[Francisco J Ballesteros]

Yes, but, what does it mean to write zero bytes?
I know, I know.
But my point is, does it make sense?
If you want a write of something weird to mean something, you might
just use a write of something weird, or a control operation kept appart.


A related question, can we create a file with an empty name?
Is what happens a bug or a feature?


On 11/21/06, Gorka guardiola <paurea@gmail.com> wrote:
> As I see it, the problem here is that of symmetry and special cases.
>
> A 0 read means eof. The problem is that it also means a 0 sized message on a
> pipe.
>
> There are 0 reads which are not eofs because we want to conserve
> the symmetry for pipes (n writes mean n reads) in order not add
> special cases. But then we have a special case when eof does not mean
> the pipe has been closed. Which is also an interpretation, because
> eof means end of file, but that means end of pipe or end of session or what?.
>
> So there is a compromise between the special case  of having zero
> writes, and thus not eof 0 reads which are not necessary because you
> can use a convention of a special character or something, versus
> adding a special case on the other side for the closing of pipes.
>
> So whatever you change, you are not better off so we stay put.
> Am I reading right or is there something else I am missing?.
>
> It is late and my english is fuzzy. Pardon my french.
> --
> - curiosity sKilled the cat
>
>

Re: [9fans] echo -n

[Gorka guardiola]

On 11/21/06, Francisco J Ballesteros <nemo@lsub.org> wrote:
> Yes, but, what does it mean to write zero bytes?
> I know, I know.
> But my point is, does it make sense?

I am not particularly disturbed by a 0 write meaning "send
an eof" as Russ said, or the idea of an empty message,
which does not necessarily mean the pipe is closed. It is just a
matter of conventions.

> If you want a write of something weird to mean something, you might
> just use a write of something weird, or a control operation kept appart.

Yes, I agree with you, you can send a special character or message. I
do not think zero sized messages are impossible to survive without
except...

... what about a network connection/files?. I think that may be a better case
for or against zero writes.  Because a network connections should not
be different from pipes, should they?. How do you send (or receive) an
empty datagram?. Does it make sense?. Do other os's do it? because we
have to cope with it in that case too.

>
> A related question, can we create a file with an empty name?
> Is what happens a bug or a feature?
>

Dunno, is it really related?. If you mean
an empty string, that should be ok shouldn't it?. You should be able
to manipulate a file with name '\0' without problem I guess. I haven't
tried or read the code dealing with this though, to answer the question.
--
- curiosity sKilled the cat

Re: [9fans] echo -n

[lucio]

> But then, this goes against the convention that zero-length read means
> eof. This reminds me of the discussion about white space in file names.
> File names may have white space in their names, but that makes
> it hard (despite quoting) to program using file names as different tokens.

It seems to me, with Joel's rider that this may be only of academic
value, that we make a strange exception for write(X, "\4", 1) to
/dev/cons and we screw up a whole lot of logic in the process.

++L