[9fans] github blob exchange
Hi Plan9ers, I wrote a little rc script for my personal use. I want to share it with you, as it look quite usefull to me (why would I have wrote it otherwise). https://github.com/ikrabbe/github.rc Check it out and tell me your thoughts. Regards, ingo
Re: [9fans] github blob exchange
I saw "GitHub" and "Plan 9" together and immediately heard angels singing. :) Question what does the --raw option do? On August 10, 2015 5:04:54 AM CDT, Ingo Krabbe wrote: >Hi Plan9ers, > >I wrote a little rc script for my personal use. I want to share it with >you, as it look quite usefull to me (why would I have wrote it >otherwise). > > https://github.com/ikrabbe/github.rc > >Check it out and tell me your thoughts. > >Regards, > >ingo -- Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.
Re: [9fans] github blob exchange
Actually the command is no rocket science. You can simply use hget, sed and htmlfmt to reach similar things. The 'github' command is a kind of shortcut to blobs from github repositories. The --raw mode is the opposite of --blob. I changed the code that *.md files are automatically read blob files, not raw files, though this does not make too much sense on plan9 terminals. I'm just experimenting a bit with the possible transfer modes for files. So for *.md Files --blob mode is automatically selected. Using --raw with *.md Files (such as README.md) will choose the raw mode anyway. For all other files --raw is the default mode and --blob can be chosen to get the html table. But --blob mode for syntax highlighted files does not work yet, as the output is not in an tag (as it is the case with *.md Files). Regards, ingo > I saw "GitHub" and "Plan 9" together and immediately heard angels singing. :) > > Question what does the --raw option do? > > On August 10, 2015 5:04:54 AM CDT, Ingo Krabbe wrote: >>Hi Plan9ers, >> >>I wrote a little rc script for my personal use. I want to share it with >>you, as it look quite usefull to me (why would I have wrote it >>otherwise). >> >> https://github.com/ikrabbe/github.rc >> >>Check it out and tell me your thoughts. >> >>Regards, >> >>ingo > > -- > Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.
[9fans] read9pmsg usage
Hi, I've a probably naive question that I can't figure out. I've just noticed that fcall(2) states > Read9pmsg calls read(2) multiple times, if necessary, to > read an entire 9P message into buf. The return value is 0 > for end of file, or -1 for error; it does not return partial > messages. > > but I've noticed that a few client does not interpret a 0 return value as a EOF, eg https://github.com/brho/plan9/blob/master/sys/src/cmd/usb/lib/fs.c#L604-L606 https://github.com/brho/plan9/blob/master/sys/src/cmd/usb/audio/audiofs.c#L889-L891 https://github.com/brho/plan9/blob/master/sys/src/cmd/aux/searchfs.c#L613-L615 https://github.com/brho/plan9/blob/master/sys/src/cmd/lnfs.c#L547-L551 https://github.com/brho/plan9/blob/master/sys/src/cmd/telco/telco.c#L935-L937 The comment there states that /* * reading from a pipe or a network device * will give an error after a few eof reads. * however, we cannot tell the difference * between a zero-length read and an interrupt * on the processes writing to us, * so we wait for the error. */ However many other fs just handle errors and eof together, for example here: https://github.com/brho/plan9/blob/master/sys/src/cmd/ip/ftpfs/ftpfs.c#L273-L279 I'm a bit confused about this. What's the proper use of the 0 return value? Giacomo
Re: [9fans] read9pmsg usage
on plan 9 systems 0 writes are not discarded. - erik On Aug 10, 2015 7:11 AM, Giacomo Tesio wrote:Hi, I've a probably naive question that I can't figure out.I've just noticed that fcall(2) statesRead9pmsg calls read(2) multiple times, if necessary, to read an entire 9P message into buf. The return value is 0 for end of file, or -1 for error; it does not return partial messages.but I've noticed that a few client does not interpret a 0 return value as a EOF, eghttps://github.com/brho/plan9/blob/master/sys/src/cmd/usb/lib/fs.c#L604-L606https://github.com/brho/plan9/blob/master/sys/src/cmd/usb/audio/audiofs.c#L889-L891https://github.com/brho/plan9/blob/master/sys/src/cmd/aux/searchfs.c#L613-L615 https://github.com/brho/plan9/blob/master/sys/src/cmd/lnfs.c#L547-L551https://github.com/brho/plan9/blob/master/sys/src/cmd/telco/telco.c#L935-L937The comment there states that/* * reading from a pipe or a network device * will give an error after a few eof reads. * however, we cannot tell the difference * between a zero-length read and an interrupt * on the processes writing to us, * so we wait for the error. */ However many other fs just handle errors and eof together, for example here:https://github.com/brho/plan9/blob/master/sys/src/cmd/ip/ftpfs/ftpfs.c#L273-L279I'm a bit confused about this. What's the proper use of the 0 return value?Giacomo
Re: [9fans] read9pmsg usage
2015-08-10 16:22 GMT+02:00 erik quanstrom : > on plan 9 systems 0 writes are not discarded. > Interesting! Is this "by design"? And what is the intended usage of 0 writes? BTW, so fcall(2) is misleading, a 0 read can not be used to identify an EOF, right? Giacomo
Re: [9fans] read9pmsg usage
Zero conventionally means end-of-file, but record boundaries are preserved on capable streams, so if a writer writes zero, the reader reads zero. Having said that, I think the comment is wrong, and read9pmsg returning zero should be interpreted as the end of the (9p) stream. In most cases, the writer will be devmnt, locally or remote, and that should not be generating zero writes (empty records). Funnily enough, I was just going to ask about this myself, specifically whether anyone had seen this case, since I noticed yesterday than 9front had changed several read9pmsg calls to do the same thing, which I was curious about. After all, if an empty record is somehow commonly occurring in a 9p stream, and should be ignored, you'd think read9pmsg would be the place to do that. I don't, however, think anyone should be ignoring the zero return, and if something is generating spurious empty records, that writer should be fixed not to do it. On 10 August 2015 at 15:35, Giacomo Tesio wrote: > 2015-08-10 16:22 GMT+02:00 erik quanstrom : > >> on plan 9 systems 0 writes are not discarded. >> > Interesting! Is this "by design"? > And what is the intended usage of 0 writes? > > BTW, so fcall(2) is misleading, a 0 read can not be used to identify an > EOF, right? > > > Giacomo >
Re: [9fans] read9pmsg usage
As a further historical note, originally 9P required a stream that preseved record boundaries, and the reliable datagram protocol IL/IP and pipes did that. Once TCP/IP was used, there was some fussing needed to work out where the records were, so the revision 9P2000 added a size and the stream didn't need to preserve boundaries itself. As an aside, John Day in his interesting Patterns in Network Architecture (http://goo.gl/4WKu1r) discusses whether protocols should preserve record boundaries, and concludes that they should (assuming I remember correctly!).
Re: [9fans] github blob exchange
Quoting Ryan Gonzalez : I saw "GitHub" and "Plan 9" together and immediately heard angels singing. :) A funeral dirge? khm
Re: [9fans] read9pmsg usage
2015-08-10 16:54 GMT+02:00 Charles Forsyth : > Zero conventionally means end-of-file, but record boundaries are preserved > on capable streams, so if a writer writes zero, the reader reads zero. > However this two requirements do not seem reconcilable. Zero can either mean EOF or "I'm alive but boring". I can't see how a reliable communication (a cpu connection for example) can survive this mismatch. I'm probably missing something. Giacomo
Re: [9fans] read9pmsg usage
On 10 August 2015 at 21:17, Giacomo Tesio wrote: > Zero can either mean EOF or "I'm alive but boring". > > I can't see how a reliable communication (a cpu connection for example) can > survive this mismatch. > I'm probably missing something. > A specialised reader and writer can always agree that it means something else in a particular case, but the general convention is that zero (empty record) means you've hit the end of a sequence of records (if write boundaries are preserved) or the end of a sequence of bytes (if write boundaries are not preserved), and thus end of file. In other words, the interpretation is the traditional one from UNIX and other systems. It isn't intended as a general "keep-alive" mechanism. That's why the read9pmsg case is odd, and why I think the comment and code are wrong. You could for instance use it to send several distinct byte streams through a pipe, but only to a specialised reader.
