* [9fans] v9fs mounting in linux @ 2006-11-20 19:06 Paul Lalonde 2006-11-20 19:15 ` erik quanstrom 0 siblings, 1 reply; 22+ messages in thread From: Paul Lalonde @ 2006-11-20 19:06 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm sorting through mounting 9p services under linux. Trying the example from Russ's swtch.com/v9fs page, I get an error: % sudo mount -t 9p -o proto=unix,name=$USER `namespace`/acme /mnt/acme mount: block device /tmp/ns.plalonde.:0/acme is write-protected, mounting read-only mount: cannot mount block device /tmp/ns.plalonde.:0/acme read-only % I've tried changing the permissions on the acme pipe, to no avail. What am I doing wrong? I do note a couple of differences from Russ' examples: my kernel module (FC6) seems to be called 9p not 9p2000, and the protocol is recognized as 9p not 9P. Thanks, Paul -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFYfyjpJeHo/Fbu1wRAlYfAKC1z0P9LF2a8SJtBlWvF3GOmnbKhACfcobg OaGvgJWSnXimxv+CgmzIp2U= =tbjt -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [9fans] v9fs mounting in linux 2006-11-20 19:06 [9fans] v9fs mounting in linux Paul Lalonde @ 2006-11-20 19:15 ` erik quanstrom 2006-11-20 22:35 ` Paul Lalonde 0 siblings, 1 reply; 22+ messages in thread From: erik quanstrom @ 2006-11-20 19:15 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [9fans] v9fs mounting in linux 2006-11-20 19:15 ` erik quanstrom @ 2006-11-20 22:35 ` Paul Lalonde 2006-11-21 0:27 ` ron minnich 0 siblings, 1 reply; 22+ messages in thread From: Paul Lalonde @ 2006-11-20 22:35 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs -----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----- ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [9fans] v9fs mounting in linux 2006-11-20 22:35 ` Paul Lalonde @ 2006-11-21 0:27 ` ron minnich 2006-11-21 1:16 ` Paul Lalonde 2006-11-21 1:23 ` [9fans] Re: echo -n arisawa 0 siblings, 2 replies; 22+ messages in thread From: ron minnich @ 2006-11-21 0:27 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs mount it with debug=255 and look at the error. Or, did dmesg show anything at all? ron ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [9fans] v9fs mounting in linux 2006-11-21 0:27 ` ron minnich @ 2006-11-21 1:16 ` Paul Lalonde 2006-11-21 2:36 ` ron minnich 2006-11-21 1:23 ` [9fans] Re: echo -n arisawa 1 sibling, 1 reply; 22+ messages in thread From: Paul Lalonde @ 2006-11-21 1:16 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1.1: Type: text/plain, Size: 306 bytes --] Ah! A debug option. Handy. But I don't see anything that jumps out and says "error" to me in the dump. I've attached it. This is from doing: echo "foo" > mnt/acme/new/body The new window appeared, as expected, but no body text made it in, and the Permission denied came with the write. [-- Attachment #1.2: foo --] [-- Type: application/octet-stream, Size: 7066 bytes --] -- v9fs_poll_mux (32005): mux ddd39a00 can write -- v9fs_poll_proc (32005): sleeping... -- v9fs_poll_mux (32005): mux ddd39a00 can write -- v9fs_poll_proc (32005): sleeping... -- v9fs_poll_mux (32005): mux ddd39a00 can write -- v9fs_poll_proc (32005): sleeping... -- v9fs_vfs_lookup (31275): dir: def31410 dentry: (new) c7ce3ef8 nameidata: c7050f34 -- v9fs_fid_lookup (31275): dentry: / (c7ce3aec) -- v9fs_t_walk (31275): fid 0 newfid 1 wname 'new' -- v9fs_send_request (31275): mux ddd39a00 task c5e1b200 tcall c4ce8600 id 110 -- v9fs_write_work (31227): mux ddd39a00 pos 0 size 22 -- v9fs_write_work (31227): mux ddd39a00 sent 22 bytes -- v9fs_poll_mux (32005): mux ddd39a00 can write -- v9fs_poll_proc (32005): sleeping... -- v9fs_poll_mux (32005): mux ddd39a00 can read -- v9fs_poll_mux (32005): schedule read work mux ddd39a00 -- v9fs_poll_mux (32005): mux ddd39a00 can write -- v9fs_poll_proc (32005): sleeping... -- v9fs_read_work (31227): start mux ddd39a00 pos 0 -- v9fs_read_work (31227): mux ddd39a00 got 22 bytes -- v9fs_deserialize_fcall (31227): size 22 id 111 tag 0 -- v9fs_read_work (31227): mux ddd39a00 fcall id 111 tag 0 -- v9fs_mux_rpc_cb (31227): req d13bea20 r c7050d20 -- v9fs_t_stat (31275): fid 1 -- v9fs_send_request (31275): mux ddd39a00 task c5e1b200 tcall c4ce8600 id 124 -- v9fs_write_work (31227): mux ddd39a00 pos 0 size 11 -- v9fs_write_work (31227): mux ddd39a00 sent 11 bytes -- v9fs_poll_mux (32005): mux ddd39a00 can write -- v9fs_poll_proc (32005): sleeping... -- v9fs_poll_mux (32005): mux ddd39a00 can read -- v9fs_poll_mux (32005): schedule read work mux ddd39a00 -- v9fs_poll_mux (32005): mux ddd39a00 can write -- v9fs_poll_proc (32005): sleeping... -- v9fs_read_work (31227): start mux ddd39a00 pos 0 -- v9fs_read_work (31227): mux ddd39a00 got 83 bytes -- v9fs_deserialize_fcall (31227): size 83 id 125 tag 0 -- v9fs_read_work (31227): mux ddd39a00 fcall id 125 tag 0 -- v9fs_mux_rpc_cb (31227): req d13bea20 r c7050d24 -- v9fs_get_inode (31275): super block: df556400 mode: 40500 -- v9fs_fid_create (31275): fid create fid 1 -- v9fs_fid_insert (31275): fid 1 (d7b88720) dentry new (c7ce3ef8) -- v9fs_vfs_lookup (31275): dir: d2e45c18 dentry: (body) c91da388 nameidata: c7050f34 -- v9fs_fid_lookup (31275): dentry: new (c7ce3ef8) -- v9fs_t_walk (31275): fid 1 newfid 2 wname 'body' -- v9fs_send_request (31275): mux ddd39a00 task c5e1b200 tcall c4ce8600 id 110 -- v9fs_write_work (31227): mux ddd39a00 pos 0 size 23 -- v9fs_write_work (31227): mux ddd39a00 sent 23 bytes -- v9fs_poll_mux (32005): mux ddd39a00 can write -- v9fs_poll_proc (32005): sleeping... -- v9fs_poll_mux (32005): mux ddd39a00 can read -- v9fs_poll_mux (32005): schedule read work mux ddd39a00 -- v9fs_poll_mux (32005): mux ddd39a00 can write -- v9fs_poll_proc (32005): sleeping... -- v9fs_read_work (31227): start mux ddd39a00 pos 0 -- v9fs_read_work (31227): mux ddd39a00 got 22 bytes -- v9fs_deserialize_fcall (31227): size 22 id 111 tag 0 -- v9fs_read_work (31227): mux ddd39a00 fcall id 111 tag 0 -- v9fs_mux_rpc_cb (31227): req d13bea20 r c7050e1c -- v9fs_t_stat (31275): fid 2 -- v9fs_send_request (31275): mux ddd39a00 task c5e1b200 tcall c4ce8600 id 124 -- v9fs_write_work (31227): mux ddd39a00 pos 0 size 11 -- v9fs_write_work (31227): mux ddd39a00 sent 11 bytes -- v9fs_poll_mux (32005): mux ddd39a00 can write -- v9fs_poll_proc (32005): sleeping... -- v9fs_poll_mux (32005): mux ddd39a00 can read -- v9fs_poll_mux (32005): schedule read work mux ddd39a00 -- v9fs_poll_mux (32005): mux ddd39a00 can write -- v9fs_poll_proc (32005): sleeping... -- v9fs_read_work (31227): start mux ddd39a00 pos 0 -- v9fs_read_work (31227): mux ddd39a00 got 86 bytes -- v9fs_deserialize_fcall (31227): size 86 id 125 tag 0 -- v9fs_read_work (31227): mux ddd39a00 fcall id 125 tag 0 -- v9fs_mux_rpc_cb (31227): req d13bea20 r c7050e20 -- v9fs_get_inode (31275): super block: df556400 mode: 100600 -- v9fs_fid_create (31275): fid create fid 2 -- v9fs_fid_insert (31275): fid 2 (c75815c0) dentry body (c91da388) -- v9fs_fid_lookup (31275): dentry: body (c91da388) -- v9fs_vfs_setattr (31275): -- v9fs_t_wstat (31275): fid 2 -- v9fs_send_request (31275): mux ddd39a00 task c5e1b200 tcall c4ce8600 id 126 -- v9fs_write_work (31227): mux ddd39a00 pos 0 size 62 -- v9fs_write_work (31227): mux ddd39a00 sent 62 bytes -- v9fs_poll_mux (32005): mux ddd39a00 can write -- v9fs_poll_proc (32005): sleeping... -- v9fs_poll_mux (32005): mux ddd39a00 can read -- v9fs_poll_mux (32005): schedule read work mux ddd39a00 -- v9fs_poll_mux (32005): mux ddd39a00 can write -- v9fs_poll_proc (32005): sleeping... -- v9fs_read_work (31227): start mux ddd39a00 pos 0 -- v9fs_read_work (31227): mux ddd39a00 got 26 bytes -- v9fs_deserialize_fcall (31227): size 26 id 107 tag 0 -- v9fs_read_work (31227): mux ddd39a00 fcall id 107 tag 0 -- process_request (31227): Rerror permission denied -- v9fs_mux_rpc_cb (31227): req d13bea20 r c7050d70 -- v9fs_vfs_setattr (31275): wstat error: permission denied -- v9fs_dentry_delete (31275): dentry: body (c91da388) -- v9fs_dentry_release (31275): dentry: body (c91da388) -- v9fs_t_clunk (31275): fid 2 -- v9fs_send_request (31275): mux ddd39a00 task c5e1b200 tcall c4ce8600 id 120 -- v9fs_write_work (31227): mux ddd39a00 pos 0 size 11 -- v9fs_write_work (31227): mux ddd39a00 sent 11 bytes -- v9fs_poll_mux (32005): mux ddd39a00 can write -- v9fs_poll_proc (32005): sleeping... -- v9fs_poll_mux (32005): mux ddd39a00 can read -- v9fs_poll_mux (32005): schedule read work mux ddd39a00 -- v9fs_poll_mux (32005): mux ddd39a00 can write -- v9fs_poll_proc (32005): sleeping... -- v9fs_read_work (31227): start mux ddd39a00 pos 0 -- v9fs_read_work (31227): mux ddd39a00 got 7 bytes -- v9fs_deserialize_fcall (31227): size 7 id 121 tag 0 -- v9fs_read_work (31227): mux ddd39a00 fcall id 121 tag 0 -- v9fs_mux_rpc_cb (31227): req d13bea20 r c7050e24 -- v9fs_dentry_delete (31275): dentry: new (c7ce3ef8) -- v9fs_dentry_release (31275): dentry: new (c7ce3ef8) -- v9fs_t_clunk (31275): fid 1 -- v9fs_send_request (31275): mux ddd39a00 task c5e1b200 tcall c4ce8600 id 120 -- v9fs_write_work (31227): mux ddd39a00 pos 0 size 11 -- v9fs_write_work (31227): mux ddd39a00 sent 11 bytes -- v9fs_poll_mux (32005): mux ddd39a00 can write -- v9fs_poll_proc (32005): sleeping... -- v9fs_poll_mux (32005): mux ddd39a00 can read -- v9fs_poll_mux (32005): schedule read work mux ddd39a00 -- v9fs_poll_mux (32005): mux ddd39a00 can write -- v9fs_poll_proc (32005): sleeping... -- v9fs_read_work (31227): start mux ddd39a00 pos 0 -- v9fs_read_work (31227): mux ddd39a00 got 7 bytes -- v9fs_deserialize_fcall (31227): size 7 id 121 tag 0 -- v9fs_read_work (31227): mux ddd39a00 fcall id 121 tag 0 -- v9fs_mux_rpc_cb (31227): req d13bea20 r c7050e24 -- v9fs_poll_mux (32005): mux ddd39a00 can write -- v9fs_poll_proc (32005): sleeping... -- v9fs_poll_mux (32005): mux ddd39a00 can write -- v9fs_poll_proc (32005): sleeping... [-- Attachment #1.3: Type: text/plain, Size: 188 bytes --] Thanks for your patience, Paul On 20-Nov-06, at 4:27 PM, ron minnich wrote: > mount it with debug=255 and look at the error. Or, did dmesg show > anything at all? > > ron [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 193 bytes --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [9fans] v9fs mounting in linux 2006-11-21 1:16 ` Paul Lalonde @ 2006-11-21 2:36 ` ron minnich 2006-11-21 2:42 ` Paul Lalonde 0 siblings, 1 reply; 22+ messages in thread From: ron minnich @ 2006-11-21 2:36 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Looks to me like the Twstat is failing. I am guessing it is because when you do a '>' the open will try to ftruncate the file. This is a frequent problem with synthetics -- they return errors on Twstat when they might be better off ignoring them. Try a >> instead of a > and let us know. ron ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [9fans] v9fs mounting in linux 2006-11-21 2:36 ` ron minnich @ 2006-11-21 2:42 ` Paul Lalonde 2006-11-21 2:49 ` ron minnich 0 siblings, 1 reply; 22+ messages in thread From: Paul Lalonde @ 2006-11-21 2:42 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bang on! '>>' works fine. Thanks for the help! Paul On 20-Nov-06, at 6:36 PM, ron minnich wrote: > Looks to me like the Twstat is failing. I am guessing it is because > when you do a '>' the open will try to ftruncate the file. This is a > frequent problem with synthetics -- they return errors on Twstat when > they might be better off ignoring them. > > Try a >> instead of a > and let us know. > > ron -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFYmd+pJeHo/Fbu1wRApZ3AKDfZwIlrD4WhhVl9lI9JV07lVMcCQCgs4eG n65QePbnmfR7Uyeiu+wJapY= =zE8z -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [9fans] v9fs mounting in linux 2006-11-21 2:42 ` Paul Lalonde @ 2006-11-21 2:49 ` ron minnich 2006-11-21 3:00 ` erik quanstrom 0 siblings, 1 reply; 22+ messages in thread From: ron minnich @ 2006-11-21 2:49 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 11/20/06, Paul Lalonde <plalonde@telus.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Bang on! '>>' works fine. > so can we change acme to just ignore silly systems that try to truncate things to 0 length (or whatever it was that was failing -- maybe the mtime as well) ron ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [9fans] v9fs mounting in linux 2006-11-21 2:49 ` ron minnich @ 2006-11-21 3:00 ` erik quanstrom 2006-11-21 3:17 ` [9fans] read of eof Michael Baldwin 0 siblings, 1 reply; 22+ messages in thread From: erik quanstrom @ 2006-11-21 3:00 UTC (permalink / raw) To: 9fans i was going to suggest '>>', but it doesn't work on my system. rather than figure it out, i'll just use the real thing. - erik ^ permalink raw reply [flat|nested] 22+ messages in thread
* [9fans] read of eof 2006-11-21 3:00 ` erik quanstrom @ 2006-11-21 3:17 ` Michael Baldwin 2006-11-21 6:38 ` Bruce Ellis 0 siblings, 1 reply; 22+ messages in thread From: Michael Baldwin @ 2006-11-21 3:17 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Obviously, a read of end-of-file should return -42. And if the data is possessed, -666. Seriously, there were two languages that I thought integrated exceptions / failures well enough that you could actually use them all the time pleasantly: Icon and Mesa. System calls (or expressions) would "fail" instead of return in-band values, and the syntactic sugar was light enough on calories that you didn't have the sense that you were dragging out an exception handling harness with whipped cream on top all the time just for one little call. Ah well. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [9fans] read of eof 2006-11-21 3:17 ` [9fans] read of eof Michael Baldwin @ 2006-11-21 6:38 ` Bruce Ellis 0 siblings, 0 replies; 22+ messages in thread From: Bruce Ellis @ 2006-11-21 6:38 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs This is crap - we are talking about delimitered messages. But say what you like, no one listens. brucee On 11/21/06, Michael Baldwin <michael@cibernet.com> wrote: > Obviously, a read of end-of-file should return -42. And if the data > is possessed, -666. > > Seriously, there were two languages that I thought integrated > exceptions / failures well enough that you could actually use them > all the time pleasantly: Icon and Mesa. System calls (or expressions) > would "fail" instead of return in-band values, and the syntactic > sugar was light enough on calories that you didn't have the sense > that you were dragging out an exception handling harness with whipped > cream on top all the time just for one little call. > > Ah well. > > ^ permalink raw reply [flat|nested] 22+ messages in thread
* [9fans] Re: echo -n 2006-11-21 0:27 ` ron minnich 2006-11-21 1:16 ` Paul Lalonde @ 2006-11-21 1:23 ` arisawa 2006-11-21 2:32 ` ron minnich 1 sibling, 1 reply; 22+ messages in thread From: arisawa @ 2006-11-21 1:23 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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? ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [9fans] Re: echo -n 2006-11-21 1:23 ` [9fans] Re: echo -n arisawa @ 2006-11-21 2:32 ` ron minnich 2006-11-21 17:36 ` Andrew Lynch 2006-11-22 1:32 ` dmr 0 siblings, 2 replies; 22+ messages in thread From: ron minnich @ 2006-11-21 2:32 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [9fans] Re: echo -n 2006-11-21 2:32 ` ron minnich @ 2006-11-21 17:36 ` Andrew Lynch 2006-11-21 17:35 ` andrey mirtchovski 2006-11-22 1:32 ` dmr 1 sibling, 1 reply; 22+ messages in thread From: Andrew Lynch @ 2006-11-21 17:36 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Re: [9fans] Re: echo -n 2006-11-21 17:36 ` Andrew Lynch @ 2006-11-21 17:35 ` andrey mirtchovski 2006-11-21 18:13 ` Axel Belinfante 0 siblings, 1 reply; 22+ messages in thread From: andrey mirtchovski @ 2006-11-21 17:35 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs "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... ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [9fans] Re: echo -n 2006-11-21 17:35 ` andrey mirtchovski @ 2006-11-21 18:13 ` Axel Belinfante 2006-11-21 18:23 ` andrey mirtchovski 0 siblings, 1 reply; 22+ messages in thread From: Axel Belinfante @ 2006-11-21 18:13 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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... ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Re: [9fans] Re: echo -n 2006-11-21 18:13 ` Axel Belinfante @ 2006-11-21 18:23 ` andrey mirtchovski 2006-11-21 18:31 ` Axel Belinfante 0 siblings, 1 reply; 22+ messages in thread From: andrey mirtchovski @ 2006-11-21 18:23 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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! ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [9fans] Re: echo -n 2006-11-21 18:23 ` andrey mirtchovski @ 2006-11-21 18:31 ` Axel Belinfante 2006-11-21 18:53 ` Skip Tavakkolian 0 siblings, 1 reply; 22+ messages in thread From: Axel Belinfante @ 2006-11-21 18:31 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > > 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??? ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [9fans] Re: echo -n 2006-11-21 18:31 ` Axel Belinfante @ 2006-11-21 18:53 ` Skip Tavakkolian 0 siblings, 0 replies; 22+ messages in thread From: Skip Tavakkolian @ 2006-11-21 18:53 UTC (permalink / raw) To: 9fans the BUGS section of echo man page should say something like "echo -n produces a lot of output on 9fans". ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [9fans] Re: echo -n 2006-11-21 2:32 ` ron minnich 2006-11-21 17:36 ` Andrew Lynch @ 2006-11-22 1:32 ` dmr 2006-11-24 4:17 ` Lyndon Nerenberg 1 sibling, 1 reply; 22+ messages in thread From: dmr @ 2006-11-22 1:32 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [9fans] Re: echo -n 2006-11-22 1:32 ` dmr @ 2006-11-24 4:17 ` Lyndon Nerenberg 2006-11-24 16:24 ` Bruce Ellis 0 siblings, 1 reply; 22+ messages in thread From: Lyndon Nerenberg @ 2006-11-24 4:17 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [9fans] Re: echo -n 2006-11-24 4:17 ` Lyndon Nerenberg @ 2006-11-24 16:24 ` Bruce Ellis 0 siblings, 0 replies; 22+ messages in thread From: Bruce Ellis @ 2006-11-24 16:24 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 > ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2006-11-24 16:24 UTC | newest] Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-11-20 19:06 [9fans] v9fs mounting in linux Paul Lalonde 2006-11-20 19:15 ` erik quanstrom 2006-11-20 22:35 ` Paul Lalonde 2006-11-21 0:27 ` ron minnich 2006-11-21 1:16 ` Paul Lalonde 2006-11-21 2:36 ` ron minnich 2006-11-21 2:42 ` Paul Lalonde 2006-11-21 2:49 ` ron minnich 2006-11-21 3:00 ` erik quanstrom 2006-11-21 3:17 ` [9fans] read of eof Michael Baldwin 2006-11-21 6:38 ` Bruce Ellis 2006-11-21 1:23 ` [9fans] Re: echo -n arisawa 2006-11-21 2:32 ` ron minnich 2006-11-21 17:36 ` Andrew Lynch 2006-11-21 17:35 ` andrey mirtchovski 2006-11-21 18:13 ` Axel Belinfante 2006-11-21 18:23 ` andrey mirtchovski 2006-11-21 18:31 ` Axel Belinfante 2006-11-21 18:53 ` Skip Tavakkolian 2006-11-22 1:32 ` dmr 2006-11-24 4:17 ` Lyndon Nerenberg 2006-11-24 16:24 ` Bruce Ellis
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).