[9fans] P9p on Fedora 12

[9fans] P9p on Fedora 12

[Pavel Klinkovsky]

Hi all,

I use p9p on my older Linux (Fedora 10).
I tried to compile and run it on my new PC with Fedora 12, but without
success:

[pavel]$ 9term rc
usage: devdraw (don't run  directly)
9term: initdraw: muxrpc: unexpected eof

Any idea?

Thanks.

Pavel

Re: [9fans] P9p on Fedora 12

[Pavel Klinkovsky]

> usage: devdraw (don't run  directly)
> 9term: initdraw: muxrpc: unexpected eof

No one other experiencing this problem?

Pavel

Re: [9fans] P9p on Fedora 12

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 430 bytes --]

On Wed, Feb 24, 2010 at 2:13 AM, Pavel Klinkovsky <
pavel.klinkovsky@gmail.com> wrote:

> > usage: devdraw (don't run  directly)
> > 9term: initdraw: muxrpc: unexpected eof
>
> No one other experiencing this problem?
>
> Pavel
>
>
I've not rebuilt on my mac in a while.  I'll try again today, but I don't
like to run Fedora in general.  I typically like archlinux these days, as
it's small and fairly sane.

Dave

[-- Attachment #2: Type: text/html, Size: 768 bytes --]

Re: [9fans] P9p on Fedora 12

[Pavel Klinkovsky]

> I'll try again today, but I don't
> like to run Fedora in general.  I typically like archlinux these days, as
> it's small and fairly sane.
Strange, I tried to compile p9p on the latest (9.10) Ubuntu, and no
success too.

Pavel

Re: [9fans] P9p on Fedora 12

[Gabriel Díaz]

hello

It works here. Below is the output of the process. did you 
get more errors when running INSTALL script?

slds.

gabi

gdiaz@m9363:~$ lsb_release -a
LSB Version:    core-2.0-ia32:core-2.0-noarch:
core-3.0-ia32:core-3.0-noarch:core-3.1-ia32:core-3.1-noarch:core-3.2-ia32:core-3.2-noarch:core-4.0-ia32:core-4.0-noarch:cxx-3.0-ia32:cxx-3.0-noarch:cxx-3.1-ia32:cxx-3.1-noarch:cxx-3.2-ia32:cxx-3.2-noarch:cxx-4.0-ia32:cxx-4.0-noarch:desktop-3.1-ia32:desktop-3.1-noarch:desktop-3.2-ia32:desktop-3.2-noarch:desktop-4.0-ia32:desktop-4.0-noarch:graphics-2.0-ia32:graphics-2.0-noarch:graphics-3.0-ia32:graphics-3.0-noarch:graphics-3.1-ia32:graphics-3.1-noarch:graphics-3.2-ia32:graphics-3.2-noarch:graphics-4.0-ia32:graphics-4.0-noarch:qt4-3.1-ia32:qt4-3.1-noarch
Distributor ID:    Ubuntu
Description:    Ubuntu 9.10
Release:    
9.10
Codename:    karmic
gdiaz@m9363:~$ cd plan9
gdiaz@m9363:~/plan9$ hg pull
real URL is http://code.swtch.com/plan9port/
pulling from http://code.swtch.com/plan9port
searching for changes
no changes found
gdiaz@m9363:~/plan9$ ./INSTALL
+ 
Mailing list: http://groups.google.com/group/plan9port-dev
+ Issue tracker: http://code.swtch.com/plan9port/issues/
+ 
Submitting changes: http://swtch.com/go/codereview
 
* Resetting 
/home/gdiaz/plan9/config
* Compiler version:
    gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9) 
* Running on Linux: checking for NPTL...
    NPTL found.
* Building everything (be patient)...
>>> cd 
/home/gdiaz/plan9/src/lib9; mk all                  
9c  _p9dialparse.c
_p9dialparse.c:74: warning: dereferencing 
type-punned pointer will break strict-aliasing rules
>>> cd 
/home/gdiaz/plan9/src/lib9; mk all
9c  sendfd.c
sendfd.c:49: 
warning: dereferencing type-punned pointer will break strict-aliasing 
rules
sendfd.c:86: warning: dereferencing type-punned pointer will break 
strict-aliasing rules
>>> cd /home/gdiaz/plan9/src/lib9; mk 
all
9c  truerand.c
truerand.c:24: warning: dereferencing 
type-punned pointer will break strict-aliasing rules
>>> cd /home/gdiaz/plan9/src/libauthsrv; mk all
9c  
readnvram.c
readnvram.c:166: warning: dereferencing type-punned 
pointer will break strict-aliasing rules
>>> cd 
/home/gdiaz/plan9/src/libavl; mk all
9c  avl.c
avl.c:215: warning: ‘checkparents’ defined but not used
avl.c:407: warning: ‘walkavl’ defined but not used
>>> cd 
/home/gdiaz/plan9/src/libip; mk all   
9c  udp.c
udp.c:25: 
warning: dereferencing type-punned pointer will break strict-aliasing 
rules
udp.c:37: warning: dereferencing type-punned pointer will break 
strict-aliasing rules
udp.c:50: warning: dereferencing type-punned 
pointer will break strict-aliasing rules
>>> cd 
/home/gdiaz/plan9/src/libmach; mk all
9c -I. Linux.c
Linux.c:149: warning: dereferencing type-punned 
pointer will break strict-aliasing rules
Linux.c:160: warning: 
dereferencing type-punned pointer will break strict-aliasing rules
Linux.c:162: warning: dereferencing type-punned pointer will break strict-aliasing 
rules
>>> cd /home/gdiaz/plan9/src/libmemdraw; mk all
9c  
draw.c
draw.c:2201: warning: dereferencing type-punned pointer will 
break strict-aliasing rules
draw.c:2216: warning: dereferencing 
type-punned pointer will break strict-aliasing rules
draw.c:2447: warning: dereferencing type-punned pointer will break 
strict-aliasing rules
draw.c:2473: warning: dereferencing type-punned pointer will break strict-aliasing rules
draw.c:2540: warning: 
dereferencing type-punned pointer will break strict-aliasing rules
>>> cd /home/gdiaz/plan9/src/cmd/acid; mk all
9c  
expr.c
expr.c:858: warning: ‘l’ is used uninitialized in this 
function
>>> cd /home/gdiaz/plan9/src/cmd/db; mk all        
9c  format.c
format.c:209: warning: dereferencing pointer ‘sp’ does 
break strict-aliasing rules
format.c:208: note: initialized from here
>>> cd 
/home/gdiaz/plan9/src/cmd/vbackup; mk all         
9c  vnfs.c
vnfs.c:326: warning: dereferencing type-punned pointer will break strict-aliasing 
rules
vnfs.c:808: warning: dereferencing type-punned pointer will 
break strict-aliasing rules
vnfs.c:845: warning: dereferencing type-punned pointer will break 
strict-aliasing rules
* Installing everything in 
/home/gdiaz/plan9/bin...
* Cleaning up...                                             
* Renaming hard-coded /usr/local/plan9 paths...            
* Building web manual...
* Done.                           
    
* Add these to your profile environment.
    
PLAN9=/home/gdiaz/plan9 export PLAN9
    PATH=$PATH:$PLAN9/bin export PATH
gdiaz@m9363:~/plan9$ 
gdiaz@m9363:~/plan9$ PLAN9=/home/gdiaz/plan9 export PLAN9
gdiaz@m9363:~/plan9$ PATH=$PATH:$PLAN9/bin export PATH
gdiaz@m9363:~/plan9$ 9term rc



----- Mensaje original ----
De: Pavel Klinkovsky <pavel.klinkovsky@gmail.com>
Para: 9fans@9fans.net
Enviado: lun,1 marzo, 2010 10:49
Asunto: Re: [9fans] P9p on Fedora 12

> I'll try again today, but I don't
> like to run Fedora in general. Â I typically like archlinux these days, as
> it's small and fairly sane.
Strange, I tried to compile p9p on the latest (9.10) Ubuntu, and no
success too.

Pavel

Re: [9fans] P9p on Fedora 12

[Pavel Klinkovsky]

Sorry, I was not precise enough.
The compilation itself succeeds but I cannot rung 9term:

[pavel]$ 9term rc
usage: devdraw (don't run  directly)
9term: initdraw: muxrpc: unexpected eof

I must do something wrong but I do not know what...?

Pavel

Re: [9fans] P9p on Fedora 12

[Gabriel Díaz]

hello

i can reproduce that with:

gdiaz@m9363:~/plan9/src/cmd/
devdraw$ echo $DISPLAY

gdiaz@m9363:~/plan9/src/cmd/devdraw$ 9term
9term: initdraw: muxrpc: unexpected eof
gdiaz@m9363:~/plan9/src/cmd/devdraw$ 

so, can you use other programs X programs?
do you have a DISPLAY 
variable? 
are you trying to execute 9term using ssh x11 forwarding?

may be devdraw does not use the x11 library which does the trick with ssh? i think ssh does not set the display variable, and still the normal X 
programs works due some trickery on a x11 proxy library :?

slds.

gabi



----- Mensaje original ----
De: Pavel Klinkovsky <pavel.klinkovsky@gmail.com>
Para: 9fans@9fans.net
Enviado: lun,1 marzo, 2010 13:11
Asunto: Re: [9fans] P9p on Fedora 12

Sorry, I was not precise enough.
The compilation itself succeeds but I cannot rung 9term:

[pavel]$ 9term rc
usage: devdraw (don't run  directly)
9term: initdraw: muxrpc: unexpected eof

I must do something wrong but I do not know what...?

Pavel

Re: [9fans] P9p on Fedora 12

[erik quanstrom]

> i can reproduce that with:
>
> gdiaz@m9363:~/plan9/src/cmd/devdraw$ 9term
> 9term: initdraw: muxrpc: unexpected eof
> gdiaz@m9363:~/plan9/src/cmd/devdraw$

you've reproduced the result, but i think the
conditions are different.  pavel's error was:

> [pavel]$ 9term rc
> usage: devdraw (don't run  directly)

- erik

Re: [9fans] P9p on Fedora 12

[Gabriel Díaz]

hello

my mistake, anyway i think the test might help

slds.

gabi




----- Mensaje original ----
De: erik quanstrom <quanstro@quanstro.net>
Para: 9fans@9fans.net
Enviado: lun,1 marzo, 2010 13:56
Asunto: Re: [9fans] P9p on Fedora 12

> i can reproduce that with:
> 
> gdiaz@m9363:~/plan9/src/cmd/devdraw$ 9term
> 9term: initdraw: muxrpc: unexpected eof
> gdiaz@m9363:~/plan9/src/cmd/devdraw$ 

you've reproduced the result, but i think the
conditions are different.  pavel's error was:

> [pavel]$ 9term rc
> usage: devdraw (don't run  directly)

- erik

Re: [9fans] P9p on Fedora 12

[Pavel Klinkovsky]

> pavel's error was:
> > [pavel]$ 9term rc
> > usage: devdraw (don't run  directly)

That is true.
But muxrpc error is also there. A consequence?

[pavel]$ 9term rc
usage: devdraw (don't run  directly)
9term: initdraw: muxrpc: unexpected eof

Pavel

Re: [9fans] P9p on Fedora 12

[erik quanstrom]

> That is true.
> But muxrpc error is also there. A consequence?
>
> [pavel]$ 9term rc
> usage: devdraw (don't run  directly)
> 9term: initdraw: muxrpc: unexpected eof

dennis was right.  print statements are often the best way
to debug a problem.

why don't you temporarly hack devdraw with something
like the following in main before ARGBEGIN

fprint(2, "devdraw args: "
for(int i = 0; i < argc; i+)
	fprint(2, "%s ", argv[i]);
fprint(2, "\n");

perhaps this output will give you some more ideas.
if you're a bit unfamiliar with the code (or just don't
remember), the second best debugging tool is grep.
i don't immediately recall, but i would imagine that
libdraw is starting devdraw.

i suspect a well-executed pincer manover with print
and grep will quickly rout this bug.

- erik

Re: [9fans] P9p on Fedora 12

[Pavel Klinkovsky]

Hello,

> so, can you use other programs X programs?
Yes, I can (e.g. gedit).


> do you have a DISPLAY variable?
Yes, I have:
[pavel@localhost ~]$ echo $DISPLAY
:0.0

> are you trying to execute 9term using ssh x11 forwarding?
No.

Pavel

Re: [9fans] P9p on Fedora 12

[Gabriel Díaz]

hello

if you inspect your install.log can you see something like this when compiling devdraw?
(I'm supposing this is ubuntu 9.10 which is the same i have here, and that you have the latest tree of plan9ports, and that you have the x11 devel libraries, etc.)

cd /home/gdiaz/plan9/src/cmd/devdraw; mk all
9c -I/usr/include mklatinkbd.c
9l -o o.mklatinkbd mklatinkbd.o
./o.mklatinkbd -r $PLAN9/lib/keyboard | sed 's/, }/ }/' >latin1.h
9c -I/usr/include latin1.c
9c -I/usr/include devdraw.c
9c -I/usr/include mouseswap.c
9c -I/usr/include winsize.c
9c -I/usr/include x11-alloc.c
9c -I/usr/include x11-cload.c
9c -I/usr/include x11-draw.c
9c -I/usr/include x11-fill.c
9c -I/usr/include x11-get.c
9c -I/usr/include x11-init.c
9c -I/usr/include x11-itrans.c
9c -I/usr/include x11-keysym2ucs.c
9c -I/usr/include x11-load.c
9c -I/usr/include x11-pixelbits.c
9c -I/usr/include x11-srv.c
9c -I/usr/include x11-unload.c
9c -I/usr/include x11-wsys.c
9l -o o.devdraw devdraw.o latin1.o mouseswap.o winsize.o x11-alloc.o x11-cload.o x11-draw.o x11-fill.o x11-get.o x11-init.o x11-itrans.o x11-keysym2ucs.o x11-load.o x11-pixelbits.o x11-srv.o x11-unload.o x11-wsys.o

slds.

gabi



----- Mensaje original ----
De: Pavel Klinkovsky <pavel.klinkovsky@gmail.com>
Para: 9fans@9fans.net
Enviado: lun,1 marzo, 2010 14:19
Asunto: Re: [9fans] P9p on Fedora 12

Hello,

> so, can you use other programs X programs?
Yes, I can (e.g. gedit).


> do you have a DISPLAY variable?
Yes, I have:
[pavel@localhost ~]$ echo $DISPLAY
:0.0

> are you trying to execute 9term using ssh x11 forwarding?
No.

Pavel

Re: [9fans] P9p on Fedora 12

[fgergo]

I haven't found any resolution to Pavel's original problem, hence this email.

Same problem here:
x86, FC12: INSTALL went smooth (no errors in install.log), but all of
the devdraw based programs stopped with the reported error.

After installing the packages libX11-devel, libXt-devel and
libXext-devel, INSTALL produced the expected result, all programs work
correctly.

I noticed that, the references to LOCAL.config and nowsys in
install(1) are somehow not clear to me. I could not find out how
nowsys was built instead of reporting the missing X11 libraries and I
couldn't find LOCAL.config either.

On Mon, Feb 22, 2010 at 11:56 AM, Pavel Klinkovsky
<pavel.klinkovsky@gmail.com> wrote:
> Hi all,
>
> I use p9p on my older Linux (Fedora 10).
> I tried to compile and run it on my new PC with Fedora 12, but without
> success:
>
> [pavel]$ 9term rc
> usage: devdraw (don't run  directly)
> 9term: initdraw: muxrpc: unexpected eof
>
> Any idea?
>
> Thanks.
>
> Pavel
>
>

Re: [9fans] P9p on Fedora 12

[erik quanstrom]

while you're at it, more new p9p bugs.  after "upgrading"
my linux box,
1.  <insert> in acme on a string like /usr/quanstro/src/
inserts another / for each keypress.
2.  passwords are echoed by 9term
3.  9term still rechoes its input:
	; echo 9term
	echo 9term
	9term

- erik

Re: [9fans] P9p on Fedora 12

[Russ Cox]

> 1.  <insert> in acme on a string like /usr/quanstro/src/
> inserts another / for each keypress.

I don't know what this means.
Acme has no <insert>.
I haven't seen this.

> 2.  passwords are echoed by 9term
> 3.  9term still rechoes its input:
>        ; echo 9term
>        echo 9term
>        9term

These are variants of the same bug.
I've been seeing it on Ubuntu Lucid too.
If you or anyone would like to hunt down
what's changed in the tty settings and
how to fix it, I'd gladly accept a patch.
When I first saw it I spent a while running
stty commands but to no avail, so I've
been putting up with the echoing, but I'd
love to get it fixed.

Thanks.
Russ

Re: [9fans] P9p on Fedora 12

[erik quanstrom]

On Mon Aug 30 07:22:48 EDT 2010, rsc@swtch.com wrote:
> > 1.  <insert> in acme on a string like /usr/quanstro/src/
> > inserts another / for each keypress.
>
> I don't know what this means.
> Acme has no <insert>.
> I haven't seen this.

oh, sure it does.

/mnt/term/usr/quanstro/plan9/src/cmd/acme/text.c:792,799
	switch(r){
	case 0x06:	/* ^F: complete */
	case Kins:
		rp = textcomplete(t);
		if(rp == nil)
			return;
		nr = runestrlen(rp);
		break;	/* fall through to normal insertion case */

oddly¸ i see that the arm port has exactly the same bug.

- erik

Re: [9fans] P9p on Fedora 12

[erik quanstrom]

On Mon Aug 30 07:41:18 EDT 2010, quanstro@quanstro.net wrote:
> On Mon Aug 30 07:22:48 EDT 2010, rsc@swtch.com wrote:
> > > 1.  <insert> in acme on a string like /usr/quanstro/src/
> > > inserts another / for each keypress.
> >
> > I don't know what this means.
> > Acme has no <insert>.
> > I haven't seen this.
>
> oh, sure it does.
>
> /mnt/term/usr/quanstro/plan9/src/cmd/acme/text.c:792,799
> 	switch(r){
> 	case 0x06:	/* ^F: complete */
> 	case Kins:
> 		rp = textcomplete(t);
> 		if(rp == nil)
> 			return;
> 		nr = runestrlen(rp);
> 		break;	/* fall through to normal insertion case */
>
> oddly¸ i see that the arm port has exactly the same bug.

sorry, i take it back.  drawterm also has the same bug.

there are several timing bugs, but often what i see
is the +Errors window opening up with just a /
in the body.  (but sometimes the / is inserted in
the original space.)  Undo in +Errors yields the normal
completion list.  texttype() really does get
Kins then '/'.

it turns out that x helpfully yields this if i hold down
the insert key
	<insert>//////////////////////////////////////////////

x has a brand new bug.

modern linux systems can be a good example of how better can be
the opposite of working.

- erik

Re: [9fans] P9p on Fedora 12

[Skip Tavakkolian]

What works for me is putting 9term in raw mode and then stty -echo.

Sent from my iPhone

On Aug 30, 2010, at 4:20 AM, Russ Cox <rsc@swtch.com> wrote:

>> 1.  <insert> in acme on a string like /usr/quanstro/src/
>> inserts another / for each keypress.
>
> I don't know what this means.
> Acme has no <insert>.
> I haven't seen this.
>
>> 2.  passwords are echoed by 9term
>> 3.  9term still rechoes its input:
>>        ; echo 9term
>>        echo 9term
>>        9term
>
> These are variants of the same bug.
> I've been seeing it on Ubuntu Lucid too.
> If you or anyone would like to hunt down
> what's changed in the tty settings and
> how to fix it, I'd gladly accept a patch.
> When I first saw it I spent a while running
> stty commands but to no avail, so I've
> been putting up with the echoing, but I'd
> love to get it fixed.
>
> Thanks.
> Russ
>

Re: [9fans] P9p on Fedora 12

[erik quanstrom]

On Mon Aug 30 12:20:30 EDT 2010, skip.tavakkolian@gmail.com wrote:
> What works for me is putting 9term in raw mode and then stty -echo.
>

if you then edit a line, like this
(^ for tick)

	; echo pdq^
	; echo ^pdq
	; echo xyz^pdq
	; echo xyz^pdq<cr>

does it echo xyzpdq or pdqxyz?

i'm guessing the (incorrect) latter.  iirc
i tried this approach on linux and it doesn't
work.

-erik

Re: [9fans] P9p on Fedora 12

[Skip Tavakkolian]

I gave the wrong mode. If you put 9term in "cooked" mode and stty
-echo then (interacting with rc), the
example below will echo the "xyz".  The "pdq" is placed on the
following line with cursor placed at '^'.
this is identical behavior to a rio window.

cpue% echo xyz
xyz
cpue% ^pdq

% uname -a
Linux ubuntu 2.6.32-24-generic #41-Ubuntu SMP Thu Aug 19 01:12:52 UTC
2010 i686 GNU/Linux
% echo xyz
xyz
% ^pdq

On Mon, Aug 30, 2010 at 10:47 AM, erik quanstrom
<quanstro@labs.coraid.com> wrote:
> On Mon Aug 30 12:20:30 EDT 2010, skip.tavakkolian@gmail.com wrote:
>> What works for me is putting 9term in raw mode and then stty -echo.
>>
>
> if you then edit a line, like this
> (^ for tick)
>
>        ; echo pdq^
>        ; echo ^pdq
>        ; echo xyz^pdq
>        ; echo xyz^pdq<cr>
>
> does it echo xyzpdq or pdqxyz?
>
> i'm guessing the (incorrect) latter.  iirc
> i tried this approach on linux and it doesn't
> work.
>
> -erik
>

Re: [9fans] P9p on Fedora 12

[Russ Cox]

On Mon, Aug 30, 2010 at 2:53 PM, Skip Tavakkolian
<skip.tavakkolian@gmail.com> wrote:
> I gave the wrong mode. If you put 9term in "cooked" mode and stty
> -echo then (interacting with rc), the
> example below will echo the "xyz".  The "pdq" is placed on the
> following line with cursor placed at '^'.
> this is identical behavior to a rio window.

Yes but then sudo sh echoes your password.
9term used to be able to figure out the right thing
to do (it polls the tty state at each keystroke)
and no longer does.

Russ

Re: [9fans] P9p on Fedora 12

[Charles Forsyth]

in rcinputproc
		s = setecho(sfd, 0);
		if(write(rcfd, pair.s, pair.ns) < 0)
			threadexitsall(nil);
		if(s)
			setecho(sfd, s);

there's a race between setting echo off, writing to rcfd, resetting echo and
the reader of the other side of rcfd. a sleep(1) before if(s) makes it less frequent
because the reader gets to read the data in the right mode.
i haven't really looked at what linux is doing that allows that,
or what changed between revisions.

it's not my observation, it was on a list or issue comment somewhere,
presumably for p9p. i can't find the bookmark.

Re: [9fans] P9p on Fedora 12

[Russ Cox]

On Mon, Aug 30, 2010 at 7:22 PM, Charles Forsyth <forsyth@terzarima.net> wrote:
> in rcinputproc
>                s = setecho(sfd, 0);
>                if(write(rcfd, pair.s, pair.ns) < 0)
>                        threadexitsall(nil);
>                if(s)
>                        setecho(sfd, s);
>
> there's a race between setting echo off, writing to rcfd, resetting echo and
> the reader of the other side of rcfd. a sleep(1) before if(s) makes it less frequent
> because the reader gets to read the data in the right mode.
> i haven't really looked at what linux is doing that allows that,
> or what changed between revisions.
>
> it's not my observation, it was on a list or issue comment somewhere,
> presumably for p9p. i can't find the bookmark.

thanks for this.  sleep(1) helped only rarely,
sleep(10) helps most of the time.  unfortunately
then there's a race between the invoked program
turning off echo and 9term turning it back on.
so "sudo sh" is pretty likely to echo the password
with the sleep in there.

what a mess.

russ

Re: [9fans] P9p on Fedora 12

[Russ Cox]

> thanks for this.  sleep(1) helped only rarely,
> sleep(10) helps most of the time.  unfortunately
> then there's a race between the invoked program
> turning off echo and 9term turning it back on.
> so "sudo sh" is pretty likely to echo the password
> with the sleep in there.
>
> what a mess.

i just submitted some code that should clean up
the mess.  it does active echo cancellation on its
own, instead of trying to coerce the tty into doing it.

the changes also make win behave the same
way as 9term: if you've done "stty echo" then
you can edit with the mouse, but if not, you can't.
so running "su" doesn't show a password anymore
in win, but you can't use the mouse to edit in an
interactive python session.  win some, lose some.

russ

Re: [9fans] P9p on Fedora 12

[roger peppe]

On 3 September 2010 15:25, Russ Cox <rsc@swtch.com> wrote:
> [...] but you can't use the mouse to edit in an
> interactive python session.  win some, lose some.

to get around this, i start up python with a script, py:

#!/bin/rc
PYTHONSTARTUP=$HOME/lib/pythonstartup
cat | python -i $*

where $HOME/lib/pythonstartup holds this, to stop
the secondary prompt getting in the way after leaving hold
mode:

import sys
sys.ps1 = '> '
sys.ps2 = ''

Re: [9fans] P9p on Fedora 12

[Russ Cox]

On Mon, Aug 30, 2010 at 12:09 PM, Skip Tavakkolian
<skip.tavakkolian@gmail.com> wrote:
> What works for me is putting 9term in raw mode and then stty -echo.

But I swear there used to be a way to make it work
in cooked mode, so that I can edit the command lines
before hitting enter.  On my Mac's 9term, I can still type

echo world

and then mouse to the middle, insert "hello", mouse to
the end, hit enter, and I get "hello world".  But it still
doesn't echo passwords.

Something changed in Lucid but I have no idea what.

Russ

Re: [9fans] P9p on Fedora 12

[Pavel Klinkovsky]

> 3.  9term still rechoes its input:
>         ; echo 9term
>         echo 9term
>         9term
I can confirm that:
- P9p on Fedora 10 does not echo the input,
- P9p on Fedora 12 (13) echoes the input.

Pavel

Re: [9fans] P9p on Fedora 12

[Russ Cox]

> I can confirm that:
> - P9p on Fedora 10 does not echo the input,
> - P9p on Fedora 12 (13) echoes the input.

Are you using the latest version of 9term?

cd $PLAN9
hg log -l 1 src/cmd/9term

Russ

Re: [9fans] P9p on Fedora 12

[Ethan Grammatikidis]

On 6 Sep 2010, at 9:08 pm, Russ Cox wrote:

>> I can confirm that:
>> - P9p on Fedora 10 does not echo the input,
>> - P9p on Fedora 12 (13) echoes the input.
>
> Are you using the latest version of 9term?
>
> cd $PLAN9
> hg log -l 1 src/cmd/9term
>
> Russ
>

That reminds me, a p9p install in which 9term was not echoing input
under OS X echoes input under slackware. Same source tree, just re-
INSTALLed. I intended to hg up before posting about it, I'll do that
now.

Re: [9fans] P9p on Fedora 12

[Ethan Grammatikidis]

On 6 Sep 2010, at 10:48 pm, Ethan Grammatikidis wrote:

>
> On 6 Sep 2010, at 9:08 pm, Russ Cox wrote:
>
>>> I can confirm that:
>>> - P9p on Fedora 10 does not echo the input,
>>> - P9p on Fedora 12 (13) echoes the input.
>>
>> Are you using the latest version of 9term?
>>
>> cd $PLAN9
>> hg log -l 1 src/cmd/9term
>>
>> Russ
>>
>
> That reminds me, a p9p install in which 9term was not echoing input
> under OS X echoes input under slackware. Same source tree, just re-
> INSTALLed. I intended to hg up before posting about it, I'll do
> that now.
>

Fixed for me after hg update. (Slackware 13.1, Linux 2.6.35.4)

Re: [9fans] P9p on Fedora 12

[Pavel Klinkovsky]

> > I can confirm that:
> > - P9p on Fedora 10 does not echo the input,
> > - P9p on Fedora 12 (13) echoes the input.
>
> Are you using the latest version of 9term?
>
Delay along the path...
I inserted this report one week ago (before you patched the
problem). :-/

Now it works fine. Thanks.

Pavel

[9fans] [plan9mod] Re: P9p on Fedora 12

[Pavel Klinkovsky]

> I haven't found any resolution to Pavel's original problem, hence this email.
I am sorry I forgot to write the solution here.
As expected, the problem was between my keyboard and chair... ;-)

> After installing the packages libX11-devel, libXt-devel and
> libXext-devel, INSTALL produced the expected result, all programs work
> correctly.
This was my mistake.
I forgot to install *-devel libraries.

Pavel