Re: [9fans] Re: echo -n

Re: [9fans] Re: echo -n

[Fco. J. Ballesteros]

:  I think Plan 9 got it completely right. Being able to push a 0-byte
:  write through the kernel is mighty handy. I got quite annoyed with
:  Unix at various points over the years as I watched "optimizations"
:  gobble up my attempts to get a 0 byte write through the kernel.

Do you remember why you wanted to push a 0-byte write?

thanks

Re: [9fans] Re: echo -n

[Dave Lukes]

My .25¢:
    echo -n
does precisely nothing,
so if you want that effect as an rc command, then why not use, for example:
     . /dev/null
instead?

>  Do you remember why you wanted to push a 0-byte write?

How else can you write tapemarks on a half-inch magtape?

Also, "push a 0-byte write" is the wrong way to think about it:
it's "send a 0-length chunk".
In the case of boundaryless media, it's nugatory; In the case of 
boundaryful media, it's useful.

To be honest, I don't care if no-one can think of an application for it.
To me it makes perfect sense, whereas the alternative doesn't:
1) write boundary preservation is definitely useful, and I've heard 
no-one say otherwise.
   Therefore you have to chose to either refuse or ignore 0-length 
records (which?) as a special case
   or you do as is done now and treat them like any other chunk.

2) it's impossible to reassemble write boundaries if they're lost:
   the converse is untrue.
   i.e. you can simulate a boundaryless system easily with a boundaryful 
system,
   but not vice-versa.

To me, either of the above is sufficient reason to leave things as they are.

DaveL

Re: [9fans] Re: echo -n

[ron minnich]

On 11/21/06, Fco. J. Ballesteros <nemo@lsub.org> wrote:
> :  I think Plan 9 got it completely right. Being able to push a 0-byte
> :  write through the kernel is mighty handy. I got quite annoyed with
> :  Unix at various points over the years as I watched "optimizations"
> :  gobble up my attempts to get a 0 byte write through the kernel.
>
> Do you remember why you wanted to push a 0-byte write?


it's usually io or networking.

many of the wacky networks I have dealt with have at times needed a
0-byte write; we got the effect via ioctl, since the kernel gobbled up
0-byte writes, the kernel of course knowing much better than you what
you were trying to do, e.g. Linux.

there is of course the need to write a blank punch card with a 0-byte
write, assuming you can find a card punch. And as david mentioned, in
a real case, tape marks.

but, seriously, it's the general issue that you need to tell something
(program, io device, network, whatever) that you don't have anything
to say, which is not the same as saying nothing.

ron

Re: [9fans] Re: echo -n

[erik quanstrom]

of course it goes without saying that an honorable fellow like
yourself wouldn't be appropriating punch cards that way.

;-)
- erik

On Tue Nov 21 10:38:17 EST 2006, rminnich@gmail.com wrote:
> there is of course the need to write a blank punch card with a 0-byte
> write, assuming you can find a card punch. And as david mentioned, in
> a real case, tape marks.

Re: [9fans] Re: echo -n

[Brantley Coile]

> it's usually io or networking.

like runing wc on a remote machine.  You have
to send an end-of-file to wc's input without
taking down the connection.  Otherwise you never
see the counts.

Re: [9fans] Re: echo -n

[Bakul Shah]

> > :  I think Plan 9 got it completely right. Being able to push a 0-byte
> > :  write through the kernel is mighty handy. I got quite annoyed with
> > :  Unix at various points over the years as I watched "optimizations"
> > :  gobble up my attempts to get a 0 byte write through the kernel.

Reminds me of OSes where you couldn't have a 0 length file.
Their designers couldn't imagine why anyone would perform
such a despicable act.

> but, seriously, it's the general issue that you need to tell something
> (program, io device, network, whatever) that you don't have anything
> to say, which is not the same as saying nothing.

I am waiting for someone to write a book with the title
"zero one two...0xffffffff: Facts and Explorations of Computer Science".

Re: [9fans] Re: echo -n

[Lyndon Nerenberg]

On Nov 21, 2006, at 1:01 AM, Fco. J. Ballesteros wrote:

> Do you remember why you wanted to push a 0-byte write?

Look at what FTP has to do with out-of-band messages to abort a
transfer.

Re: [9fans] v9fs mounting in linux

[erik quanstrom]

i use this in my /etc/fstab

/tmp/ns.quanstro.:0/acme	/home/quanstro/9/acme	9p	uid=1000,user,uname=quanstro,proto=unix,noauto	0 0
/tmp/ns.quanstro.:0/upasfs	/home/quanstro/9/upasfs	9p	uid=1000,user,uname=quanstro,proto=unix,noauto	0 0
/tmp/ns.quanstro.:0/sources	/home/quanstro/9/sources	9p	uid=1000,user,uname=quanstro,proto=unix,noauto	0 0
/tmp/ns.quanstro.:0/tapefs	/home/quanstro/9/tapefs	9p	uid=1000,user,uname=quanstro,proto=unix,noauto	0 0

this allows me to mount without su/sudo.  are you sure the permissions on /mnt/acme  are okay?

- erik

Re: [9fans] v9fs mounting in linux

[Paul Lalonde]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Adding the uid= option got me a mount, but I still fail on write to
any of the files; I can 9p write to (for exampe) acme/1/body, but any
attempt to write to the mounted version (/home/plalonde/mnt/acme/1/
body) give me a
body: rc: can't open: Permission denied

Any clues?

Thanks,
     Paul

On 20-Nov-06, at 11:15 AM, erik quanstrom wrote:

> i use this in my /etc/fstab
>
> /tmp/ns.quanstro.:0/acme	/home/quanstro/9/acme	9p
> uid=1000,user,uname=quanstro,proto=unix,noauto	0 0
> /tmp/ns.quanstro.:0/upasfs	/home/quanstro/9/upasfs	9p
> uid=1000,user,uname=quanstro,proto=unix,noauto	0 0
> /tmp/ns.quanstro.:0/sources	/home/quanstro/9/sources	9p
> uid=1000,user,uname=quanstro,proto=unix,noauto	0 0
> /tmp/ns.quanstro.:0/tapefs	/home/quanstro/9/tapefs	9p
> uid=1000,user,uname=quanstro,proto=unix,noauto	0 0
>
> this allows me to mount without su/sudo.  are you sure the
> permissions on /mnt/acme  are okay?
>
> - erik
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFFYi2ipJeHo/Fbu1wRAtFlAJsGmWT4Gl8ZSatgbL7EdCph5AM2HgCgvtBp
JpXNVE92M4YBVTEX+4mHhp8=
=iVdk
-----END PGP SIGNATURE-----

Re: [9fans] v9fs mounting in linux

[ron minnich]

mount it with debug=255 and look at the error. Or, did dmesg show
anything at all?

ron

[9fans] Re: echo -n

[arisawa]

Thanks all for following to my question.

Just my impression ...
If 0 byte writing is a message other than EOF, then we should have
some mechanism that enables to distinguish between 0 byte read and
true EOF.
However introducing a new mechanism to system call is a great surgery.

Coming back to my original question:
	0 byte write using echo -n
What is intended by this operation?
Let  "ECHO" be another "echo" that does not write 0 byte to stdout.
How to distinguish these two commands?
Using the command in rc script to pipe will make the difference.
Are there any other cases that make difference?

If the difference is only in pipe, then we should consider:
is it a legitimate method to let the other end close the pipe?

Re: [9fans] Re: echo -n

[ron minnich]

This whole discussion has been coming up for years. I can't remember
the first time I saw it but it was definitely over a quarter century
ago. I think at some point we figured the issue was roughly akin to
the difference between the empty string and the null string -- where
EOF is the null string, and 0 bytes of data is the empty string --
which you can't actually distinguish via read. I'm NOT saying this is
exactly it, but I think it provides an analogy and a  way to think
about it.

I think Plan 9 got it completely right. Being able to push a 0-byte
write through the kernel is mighty handy. I got quite annoyed with
Unix at various points over the years as I watched "optimizations"
gobble up my attempts to get a 0 byte write through the kernel.

Score one more for Plan 9 -- it lets you do what you want to do.

I hope people enjoyed this discussion more than the up-arrow thread.

thanks

ron

Re: [9fans] Re: echo -n

[Andrew Lynch]

On 21.11.2006, at 03:32, ron minnich wrote:

> This whole discussion has been coming up for years. I can't remember
> the first time I saw it but it was definitely over a quarter century
> ago. I think at some point we figured the issue was roughly akin to
> the difference between the empty string and the null string -- where
> EOF is the null string, and 0 bytes of data is the empty string --
> which you can't actually distinguish via read. I'm NOT saying this is
> exactly it, but I think it provides an analogy and a  way to think
> about it.


I'm surprised nobody has mentioned Doug McIlroy's "The UNIX and the
Echo"(*) yet.
An amusing fable about the problem of saying nothing vs. not saying
anything.
I believe I saw an expanded version of it somewhere on the web many
years ago.

Andrew.

(*) The UNIX Programming Environment
Brian W. Kernighan & Rob Pike
Prentice-Hall, 1984

Re: Re: [9fans] Re: echo -n

[andrey mirtchovski]

"the parable of glenda and the multitudes"? this is stuck in my head
as the expanded version but i have not been able to find it...

Re: [9fans] Re: echo -n

[Axel Belinfante]

http://9fans.net/archive/2001/09/54 is what you mean, I think.

> "the parable of glenda and the multitudes"? this is stuck in my head
> as the expanded version but i have not been able to find it...

Re: Re: [9fans] Re: echo -n

[andrey mirtchovski]

On 11/21/06, Axel Belinfante <Axel.Belinfante@cs.utwente.nl> wrote:
> http://9fans.net/archive/2001/09/54 is what you mean, I think.
>

thank you!

Re: [9fans] Re: echo -n

[Axel Belinfante]

> > http://9fans.net/archive/2001/09/54 is what you mean, I think.
> >
>
> thank you!

no thanks, it could very well _not_ be what you were looking for -
I realized a few minutes after posting... at least that's when I
recalled something that fitted the description better, but where that is???

Re: [9fans] Re: echo -n

[Skip Tavakkolian]

the BUGS section of echo man page should say something
like "echo -n produces a lot of output on 9fans".

Re: [9fans] Re: echo -n

[dmr]

  > This whole discussion has been coming up for years. I can't remember
  > the first time I saw it but it was definitely over a quarter century
  > ago.

Indeed.  7th edition and earlier did ignore 0-length
writes.  8th edition streams began to transmit them
over pipes (or networks).  I recall there were two
problems associated with this; one I forget, the other
was that nroff (for some input) would sometimes
generate one for no good reason, so
  nroff thing.ms | whatever
would terminate prematurely.  It was simplest to
fix nroff.

	Dennis

Re: [9fans] Re: echo -n

[Lyndon Nerenberg]

On Nov 21, 2006, at 5:32 PM, dmr@plan9.bell-labs.com wrote:

> 8th edition streams began to transmit them
> over pipes (or networks).

Since this thread started I've been nagged by the memory of UUCP's
'e' protocol.  If my brain hasn't completely cached out, 'e' used the
ability of Datakit to preserve 0-length messages as an inband
delimiter, vs. the 't' protocols use of explicit protocol field
length counters.  (Or was it 'x' that used null read/write ops ... ?)

--lyndon

Re: [9fans] Re: echo -n

[Bruce Ellis]

0 is a number ... a fine and useful one.  if you want to ignore echo
then SYSCALL(1) will do exactly what you want.

brucee

On 11/24/06, Lyndon Nerenberg <lyndon@orthanc.ca> wrote:
> On Nov 21, 2006, at 5:32 PM, dmr@plan9.bell-labs.com wrote:
>
> > 8th edition streams began to transmit them
> > over pipes (or networks).
>
> Since this thread started I've been nagged by the memory of UUCP's
> 'e' protocol.  If my brain hasn't completely cached out, 'e' used the
> ability of Datakit to preserve 0-length messages as an inband
> delimiter, vs. the 't' protocols use of explicit protocol field
> length counters.  (Or was it 'x' that used null read/write ops ... ?)
>
> --lyndon
>