* [9fans] echo -n @ 2006-11-20 8:40 arisawa 2006-11-20 9:45 ` Martin Neubauer 2006-11-20 12:46 ` Russ Cox 0 siblings, 2 replies; 26+ messages in thread From: arisawa @ 2006-11-20 8:40 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] echo -n 2006-11-20 8:40 [9fans] echo -n arisawa @ 2006-11-20 9:45 ` Martin Neubauer 2006-11-20 10:42 ` lucio 2006-11-20 12:46 ` Russ Cox 1 sibling, 1 reply; 26+ messages in thread From: Martin Neubauer @ 2006-11-20 9:45 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs * 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] echo -n 2006-11-20 9:45 ` Martin Neubauer @ 2006-11-20 10:42 ` lucio 2006-11-20 17:35 ` maht 0 siblings, 1 reply; 26+ messages in thread From: lucio @ 2006-11-20 10:42 UTC (permalink / raw) To: 9fans > Maybe a shell function checking the arguments before > calling echo would be a cleaner solution. Or a distinct option to /bin/echo? ++L ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] echo -n 2006-11-20 10:42 ` lucio @ 2006-11-20 17:35 ` maht 0 siblings, 0 replies; 26+ messages in thread From: maht @ 2006-11-20 17:35 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs >> 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 } ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] echo -n 2006-11-20 8:40 [9fans] echo -n arisawa 2006-11-20 9:45 ` Martin Neubauer @ 2006-11-20 12:46 ` Russ Cox 2006-11-20 14:41 ` John Stalker 2006-11-20 16:37 ` Joel Salomon 1 sibling, 2 replies; 26+ messages in thread From: Russ Cox @ 2006-11-20 12:46 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] echo -n 2006-11-20 12:46 ` Russ Cox @ 2006-11-20 14:41 ` John Stalker 2006-11-20 14:59 ` Dave Lukes 2006-11-20 14:59 ` Axel Belinfante 2006-11-20 16:37 ` Joel Salomon 1 sibling, 2 replies; 26+ messages in thread From: John Stalker @ 2006-11-20 14:41 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] echo -n 2006-11-20 14:41 ` John Stalker @ 2006-11-20 14:59 ` Dave Lukes 2006-11-20 14:59 ` Axel Belinfante 1 sibling, 0 replies; 26+ messages in thread From: Dave Lukes @ 2006-11-20 14:59 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs $ 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. > ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] echo -n 2006-11-20 14:41 ` John Stalker 2006-11-20 14:59 ` Dave Lukes @ 2006-11-20 14:59 ` Axel Belinfante 2006-11-20 15:34 ` ron minnich 2006-11-20 15:43 ` erik quanstrom 1 sibling, 2 replies; 26+ messages in thread From: Axel Belinfante @ 2006-11-20 14:59 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] echo -n 2006-11-20 14:59 ` Axel Belinfante @ 2006-11-20 15:34 ` ron minnich 2006-11-20 15:43 ` erik quanstrom 1 sibling, 0 replies; 26+ messages in thread From: ron minnich @ 2006-11-20 15:34 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] echo -n 2006-11-20 14:59 ` Axel Belinfante 2006-11-20 15:34 ` ron minnich @ 2006-11-20 15:43 ` erik quanstrom 1 sibling, 0 replies; 26+ messages in thread From: erik quanstrom @ 2006-11-20 15:43 UTC (permalink / raw) To: 9fans 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] echo -n 2006-11-20 12:46 ` Russ Cox 2006-11-20 14:41 ` John Stalker @ 2006-11-20 16:37 ` Joel Salomon 2006-11-20 18:49 ` Russ Cox 1 sibling, 1 reply; 26+ messages in thread From: Joel Salomon @ 2006-11-20 16:37 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] echo -n 2006-11-20 16:37 ` Joel Salomon @ 2006-11-20 18:49 ` Russ Cox 2006-11-20 19:16 ` Francisco J Ballesteros 2006-11-20 19:32 ` Joel Salomon 0 siblings, 2 replies; 26+ messages in thread From: Russ Cox @ 2006-11-20 18:49 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] echo -n 2006-11-20 18:49 ` Russ Cox @ 2006-11-20 19:16 ` Francisco J Ballesteros 2006-11-20 19:57 ` Joel Salomon 2006-11-20 19:32 ` Joel Salomon 1 sibling, 1 reply; 26+ messages in thread From: Francisco J Ballesteros @ 2006-11-20 19:16 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 > > ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] echo -n 2006-11-20 19:16 ` Francisco J Ballesteros @ 2006-11-20 19:57 ` Joel Salomon 2006-11-20 20:18 ` Federico Benavento 2006-11-20 20:38 ` Russ Cox 0 siblings, 2 replies; 26+ messages in thread From: Joel Salomon @ 2006-11-20 19:57 UTC (permalink / raw) To: 9fans > > 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] echo -n 2006-11-20 19:57 ` Joel Salomon @ 2006-11-20 20:18 ` Federico Benavento 2006-11-20 20:38 ` Russ Cox 1 sibling, 0 replies; 26+ messages in thread From: Federico Benavento @ 2006-11-20 20:18 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] echo -n 2006-11-20 19:57 ` Joel Salomon 2006-11-20 20:18 ` Federico Benavento @ 2006-11-20 20:38 ` Russ Cox 2006-11-20 21:00 ` Joel Salomon 2006-11-20 21:05 ` Francisco J Ballesteros 1 sibling, 2 replies; 26+ messages in thread From: Russ Cox @ 2006-11-20 20:38 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] echo -n 2006-11-20 20:38 ` Russ Cox @ 2006-11-20 21:00 ` Joel Salomon 2006-11-20 21:05 ` Francisco J Ballesteros 1 sibling, 0 replies; 26+ messages in thread From: Joel Salomon @ 2006-11-20 21:00 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] echo -n 2006-11-20 20:38 ` Russ Cox 2006-11-20 21:00 ` Joel Salomon @ 2006-11-20 21:05 ` Francisco J Ballesteros 2006-11-20 21:55 ` Russ Cox 2006-11-21 3:24 ` lucio 1 sibling, 2 replies; 26+ messages in thread From: Francisco J Ballesteros @ 2006-11-20 21:05 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > 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? ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] echo -n 2006-11-20 21:05 ` Francisco J Ballesteros @ 2006-11-20 21:55 ` Russ Cox 2006-11-20 22:11 ` Francisco J Ballesteros 2006-11-21 3:24 ` lucio 1 sibling, 1 reply; 26+ messages in thread From: Russ Cox @ 2006-11-20 21:55 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] echo -n 2006-11-20 21:55 ` Russ Cox @ 2006-11-20 22:11 ` Francisco J Ballesteros 2006-11-20 22:24 ` Martin Neubauer 2006-11-20 23:14 ` Gorka guardiola 0 siblings, 2 replies; 26+ messages in thread From: Francisco J Ballesteros @ 2006-11-20 22:11 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] echo -n 2006-11-20 22:11 ` Francisco J Ballesteros @ 2006-11-20 22:24 ` Martin Neubauer 2006-11-20 23:14 ` Gorka guardiola 1 sibling, 0 replies; 26+ messages in thread From: Martin Neubauer @ 2006-11-20 22:24 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs * 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] echo -n 2006-11-20 22:11 ` Francisco J Ballesteros 2006-11-20 22:24 ` Martin Neubauer @ 2006-11-20 23:14 ` Gorka guardiola 2006-11-20 23:22 ` Francisco J Ballesteros 1 sibling, 1 reply; 26+ messages in thread From: Gorka guardiola @ 2006-11-20 23:14 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] echo -n 2006-11-20 23:14 ` Gorka guardiola @ 2006-11-20 23:22 ` Francisco J Ballesteros 2006-11-20 23:57 ` Gorka guardiola 0 siblings, 1 reply; 26+ messages in thread From: Francisco J Ballesteros @ 2006-11-20 23:22 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 > > ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] echo -n 2006-11-20 23:22 ` Francisco J Ballesteros @ 2006-11-20 23:57 ` Gorka guardiola 0 siblings, 0 replies; 26+ messages in thread From: Gorka guardiola @ 2006-11-20 23:57 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] echo -n 2006-11-20 21:05 ` Francisco J Ballesteros 2006-11-20 21:55 ` Russ Cox @ 2006-11-21 3:24 ` lucio 1 sibling, 0 replies; 26+ messages in thread From: lucio @ 2006-11-21 3:24 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] echo -n 2006-11-20 18:49 ` Russ Cox 2006-11-20 19:16 ` Francisco J Ballesteros @ 2006-11-20 19:32 ` Joel Salomon 1 sibling, 0 replies; 26+ messages in thread From: Joel Salomon @ 2006-11-20 19:32 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > > 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2006-11-21 3:24 UTC | newest] Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-11-20 8:40 [9fans] echo -n arisawa 2006-11-20 9:45 ` Martin Neubauer 2006-11-20 10:42 ` lucio 2006-11-20 17:35 ` maht 2006-11-20 12:46 ` Russ Cox 2006-11-20 14:41 ` John Stalker 2006-11-20 14:59 ` Dave Lukes 2006-11-20 14:59 ` Axel Belinfante 2006-11-20 15:34 ` ron minnich 2006-11-20 15:43 ` erik quanstrom 2006-11-20 16:37 ` Joel Salomon 2006-11-20 18:49 ` Russ Cox 2006-11-20 19:16 ` Francisco J Ballesteros 2006-11-20 19:57 ` Joel Salomon 2006-11-20 20:18 ` Federico Benavento 2006-11-20 20:38 ` Russ Cox 2006-11-20 21:00 ` Joel Salomon 2006-11-20 21:05 ` Francisco J Ballesteros 2006-11-20 21:55 ` Russ Cox 2006-11-20 22:11 ` Francisco J Ballesteros 2006-11-20 22:24 ` Martin Neubauer 2006-11-20 23:14 ` Gorka guardiola 2006-11-20 23:22 ` Francisco J Ballesteros 2006-11-20 23:57 ` Gorka guardiola 2006-11-21 3:24 ` lucio 2006-11-20 19:32 ` Joel Salomon
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).