* Re: [9fans] success with 9vx from a terminal
@ 2008-10-22 11:42 erik quanstrom
2008-10-22 12:25 ` roger peppe
2008-10-22 14:22 ` john
0 siblings, 2 replies; 26+ messages in thread
From: erik quanstrom @ 2008-10-22 11:42 UTC (permalink / raw)
To: Christian.Kellermann, 9fans
> * gdiaz@9grid.es <gdiaz@9grid.es> [081022 11:16]:
> > Hello,
> >
> > Rio is the responsible for killing a process using the Del key, AFAIK there is no way to terminate a program running in console. May be with some magic combination of the keys ctrl-t ctrl-t X.
>
> Why not write a simple 'shell' shell (heh) that cooks input and just runs rc? Then you would have the del key and others again.
you mean like, uh, rio or acme? ☺
- erik
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] success with 9vx from a terminal 2008-10-22 11:42 [9fans] success with 9vx from a terminal erik quanstrom @ 2008-10-22 12:25 ` roger peppe 2008-10-22 14:22 ` john 1 sibling, 0 replies; 26+ messages in thread From: roger peppe @ 2008-10-22 12:25 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Wed, Oct 22, 2008 at 12:42 PM, erik quanstrom <quanstro@quanstro.net> wrote: > you mean like, uh, rio or acme? ☺ i can't see why it would be a bad idea to do something like this for text-only mode. it'd be a nice exercise, if nothing else. it should be possible to do without writing a file server, too, which is always a bonus. there's one thing: i think you'd need either to use a different key for interrupt, or have a wrapper outside of 9vx to prevent the usual key for interrupt just killing 9vx as usual. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] success with 9vx from a terminal 2008-10-22 11:42 [9fans] success with 9vx from a terminal erik quanstrom 2008-10-22 12:25 ` roger peppe @ 2008-10-22 14:22 ` john 2008-10-22 16:28 ` erik quanstrom 1 sibling, 1 reply; 26+ messages in thread From: john @ 2008-10-22 14:22 UTC (permalink / raw) To: 9fans >> * gdiaz@9grid.es <gdiaz@9grid.es> [081022 11:16]: >> > Hello, >> > >> > Rio is the responsible for killing a process using the Del key, AFAIK there is no way to terminate a program running in console. May be with some magic combination of the keys ctrl-t ctrl-t X. >> >> Why not write a simple 'shell' shell (heh) that cooks input and just runs rc? Then you would have the del key and others again. > > you mean like, uh, rio or acme? ☺ > > - erik This whole "Writing anything new is a terrible idea!" attitude is getting old. Why does acme exist? Thank god you weren't around the Unix Room when that got started, or you would have just said, "Isn't sam good enough for you?" If somebody feels the need for a functional text-mode interface, he should write it. I've felt a need for such a thing myself while fiddling with kernels that don't have video support. Believe it or not, there *is* room in Plan 9 for additions and improvements. John "Denial ain't just a river" Floren ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] success with 9vx from a terminal 2008-10-22 14:22 ` john @ 2008-10-22 16:28 ` erik quanstrom 2008-10-22 16:35 ` Roman V. Shaposhnik 0 siblings, 1 reply; 26+ messages in thread From: erik quanstrom @ 2008-10-22 16:28 UTC (permalink / raw) To: john, 9fans > >> > Hello, > >> > > >> > Rio is the responsible for killing a process using the Del key, AFAIK there is no way to terminate a program running in console. May be with some magic combination of the keys ctrl-t ctrl-t X. > >> > >> Why not write a simple 'shell' shell (heh) that cooks input and just runs rc? Then you would have the del key and others again. > > > > you mean like, uh, rio or acme? ☺ > > > > - erik > > This whole "Writing anything new is a terrible idea!" attitude is > getting old. Why does acme exist? Thank god you weren't around the > Unix Room when that got started, or you would have just said, "Isn't > sam good enough for you?" If somebody feels the need for a functional > text-mode interface, he should write it. I've felt a need for such a > thing myself while fiddling with kernels that don't have video > support. Believe it or not, there *is* room in Plan 9 for additions > and improvements. i thought "☺" was the international symbol for tongue-in-cheek. could you please let me know what the iso approved symbol is? by the way, in case you haven't noticed, i have contributed a number of new things. not all of them are worth incorporating. i would hope that standards for plan 9 remain high and we don't just shovel everything in. rio does provide most everything one would need for a "text-mode" interface. unfortunately, you can't currently "tail -f" /dev/text. perhaps such a change would be easier and more general than writing something completely seperate? - erik ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] success with 9vx from a terminal 2008-10-22 16:28 ` erik quanstrom @ 2008-10-22 16:35 ` Roman V. Shaposhnik 0 siblings, 0 replies; 26+ messages in thread From: Roman V. Shaposhnik @ 2008-10-22 16:35 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Wed, 2008-10-22 at 12:28 -0400, erik quanstrom wrote: > rio does provide most everything one would need for a "text-mode" > interface. unfortunately, you can't currently "tail -f" /dev/text. perhaps > such a change would be easier and more general That's a very good point! It hadn't occurred to me either, but now that you've mentioned it -- makes total sense. I have the same issue with browsers on UNIX -- why is Firefox not capable of rendering on non-X11 surfaces? Why do I have to use a separate thing called lynx? Thanks, Roman. ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <0bff7fbe9fa7f6b6305adedeba12e019@quanstro.net>]
* Re: [9fans] success with 9vx from a terminal [not found] <0bff7fbe9fa7f6b6305adedeba12e019@quanstro.net> @ 2008-10-22 12:01 ` Christian Kellermann 0 siblings, 0 replies; 26+ messages in thread From: Christian Kellermann @ 2008-10-22 12:01 UTC (permalink / raw) To: erik quanstrom; +Cc: 9fans [-- Attachment #1: Type: text/plain, Size: 710 bytes --] * erik quanstrom <quanstro@quanstro.net> [081022 13:51]: > > * gdiaz@9grid.es <gdiaz@9grid.es> [081022 11:16]: > > > Hello, > > > > > > Rio is the responsible for killing a process using the Del key, AFAIK there is no way to terminate a program running in console. May be with some magic combination of the keys ctrl-t ctrl-t X. > > > > Why not write a simple 'shell' shell (heh) that cooks input and just runs rc? Then you would have the del key and others again. > > you mean like, uh, rio or acme? ??? Yes, the requirements have been laid out as non graphical, so acme and rio are out... -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen) [-- Attachment #2: Type: application/pgp-signature, Size: 202 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] success with 9vx from a terminal
@ 2008-10-22 9:15 gdiaz
2008-10-22 9:18 ` Christian Kellermann
0 siblings, 1 reply; 26+ messages in thread
From: gdiaz @ 2008-10-22 9:15 UTC (permalink / raw)
To: 9fans
Hello,
Rio is the responsible for killing a process using the Del key, AFAIK there is no way to terminate a program running in console. May be with some magic combination of the keys ctrl-t ctrl-t X.
gabi
-- cmbrannon@cox.net wrote:
>
>Last night I downloaded 9vx. It works fine from a terminal, using
>the following invocation:
>../9vx.Linux -g -u glenda
>where -g is the option to run sans GUI.
>This has one or two complications. There is no way to interrupt or kill
>the foreground process. Instead, ctrl-c interrupts 9vx itself.
>Anyway, I managed to get an emulated Plan 9 system up and running.
>Both ed and "sam -d" work well for editing text.
>
>-- Chris
>
>
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] success with 9vx from a terminal 2008-10-22 9:15 gdiaz @ 2008-10-22 9:18 ` Christian Kellermann 0 siblings, 0 replies; 26+ messages in thread From: Christian Kellermann @ 2008-10-22 9:18 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 522 bytes --] * gdiaz@9grid.es <gdiaz@9grid.es> [081022 11:16]: > Hello, > > Rio is the responsible for killing a process using the Del key, AFAIK there is no way to terminate a program running in console. May be with some magic combination of the keys ctrl-t ctrl-t X. Why not write a simple 'shell' shell (heh) that cooks input and just runs rc? Then you would have the del key and others again. Cheers, Christian -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen) [-- Attachment #2: Type: application/pgp-signature, Size: 202 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* [9fans] success with 9vx from a terminal @ 2008-10-22 8:35 Chris Brannon 2008-10-22 16:54 ` andrey mirtchovski 0 siblings, 1 reply; 26+ messages in thread From: Chris Brannon @ 2008-10-22 8:35 UTC (permalink / raw) To: 9fans Last night I downloaded 9vx. It works fine from a terminal, using the following invocation: ../9vx.Linux -g -u glenda where -g is the option to run sans GUI. This has one or two complications. There is no way to interrupt or kill the foreground process. Instead, ctrl-c interrupts 9vx itself. Anyway, I managed to get an emulated Plan 9 system up and running. Both ed and "sam -d" work well for editing text. -- Chris ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] success with 9vx from a terminal 2008-10-22 8:35 Chris Brannon @ 2008-10-22 16:54 ` andrey mirtchovski 2008-10-22 17:56 ` andrey mirtchovski ` (2 more replies) 0 siblings, 3 replies; 26+ messages in thread From: andrey mirtchovski @ 2008-10-22 16:54 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 2096 bytes --] > This has one or two complications. There is no way to interrupt or kill > the foreground process. Instead, ctrl-c interrupts 9vx itself. chris, one of the nice things about the Plan 9 graphics system is that rio is in no way different than any other graphical program. it reads and writes files in /dev/wsys and multiplexes them between other applications. in that sense, you don't need to run rio in order to run a graphical app. from the 9vx console you can just type 'acme' and you'll have acme running in full-screen mode. if you know what you desire in a window manager (perhaps a terminal window in a static location to which you can always return, or keyboard-driven window switching) one can be written so that it's used instead of rio. graphical programs in plan9 are not hard. in the mean time you wan use acme's terminal (the program is called 'win') to gain a more feature-full environment. i have attached here a dump file which can be used to start acme in a single-column mode with a single window running the terminal program. that will give you interrupt capability. from here you can hopefully explore the system without having to deal with windows. unfortunately the default for 'win' is to not scroll to the bottom of the window when the text fills the screen and there is only one way to turn that off: in a terminal you have to type 'scroll' and middle-click it with the mouse (is there a way to issue this as a command from the terminal, anybody?). also, you can backspace over the beginning of the line to the previous row which can be annoying. if you think this may be useful and you want to give it a try please copy the attached acme.dump file somewhere within the 9vx plan9 directory, then start 9vx and in its terminal type "acme -l /path/to/acme.dump" where /path/to is just the path relative to root. the screen will have acme's main "menu" (text) as its first row, then column menu as the second (New Cut Paste, etc) with the terminal starting on the third row. hope this gives you a better environment. andery [-- Attachment #2: acme.dump --] [-- Type: application/octet-stream, Size: 252 bytes --] / /lib/font/bit/lucidasans/euro.8.font /lib/font/bit/lucm/unicode.9.font 0 e 0 0 0 0 1 2 38 6153 0 1 //-vx32 Del Snarf | Look Send Noscroll / win ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] success with 9vx from a terminal 2008-10-22 16:54 ` andrey mirtchovski @ 2008-10-22 17:56 ` andrey mirtchovski 2008-10-22 17:56 ` erik quanstrom 2008-10-22 23:43 ` Roman V. Shaposhnik 2 siblings, 0 replies; 26+ messages in thread From: andrey mirtchovski @ 2008-10-22 17:56 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 1787 bytes --] my previous message was meant to include a small addition which I omitted by accident and which turned out to be wrong anyway. here is the rest of the picture. I presume that there is no program to read the text on the graphical 9vx terminal (which would be required in order to "visualize" rio), so instead i've made a small addition to the win program that runs inside 'acme' allowing all input and output to be tee-d (logged) to a separate file somewhere in the plan9 tree. that file can then be then tail-ed, catted or whatever is needed in order to provide the text of the acme conversation to a third program. the changes are rather rude, but i hope they help. here is how to install them: copy the attached main.c to /acme/bin/source/win (inside plan9). cd to that directory and run 'mk install' from within 9vx. then copy the new acme.dump file attached in this email to your home directory in 9vx (/usr/youruser, it has to be in a home directory because / is not writeable in 9vx). edit this file. the last line provides the application to start. the argument to win which we just added with the new code tells it to dump the conversation to /usr/andrey/test.txt. change this to point to a file in your home directory inside 9vx. this is the file which will contain the entire conversation and update it in real-time. i imagine that whatever program reads text will be using that file as its source. start 9vx and acme again inside via "acme -l /path/to/acme.dump" and it should start in a single-column mode with the new 'win' program copying its i/o to the file of your choosing. i admin it's convoluted, but it was a nice exercise in trying to understand the system from a completely different point of view. hope it's useful. andrey [-- Attachment #2: acme.dump --] [-- Type: application/octet-stream, Size: 306 bytes --] /usr/andrey /lib/font/bit/lucidasans/euro.8.font /lib/font/bit/lucm/unicode.9.font 0 e 0 0 0 0 1 2 48 2 0 1 /usr/andrey/-vx32 Del Snarf | Look Send Noscroll /usr/andrey win -f /usr/andrey/test.txt [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #3: main.c --] [-- Type: text/x-csrc; name=main.c, Size: 12767 bytes --] #include <u.h> #include <libc.h> #include <bio.h> #include <thread.h> #include <fcall.h> #include <9p.h> #include <ctype.h> #include "dat.h" void mainctl(void*); void startcmd(char *[], int*); void stdout2body(void*); int debug; int notepg; int eraseinput; int dirty = 0; int logfile = -1; Window *win; /* the main window */ void usage(void) { fprint(2, "usage: win [command]\n"); threadexitsall("usage"); } void threadmain(int argc, char *argv[]) { int i, j; char *dir, *tag, *name; char buf[1024], **av, *f; quotefmtinstall(); rfork(RFNAMEG); ARGBEGIN{ case 'd': debug = 1; chatty9p++; break; case 'e': eraseinput = 1; break; case 'D': {extern int _threaddebuglevel; _threaddebuglevel = 1<<20; } case 'f': f = EARGF(usage); logfile=create(f, OWRITE, 0666); if(logfile < 0) sysfatal("can not open log file %s: %r", f); }ARGEND if(argc == 0){ av = emalloc(3*sizeof(char*)); av[0] = "rc"; av[1] = "-i"; name = getenv("sysname"); }else{ av = argv; name = utfrrune(av[0], '/'); if(name) name++; else name = av[0]; } if(getwd(buf, sizeof buf) == 0) dir = "/"; else dir = buf; dir = estrdup(dir); tag = estrdup(dir); tag = eappend(estrdup(tag), "/-", name); win = newwindow(); snprint(buf, sizeof buf, "%d", win->id); putenv("winid", buf); winname(win, tag); wintagwrite(win, "Send Noscroll", 5+8); threadcreate(mainctl, win, STACK); mountcons(); threadcreate(fsloop, nil, STACK); startpipe(); startcmd(av, ¬epg); strcpy(buf, "win"); j = 3; for(i=0; i<argc && j+1+strlen(argv[i])+1<sizeof buf; i++){ strcpy(buf+j, " "); strcpy(buf+j+1, argv[i]); j += 1+strlen(argv[i]); } ctlprint(win->ctl, "scroll"); winsetdump(win, dir, buf); } int EQUAL(char *s, char *t) { while(tolower(*s) == tolower(*t++)) if(*s++ == '\0') return 1; return 0; } int command(Window *w, char *s) { while(*s==' ' || *s=='\t' || *s=='\n') s++; if(strcmp(s, "Delete")==0 || strcmp(s, "Del")==0){ windel(w, 1); threadexitsall(nil); return 1; } if(EQUAL(s, "scroll")){ ctlprint(w->ctl, "scroll\nshow"); return 1; } if(EQUAL(s, "noscroll")){ ctlprint(w->ctl, "noscroll"); return 1; } return 0; } static long utfncpy(char *to, char *from, int n) { char *end, *e; e = to+n; if(to >= e) return 0; end = memccpy(to, from, '\0', e - to); if(end == nil){ end = e; if(end[-1]&0x80){ if(end-2>=to && (end[-2]&0xE0)==0xC0) return end-to; if(end-3>=to && (end[-3]&0xF0)==0xE0) return end-to; while(end>to && (*--end&0xC0)==0x80) ; } }else end--; return end - to; } /* sendinput and fsloop run in the same proc (can't interrupt each other). */ static Req *q; static Req **eq; static int __sendinput(Window *w, ulong q0, ulong q1) { char *s, *t; int n, nb, eofchar; static int partial; static char tmp[UTFmax]; Req *r; Rune rune; if(!q) return 0; r = q; n = 0; if(partial){ Partial: nb = partial; if(nb > r->ifcall.count) nb = r->ifcall.count; memmove(r->ofcall.data, tmp, nb); if(nb!=partial) memmove(tmp, tmp+nb, partial-nb); partial -= nb; q = r->aux; if(q == nil) eq = &q; r->aux = nil; r->ofcall.count = nb; if(debug) fprint(2, "satisfy read with partial\n"); respond(r, nil); return n; } if(q0==q1) return 0; s = emalloc((q1-q0)*UTFmax+1); n = winread(w, q0, q1, s); s[n] = '\0'; t = strpbrk(s, "\n\004"); if(t == nil){ free(s); return 0; } r = q; eofchar = 0; if(*t == '\004'){ eofchar = 1; *t = '\0'; }else *++t = '\0'; nb = utfncpy((char*)r->ofcall.data, s, r->ifcall.count); if(nb==0 && s<t && r->ifcall.count > 0){ partial = utfncpy(tmp, s, UTFmax); assert(partial > 0); chartorune(&rune, tmp); partial = runelen(rune); free(s); n = 1; goto Partial; } n = utfnlen(r->ofcall.data, nb); if(nb==strlen(s) && eofchar) n++; r->ofcall.count = nb; q = r->aux; if(q == nil) eq = &q; r->aux = nil; if(debug) fprint(2, "read returns %lud-%lud: %.*q\n", q0, q0+n, n, r->ofcall.data); respond(r, nil); return n; } static int _sendinput(Window *w, ulong q0, ulong *q1) { char buf[32]; int n; n = __sendinput(w, q0, *q1); if(!n || !eraseinput) return n; /* erase q0 to q0+n */ sprint(buf, "#%lud,#%lud", q0, q0+n); winsetaddr(w, buf, 0); write(w->data, buf, 0); if(logfile) write(logfile, buf, 0); *q1 -= n; return 0; } int sendinput(Window *w, ulong q0, ulong *q1) { ulong n; Req *oq; n = 0; do { oq = q; n += _sendinput(w, q0+n, q1); } while(q != oq); return n; } Event esendinput; void fsloop(void*) { Fsevent e; Req **l, *r; eq = &q; memset(&esendinput, 0, sizeof esendinput); esendinput.c1 = 'C'; for(;;){ while(recv(fschan, &e) == -1) ; r = e.r; switch(e.type){ case 'r': *eq = r; r->aux = nil; eq = &r->aux; /* call sendinput with hostpt and endpt */ sendp(win->cevent, &esendinput); break; case 'f': for(l=&q; *l; l=&(*l)->aux){ if(*l == r->oldreq){ *l = (*l)->aux; if(*l == nil) eq = l; respond(r->oldreq, "interrupted"); break; } } respond(r, nil); break; } } } void sendit(char *s) { // char tmp[32]; write(win->body, s, strlen(s)); if(logfile) write(logfile, s, strlen(s)); /* * RSC: The problem here is that other procs can call sendit, * so we lose our single-threadedness if we call sendinput. * In fact, we don't even have the right queue memory, * I think that we'll get a write event from the body write above, * and we can do the sendinput then, from our single thread. * * I still need to figure out how to test this assertion for * programs that use /srv/win* * winselect(win, "$", 0); seek(win->addr, 0UL, 0); if(read(win->addr, tmp, 2*12) == 2*12) hostpt += sendinput(win, hostpt, atol(tmp), ); */ } void execevent(Window *w, Event *e, int (*command)(Window*, char*)) { Event *ea, *e2; int n, na, len, needfree; char *s, *t; ea = nil; e2 = nil; if(e->flag & 2) e2 = recvp(w->cevent); if(e->flag & 8){ ea = recvp(w->cevent); na = ea->nb; recvp(w->cevent); }else na = 0; needfree = 0; s = e->b; if(e->nb==0 && (e->flag&2)){ s = e2->b; e->q0 = e2->q0; e->q1 = e2->q1; e->nb = e2->nb; } if(e->nb==0 && e->q0<e->q1){ /* fetch data from window */ s = emalloc((e->q1-e->q0)*UTFmax+2); n = winread(w, e->q0, e->q1, s); s[n] = '\0'; needfree = 1; }else if(na){ t = emalloc(strlen(s)+1+na+2); sprint(t, "%s %s", s, ea->b); if(needfree) free(s); s = t; needfree = 1; } /* if it's a known command, do it */ /* if it's a long message, it can't be for us anyway */ if(!command(w, s) && s[0]!='\0'){ /* send it as typed text */ /* if it's a built-in from the tag, send it back */ if(e->flag & 1) fprint(w->event, "%c%c%d %d\n", e->c1, e->c2, e->q0, e->q1); else{ /* send text to main window */ len = strlen(s); if(len>0 && s[len-1]!='\n' && s[len-1]!='\004'){ if(!needfree){ /* if(needfree), we left room for a newline before */ t = emalloc(len+2); strcpy(t, s); s = t; needfree = 1; } s[len++] = '\n'; s[len] = '\0'; } sendit(s); } } if(needfree) free(s); } int hasboundary(Rune *r, int nr) { int i; for(i=0; i<nr; i++) if(r[i]=='\n' || r[i]=='\004') return 1; return 0; } void mainctl(void *v) { Window *w; Event *e; int delta, pendingS, pendingK; ulong hostpt, endpt; char tmp[32]; w = v; proccreate(wineventproc, w, STACK); hostpt = 0; endpt = 0; winsetaddr(w, "0", 0); pendingS = 0; pendingK = 0; for(;;){ if(debug) fprint(2, "input range %lud-%lud\n", hostpt, endpt); e = recvp(w->cevent); if(debug) fprint(2, "msg: %C %C %d %d %d %d %q\n", e->c1 ? e->c1 : ' ', e->c2 ? e->c2 : ' ', e->q0, e->q1, e->flag, e->nb, e->b); switch(e->c1){ default: Unknown: fprint(2, "unknown message %c%c\n", e->c1, e->c2); break; case 'C': /* input needed for /dev/cons */ if(pendingS) pendingK = 1; else hostpt += sendinput(w, hostpt, &endpt); break; case 'S': /* output to stdout */ sprint(tmp, "#%lud", hostpt); winsetaddr(w, tmp, 0); write(w->data, e->b, e->nb); if(logfile) write(logfile, e->b, e->nb); pendingS += e->nr; break; case 'E': /* write to tag or body; body happens due to sendit */ delta = e->q1-e->q0; if(e->c2=='I'){ endpt += delta; if(e->q0 < hostpt) hostpt += delta; else hostpt += sendinput(w, hostpt, &endpt); break; } if(!islower(e->c2)) fprint(2, "win msg: %C %C %d %d %d %d %q\n", e->c1, e->c2, e->q0, e->q1, e->flag, e->nb, e->b); break; case 'F': /* generated by our actions (specifically case 'S' above) */ delta = e->q1-e->q0; if(e->c2=='D'){ /* we know about the delete by _sendinput */ break; } if(e->c2=='I'){ pendingS -= e->q1 - e->q0; if(pendingS < 0) fprint(2, "win: pendingS = %d\n", pendingS); if(e->q0 != hostpt) fprint(2, "win: insert at %d expected %lud\n", e->q0, hostpt); endpt += delta; hostpt += delta; sendp(writechan, nil); if(pendingS == 0 && pendingK){ pendingK = 0; hostpt += sendinput(w, hostpt, &endpt); } break; } if(!islower(e->c2)) fprint(2, "win msg: %C %C %d %d %d %d %q\n", e->c1, e->c2, e->q0, e->q1, e->flag, e->nb, e->b); break; case 'K': delta = e->q1-e->q0; if(logfile) write(logfile, e->b, e->nb); switch(e->c2){ case 'D': endpt -= delta; if(e->q1 < hostpt) hostpt -= delta; else if(e->q0 < hostpt) hostpt = e->q0; break; case 'I': delta = e->q1 - e->q0; endpt += delta; if(endpt < e->q1) /* just in case */ endpt = e->q1; if(e->q0 < hostpt) hostpt += delta; if(e->nr>0 && e->r[e->nr-1]==0x7F){ write(notepg, "interrupt", 9); hostpt = endpt; break; } if(e->q0 >= hostpt && hasboundary(e->r, e->nr)){ /* * If we are between the S message (which * we processed by inserting text in the * window) and the F message notifying us * that the text has been inserted, then our * impression of the hostpt and acme's * may be different. This could be seen if you * hit enter a bunch of times in a con * session. To work around the unreliability, * only send input if we don't have an S pending. * The same race occurs between when a character * is typed and when we get notice of it, but * since characters tend to be typed at the end * of the buffer, we don't run into it. There's * no workaround possible for this typing race, * since we can't tell when the user has typed * something but we just haven't been notified. */ if(pendingS) pendingK = 1; else hostpt += sendinput(w, hostpt, &endpt); } break; } break; case 'M': /* mouse */ delta = e->q1-e->q0; switch(e->c2){ case 'x': case 'X': execevent(w, e, command); break; case 'l': /* reflect all searches back to acme */ case 'L': if(e->flag & 2) recvp(w->cevent); winwriteevent(w, e); break; case 'I': endpt += delta; if(e->q0 < hostpt) hostpt += delta; else hostpt += sendinput(w, hostpt, &endpt); break; case 'D': endpt -= delta; if(e->q1 < hostpt) hostpt -= delta; else if(e->q0 < hostpt) hostpt = e->q0; break; case 'd': /* modify away; we don't care */ case 'i': break; default: goto Unknown; } } } } enum { NARGS = 100, NARGCHAR = 8*1024, EXECSTACK = STACK+(NARGS+1)*sizeof(char*)+NARGCHAR }; struct Exec { char **argv; Channel *cpid; }; int lookinbin(char *s) { if(s[0] == '/') return 0; if(s[0]=='.' && s[1]=='/') return 0; if(s[0]=='.' && s[1]=='.' && s[2]=='/') return 0; return 1; } /* adapted from mail. not entirely free of details from that environment */ void execproc(void *v) { struct Exec *e; char *cmd, **av; Channel *cpid; e = v; rfork(RFCFDG|RFNOTEG); av = e->argv; close(0); open("/dev/cons", OREAD); close(1); open("/dev/cons", OWRITE); dup(1, 2); cpid = e->cpid; free(e); procexec(cpid, av[0], av); if(lookinbin(av[0])){ cmd = estrstrdup("/bin/", av[0]); procexec(cpid, cmd, av); } error("can't exec %s: %r", av[0]); } void startcmd(char *argv[], int *notepg) { struct Exec *e; Channel *cpid; char buf[64]; int pid; e = emalloc(sizeof(struct Exec)); e->argv = argv; cpid = chancreate(sizeof(ulong), 0); e->cpid = cpid; sprint(buf, "/mnt/wsys/%d", win->id); bind(buf, "/dev/acme", MREPL); proccreate(execproc, e, EXECSTACK); do pid = recvul(cpid); while(pid == -1); sprint(buf, "/proc/%d/notepg", pid); *notepg = open(buf, OWRITE); } ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] success with 9vx from a terminal 2008-10-22 16:54 ` andrey mirtchovski 2008-10-22 17:56 ` andrey mirtchovski @ 2008-10-22 17:56 ` erik quanstrom 2008-10-22 18:52 ` andrey mirtchovski 2008-10-22 23:43 ` Roman V. Shaposhnik 2 siblings, 1 reply; 26+ messages in thread From: erik quanstrom @ 2008-10-22 17:56 UTC (permalink / raw) To: mirtchovski, 9fans > you have to type 'scroll' and middle-click it with the mouse (is there > a way to issue this as a command from the terminal, anybody?). also, one would think that ; echo noscroll>/dev/wctl would work, but it does not. - erik ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] success with 9vx from a terminal 2008-10-22 17:56 ` erik quanstrom @ 2008-10-22 18:52 ` andrey mirtchovski 0 siblings, 0 replies; 26+ messages in thread From: andrey mirtchovski @ 2008-10-22 18:52 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs I was playing around with the modified "win" program and I realized it's not going to work due to the propensity of acme to redirect standard error to a separate window. This environment has no way of notifying anyone that a new window has opened without being requested except visually. A better solution would be to display only a single, border-less terminal window filling the entire screen. Perhaps even multiplexing between a few full-screen terminal windows similar to the ttys available on a *bsd or linux console. Sorry for the noise. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] success with 9vx from a terminal 2008-10-22 16:54 ` andrey mirtchovski 2008-10-22 17:56 ` andrey mirtchovski 2008-10-22 17:56 ` erik quanstrom @ 2008-10-22 23:43 ` Roman V. Shaposhnik 2008-11-09 16:55 ` sqweek 2 siblings, 1 reply; 26+ messages in thread From: Roman V. Shaposhnik @ 2008-10-22 23:43 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Wed, 2008-10-22 at 10:54 -0600, andrey mirtchovski wrote: > > This has one or two complications. There is no way to interrupt or kill > > the foreground process. Instead, ctrl-c interrupts 9vx itself. > > chris, > > one of the nice things about the Plan 9 graphics system is that rio is > in no way different than any other graphical program. it reads and > writes files in /dev/wsys and multiplexes them between other > applications. in that sense, you don't need to run rio in order to run > a graphical app. from the 9vx console you can just type 'acme' and > you'll have acme running in full-screen mode. if you know what you > desire in a window manager (perhaps a terminal window in a static > location to which you can always return, or keyboard-driven window > switching) one can be written so that it's used instead of rio. > graphical programs in plan9 are not hard. > > in the mean time you wan use acme's terminal (the program is called > 'win') to gain a more feature-full environment. Everything up until this point made total sense to me. But now, that you've brought acme into discussion -- I'm confused. Granted, I happen to NOT be an acme user myself so may be that's why I see nothing that it brings to the table in this particular situation. The previous suggestion was around rio which, at face value was more than reasonable especially if one considers rio's desire to stay explicitly out of the way as far as drawing surfaces multiplexing is concerned: From rio(4): "Note that the draw(3) device multiplexes itself; rio places windows but does not mediate programs' access to the display device." It seems that all we need from rio(4) in a tty-only scenario is its ability to multiplex /dev/cons in a way that also interprets particular sequences of bytes (like Ctrl-C, Ctrl-D, and may be even escape sequences) and translates those into actions: sending a note to a process, creating a new window, etc. It almost sounds exactly like what screen(1) is doing for UNIX ttys. It probably will require some changes to the existing code for rio. That's what I would call an internal multiplexing: 9vx is running with its stdin, stdout and stderr attached to a tty and that's what gets served as '#c/cons'. The only process that accesses it is rio. The rest of the Plan 9 processes see /dev/cons served by rio. So far so good, except that 9vx *already* seems to interpret things like Ctrl-D: linux-box$ ./9vx.Linux -g -u glenda init: starting /bin/rc upas/fs: '/bin/upas/fs' does not exist #m/mousectl: rc: can't open: jmk added reentrancy for threads init: rc exit status: rc 5: error init: starting /bin/rc % cat \x04% It looks like when I pressed Ctrl-D that got interpreted as an EOF coming from '#c/cons' right? In that same spirit, interpreting DEL as a character that triggers a note to be sent should also be quite doable within the #c driver. The only question is -- where such a note is supposed to be sent to? Can someone, please, educate me on the moral equivalent of process groups, sessions and their relationships with #c/cons ? Thanks, Roman. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] success with 9vx from a terminal 2008-10-22 23:43 ` Roman V. Shaposhnik @ 2008-11-09 16:55 ` sqweek 2008-11-09 20:50 ` Charles Forsyth 2008-11-10 22:24 ` Roman V. Shaposhnik 0 siblings, 2 replies; 26+ messages in thread From: sqweek @ 2008-11-09 16:55 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Thu, Oct 23, 2008 at 8:43 AM, Roman V. Shaposhnik <rvs@sun.com> wrote: > The only question is -- where such a note > is supposed to be sent to? > > Can someone, please, educate me on the moral equivalent of process > groups, sessions and their relationships with #c/cons ? Maybe you worked this one out already, but It depends on how they were forked. I don't think I can explain it better than rfork(2) - the bit about RFNOTEG is particularly relevant. I'm not aware of any relationship between #c/cons and notes, but I'm not really sure what magic is involved in the DEL interrupt. -sqweek ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] success with 9vx from a terminal 2008-11-09 16:55 ` sqweek @ 2008-11-09 20:50 ` Charles Forsyth 2008-11-10 22:24 ` Roman V. Shaposhnik 1 sibling, 0 replies; 26+ messages in thread From: Charles Forsyth @ 2008-11-09 20:50 UTC (permalink / raw) To: 9fans >I'm not really sure what magic is involved in the DEL interrupt. rio (or ip/telnetd, or ... some other user program). ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] success with 9vx from a terminal 2008-11-09 16:55 ` sqweek 2008-11-09 20:50 ` Charles Forsyth @ 2008-11-10 22:24 ` Roman V. Shaposhnik 2008-11-10 22:49 ` ron minnich 2008-11-10 23:27 ` erik quanstrom 1 sibling, 2 replies; 26+ messages in thread From: Roman V. Shaposhnik @ 2008-11-10 22:24 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Mon, 2008-11-10 at 01:55 +0900, sqweek wrote: > On Thu, Oct 23, 2008 at 8:43 AM, Roman V. Shaposhnik <rvs@sun.com> wrote: > > The only question is -- where such a note > > is supposed to be sent to? > > > > Can someone, please, educate me on the moral equivalent of process > > groups, sessions and their relationships with #c/cons ? > > Maybe you worked this one out already, Well, sort of -- yes. But thanks for chiming in anyway. > I'm not aware of any relationship between #c/cons and notes, > but I'm not really sure what magic is involved in the DEL interrupt. At least in case of cpu(1) the magic is a bit perverse and quite unlike the rest of the system. The way notes are managed make a local end of a cpu(1) jump through considerable hoops in order for the notes to be properly delivered. That was a sad discovery. Another discovery was that devcons.c could have made DEL work but decided not to :-( Thanks, Roman. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] success with 9vx from a terminal 2008-11-10 22:24 ` Roman V. Shaposhnik @ 2008-11-10 22:49 ` ron minnich 2008-11-10 22:50 ` Roman V. Shaposhnik 2008-11-10 23:27 ` erik quanstrom 1 sibling, 1 reply; 26+ messages in thread From: ron minnich @ 2008-11-10 22:49 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Mon, Nov 10, 2008 at 2:24 PM, Roman V. Shaposhnik <rvs@sun.com> wrote: > At least in case of cpu(1) the magic is a bit perverse and quite > unlike the rest of the system. The way notes are managed make > a local end of a cpu(1) jump through considerable hoops in order > for the notes to be properly delivered. That was a sad discovery. CPU is really worth reading and understanding. It uses a lot of neat tricks. Recommended. ron ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] success with 9vx from a terminal 2008-11-10 22:49 ` ron minnich @ 2008-11-10 22:50 ` Roman V. Shaposhnik 2008-11-10 23:14 ` ron minnich 2008-11-10 23:42 ` andrey mirtchovski 0 siblings, 2 replies; 26+ messages in thread From: Roman V. Shaposhnik @ 2008-11-10 22:50 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Mon, 2008-11-10 at 14:49 -0800, ron minnich wrote: > On Mon, Nov 10, 2008 at 2:24 PM, Roman V. Shaposhnik <rvs@sun.com> wrote: > > > At least in case of cpu(1) the magic is a bit perverse and quite > > unlike the rest of the system. The way notes are managed make > > a local end of a cpu(1) jump through considerable hoops in order > > for the notes to be properly delivered. That was a sad discovery. > > > CPU is really worth reading and understanding. 100% agreed. But... > It uses a lot of neat tricks. ... would you really honestly say that rolling out your own notes forwarder is a *neat* trick? As opposed to be able to use basic system's FS functionality? This not a jab at cpu(1) rather at the design of notes. My personal feeling when going over that bit was: well, that's how UNIX people do signal forwarding (we do something similar for the remote debugging sessions) am I reading the right source file?!?! Thanks, Roman. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] success with 9vx from a terminal 2008-11-10 22:50 ` Roman V. Shaposhnik @ 2008-11-10 23:14 ` ron minnich 2008-11-10 23:42 ` andrey mirtchovski 1 sibling, 0 replies; 26+ messages in thread From: ron minnich @ 2008-11-10 23:14 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs cpu is just great tutorial. notes forwarder, well, I am stil unsure. ron ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] success with 9vx from a terminal 2008-11-10 22:50 ` Roman V. Shaposhnik 2008-11-10 23:14 ` ron minnich @ 2008-11-10 23:42 ` andrey mirtchovski 2008-11-11 0:42 ` Roman V. Shaposhnik 1 sibling, 1 reply; 26+ messages in thread From: andrey mirtchovski @ 2008-11-10 23:42 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > ... would you really honestly say that rolling out your > own notes forwarder is a *neat* trick? As opposed to > be able to use basic system's FS functionality? ok, how would you implement it, then? how would you deliver a note to a process that's running on a remote machine? would you be introducing "distributed" notes in which you can specify a target machine as well as a target process? with special agents on the local host which can "dial" the remote machine to send it the note, and kernel daemon note forwarders which can accept notes from remote machines destined for local processes and... and.. you run up the list of necessary (and required) services as quickly as portmap, rpc.idmapd and friends from nfs-land :) rmnoteproc() as implemented in cpu.c is just about the simplest way to do such a thing. it only requires one thing: the remote tree mounted in /mnt/term (which really is the clever bit). unfortunately we've been dealing with complexity in the non-plan9 world for so long that we are unable to appreciate anything unless it requires a huge deal of effort to comprehend :) ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] success with 9vx from a terminal 2008-11-10 23:42 ` andrey mirtchovski @ 2008-11-11 0:42 ` Roman V. Shaposhnik 2008-11-11 1:04 ` andrey mirtchovski 0 siblings, 1 reply; 26+ messages in thread From: Roman V. Shaposhnik @ 2008-11-11 0:42 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Mon, 2008-11-10 at 16:42 -0700, andrey mirtchovski wrote: > > ... would you really honestly say that rolling out your > > own notes forwarder is a *neat* trick? As opposed to > > be able to use basic system's FS functionality? > > ok, how would you implement it, then? how would you deliver a note to > a process that's running on a remote machine? I would like to be able to import the /proc (or similar) filesystem from the remote machine and bind it over the files that my local kernel uses to send notes to the proxy process. That's how my "ideal world" model would work. Observe how that was also the first suggestion on the "notes thief" thread. Do you think it is a coincidence? > would you be introducing "distributed" notes in which you can specify a > target machine as well as a target process? Of course not! But I still would like *not* to be forced to invent a covert channel for things that really seem to belong to a devproc.c. Look, seriously, when cpu(1) is run inside a rio window the only reason it has to jump through these hoops is because rio sends notes using a notepg file located in a completely unrelated subdirectory in /proc. I'm not saying I know of a better way as of right now, all I'm saying is that notes and how the group of processes is handled by the Plan9 kernel feels much less elegant than the rest of the system. > rmnoteproc() as implemented in cpu.c is just about the simplest way to > do such a thing. Given the constraints that I now understand notes require -- yes. But, honestly, don't you feel weird that /dev/cons gets proxied by a simple bind operation and notes are *the only* part of the system that need special handling? > it only requires one thing: the remote tree mounted in /mnt/term (which really > is the clever bit). Well it is the kind of cleverness that 9fans tend to dislike in other systems. Thanks, Roman. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] success with 9vx from a terminal 2008-11-11 0:42 ` Roman V. Shaposhnik @ 2008-11-11 1:04 ` andrey mirtchovski 2008-11-11 16:47 ` ron minnich 0 siblings, 1 reply; 26+ messages in thread From: andrey mirtchovski @ 2008-11-11 1:04 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > I would like to be able to import the /proc (or similar) filesystem from > the remote machine and bind it over the files that my local kernel uses > to send notes to the proxy process. That's how my "ideal world" model > would work. Observe how that was also the first suggestion on the "notes > thief" thread. Do you think it is a coincidence? if /proc is your only concern ask Jim or somebody else at BL to release the description of the original (plan9-only) cut of XCPU by Vic Zandy. I can't find my copy of it anymore and I don't remember if that information was releasable or not, but in short it was a modified p9 kernel that allowed you to start and control processes on multiple cpu servers at the same time. I don't remember if the solution for note sending across machines was novel. I seem to remember that in this case processes were addressed by node/pid. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] success with 9vx from a terminal 2008-11-11 1:04 ` andrey mirtchovski @ 2008-11-11 16:47 ` ron minnich 0 siblings, 0 replies; 26+ messages in thread From: ron minnich @ 2008-11-11 16:47 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Mon, Nov 10, 2008 at 5:04 PM, andrey mirtchovski <mirtchovski@gmail.com> wrote: > I don't remember if the solution for note sending across machines was > novel. I seem to remember that in this case processes were addressed > by node/pid. > > I've got it somewhere, will rummage around. ron ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] success with 9vx from a terminal 2008-11-10 22:24 ` Roman V. Shaposhnik 2008-11-10 22:49 ` ron minnich @ 2008-11-10 23:27 ` erik quanstrom 2008-11-12 4:10 ` Roman Shaposhnik 1 sibling, 1 reply; 26+ messages in thread From: erik quanstrom @ 2008-11-10 23:27 UTC (permalink / raw) To: 9fans > At least in case of cpu(1) the magic is a bit perverse and quite > unlike the rest of the system. The way notes are managed make > a local end of a cpu(1) jump through considerable hoops in order > for the notes to be properly delivered. That was a sad discovery. > > Another discovery was that devcons.c could have made DEL work > but decided not to :-( talking about it is the easy part. why don't you code something up? - erik ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [9fans] success with 9vx from a terminal 2008-11-10 23:27 ` erik quanstrom @ 2008-11-12 4:10 ` Roman Shaposhnik 0 siblings, 0 replies; 26+ messages in thread From: Roman Shaposhnik @ 2008-11-12 4:10 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Nov 10, 2008, at 3:27 PM, erik quanstrom wrote: >> At least in case of cpu(1) the magic is a bit perverse and quite >> unlike the rest of the system. The way notes are managed make >> a local end of a cpu(1) jump through considerable hoops in order >> for the notes to be properly delivered. That was a sad discovery. >> >> Another discovery was that devcons.c could have made DEL work >> but decided not to :-( > > talking about it is the easy part. why don't you code something up? Good question. I guess the easiest way to explain would be that I am not actually using Plan9 for anything as a standalone system, but rather as a source of inspiration (yeah, may be it is lame to say something like that -- but here I'm saying it anyway). Everytime I have to implement something for Solaris/Linux I usually take a look (unless I remember) at how similar things were handled by Plan9. Most of the things I've looked at are true gems in terms of ideas and coding. Really, really elegant stuff. A small number of things, however, make me go "Huh?". Which is, usually, a sign of me not being smart enough to instantly recognize the constraints these things are dealing with. But how am I to know for certain that they are not the rarest case of an oversight? One way would be, as you suggested, to start hacking things up and coming up with better solution. I suspect that in 90% of the cases I would end up fully appreciating why it was coded the way it was. That would be the .u way ;-) Very rewarding, but also quite time consuming. Another way (which I try NOT to abuse) is to talk about it here. In the hopes that even if I'm making a total fool out of myself there will be somebody idle enough to quickly enlighten me. Does that sound fair to you? Thanks, Roman. P.S. I would love to have any project related to Plan9/Inferno proper as my day job, but right now I'm reduced to UNIX and 9P at best :-( ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2008-11-12 4:10 UTC | newest] Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-10-22 11:42 [9fans] success with 9vx from a terminal erik quanstrom 2008-10-22 12:25 ` roger peppe 2008-10-22 14:22 ` john 2008-10-22 16:28 ` erik quanstrom 2008-10-22 16:35 ` Roman V. Shaposhnik [not found] <0bff7fbe9fa7f6b6305adedeba12e019@quanstro.net> 2008-10-22 12:01 ` Christian Kellermann -- strict thread matches above, loose matches on Subject: below -- 2008-10-22 9:15 gdiaz 2008-10-22 9:18 ` Christian Kellermann 2008-10-22 8:35 Chris Brannon 2008-10-22 16:54 ` andrey mirtchovski 2008-10-22 17:56 ` andrey mirtchovski 2008-10-22 17:56 ` erik quanstrom 2008-10-22 18:52 ` andrey mirtchovski 2008-10-22 23:43 ` Roman V. Shaposhnik 2008-11-09 16:55 ` sqweek 2008-11-09 20:50 ` Charles Forsyth 2008-11-10 22:24 ` Roman V. Shaposhnik 2008-11-10 22:49 ` ron minnich 2008-11-10 22:50 ` Roman V. Shaposhnik 2008-11-10 23:14 ` ron minnich 2008-11-10 23:42 ` andrey mirtchovski 2008-11-11 0:42 ` Roman V. Shaposhnik 2008-11-11 1:04 ` andrey mirtchovski 2008-11-11 16:47 ` ron minnich 2008-11-10 23:27 ` erik quanstrom 2008-11-12 4:10 ` Roman Shaposhnik
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).