Re: [9fans] pipefile

Re: [9fans] pipefile

[rob pike]

> I think he was thinking of the v2 edition where, with ktrans, you
> could hit a ctrl seq and switch into different modes.  I assume that
> functionality was always part of ktrans itself, in other words after it's
> started it is always running and handles whether or not to do translation.

I thought the problem was not how to implement the translation, but
how to inject it into the input stream.  Thus I wrote pipefile, with
the belief that someone would write the obvious bytestream converter,
with or without modes, that would convert a standard keyboard into
some other style of input.

With pipefile, you can add any translation you want to /dev/cons.
The program you write - the argument to -r - can do anything it
wants, including switching between languages.  Unlike with /dev/kbd,
the mode won't be per window if you start it under rio, but you can
start it in each window instead, if that's really what you want.

/dev/kbd may seem more natural, but the idea that an arbitrary
program can wake up at any time and inject characters into my
input stream is too distasteful for me.  That's why I didn't put
/dev/kbd into rio, hoping something better (or at least safer)
would come along.

Pipefile may not be as convenient, but it's much safer because you
must explicitly create the process; there's nothing like /dev/kbd
hanging around ready to receive random characters.

-rob

Re: [9fans] pipefile

[okamoto]

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

I'm very happy to hear it.  

Yesterday, I went out from our Univ. after that success, because 
I was too happy to continue to sit down on the chair.  ☺

However, this is the success of Rob's idea not mine.

Kenji


[-- Attachment #2: Type: message/rfc822, Size: 2727 bytes --]

From: "Matt" <matt@proweb.co.uk>
To: <9fans@cse.psu.edu>
Subject: Re: [9fans] pipefile
Date: Thu, 3 Aug 2000 08:14:27 +0100
Message-ID: <009301bffd1a$7a022080$02a7b6c3@lucid.proweb.net>

> これは初めて release 3 Plan 9 + pipefile + acme + my version of ktrans
を使って書いているテスト
> メールです。日本語を読めない皆さまには御免なさい
> です。
>
> This is the first Japanese mail written under
> the release 3 Plan 9 + pipefile + acme + my
> version of ktrans.  Please forgive me if you
> don't want to read Japanese.
>
> Kenji

congratulations on your success

I *do* want to read japanese I just can't

it's not your fault

Matt

Re: [9fans] pipefile

[Boyd Roberts]

From: <okamoto@granite.cias.osakafu-u.ac.jp>
> When I input Japanese like below:
>
> term% 日本語の入力の練習です。<cr>
>
>

nihongo no? iri ka? no? ...

Re: [9fans] pipefile

[Matt]

> これは初めて release 3 Plan 9 + pipefile + acme + my version of ktrans
を使って書いているテスト
> メールです。日本語を読めない皆さまには御免なさい
> です。
>
> This is the first Japanese mail written under
> the release 3 Plan 9 + pipefile + acme + my
> version of ktrans.  Please forgive me if you
> don't want to read Japanese.
>
> Kenji

congratulations on your success

I *do* want to read japanese I just can't

it's not your fault

Matt

Re: [9fans] pipefile

[rob pike]

> >Could one stack pipefiles?
> No...

Why not?

% pipefile -w 'tr a-z A-Z' /dev/cons
% pipefile -w 'tr A-J 0-9' /dev/cons
% rc < /dev/cons > /dev/cons >[2] /dev/cons
% date
THU 0UG  3 00:48:13 43T 2000
% 

Re: [9fans] pipefile

[okamoto]

>/dev/kbd may seem more natural, but the idea that an arbitrary

Now I believe pipfile method is superior, because we can input
Japanese onto any window anytime.

>Pipefile may not be as convenient, 

Now, I believe it's not inconvenient.

>but it's much safer because you
>must explicitly create the process; there's nothing like /dev/kbd
>hanging around ready to receive random characters.

I still have problem to understand this.  In Plan 9, all the /dev
files are owned by hostowner which means s/he has superior
permission to key input anything.  I feel this is natural...

Kenji

Re: [9fans] pipefile

[okamoto]

これは初めて release 3 Plan 9 + pipefile + acme + my version of ktrans を使って書いているテスト
メールです。日本語を読めない皆さまには御免なさい
です。

This is the first Japanese mail written under
the release 3 Plan 9 + pipefile + acme + my 
version of ktrans.  Please forgive me if you 
don't want to read Japanese.

Kenji

Re: [9fans] pipefile

[okamoto]

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

This problem has been solved completely through discussions
between Russ.

Now I can input Japanese on this new plan 9 release.
Thank you very much Russ.

Kenji


[-- Attachment #2: Type: message/rfc822, Size: 5898 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 685 bytes --]

I'm using my version of ktrans to test this, where we can change
language.  Yes, this is true.  My point is that:

> When I input Japanese like below:
> 
> term% 日本語の入力の練習です。<cr>

I wanted to input Japanese text as a false command for rc shell, 
and then I expect shell will return with no such command etc. by 
hiiting Enter key.   However, it's still in raw mode, and I have no 
clue to return back to cooked mode, and recognize the meaning 
of newline.

Actually, I was also confused this nature of Enter key to newline 
conversion, whence my version had a serious bug for conversion 
from kana to kanji after hitting Enter key...

Kenji


[-- Attachment #2.1.2: Type: message/rfc822, Size: 3148 bytes --]

From: "James A. Robinson" <jim.robinson@stanford.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] pipefile
Date: Wed, 02 Aug 2000 08:49:40 -0700
Message-ID: <200008021549.LAA27375@cse.psu.edu>


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2.1.2.1: Type: text/plain; charset="x-unknown", Size: 664 bytes --]

From: "James A. Robinson" <jim.robinson@stanford.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] pipefile
Date: Wed, 02 Aug 2000 08:49:40 -0700
Message-ID: <200008021549.LAA27375@cse.psu.edu>

I think he was thinking of the v2 edition where, with ktrans, you
could hit a ctrl seq and switch into different modes.  I assume that
functionality was always part of ktrans itself, in other words after it's
started it is always running and handles whether or not to do translation.


> > When I input Japanese like below:
> > 
> > term% 日本語の入力の練習です。<cr>
> > 
> > 
> > I cannot now return to rc shell.
> 
> I don't understand.  Do you want just to enter one line of Japanese text?
> The idea was to switch the mode of /dev/cons permanently. I assumed
> your Japanese input methods could provide both ASCII and Japanese text.

Re: [9fans] pipefile

[Skip Tavakkolian]

At 08:40 PM 8/1/00 -0700, Skip Tavakkolian wrote:
>Could one stack pipefiles?

No, but one can pipeline the input and output filters.
(pipefile -w 'tr a-z A-Z | tr A-Z a-z' /dev/cons)

>
>Also, this may be a totally stupid question, but I am wondering why
>there never was a notation for bidirectional pipes in the shell
>(say '><') that sets this pipelining?
>

Upon reflection, that is a stupid question. (note to self: see pipe(3))

"We now return you to your regularly scheduled programming..."

Re: [9fans] pipefile

[okamoto]

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

I'm using my version of ktrans to test this, where we can change
language.  Yes, this is true.  My point is that:

> When I input Japanese like below:
> 
> term% 日本語の入力の練習です。<cr>

I wanted to input Japanese text as a false command for rc shell, 
and then I expect shell will return with no such command etc. by 
hiiting Enter key.   However, it's still in raw mode, and I have no 
clue to return back to cooked mode, and recognize the meaning 
of newline.

Actually, I was also confused this nature of Enter key to newline 
conversion, whence my version had a serious bug for conversion 
from kana to kanji after hitting Enter key...

Kenji


[-- Attachment #2: Type: message/rfc822, Size: 3148 bytes --]

From: "James A. Robinson" <jim.robinson@stanford.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] pipefile
Date: Wed, 02 Aug 2000 08:49:40 -0700
Message-ID: <200008021549.LAA27375@cse.psu.edu>


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2.1: Type: text/plain; charset="x-unknown", Size: 664 bytes --]

From: "James A. Robinson" <jim.robinson@stanford.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] pipefile
Date: Wed, 02 Aug 2000 08:49:40 -0700
Message-ID: <200008021549.LAA27375@cse.psu.edu>

I think he was thinking of the v2 edition where, with ktrans, you
could hit a ctrl seq and switch into different modes.  I assume that
functionality was always part of ktrans itself, in other words after it's
started it is always running and handles whether or not to do translation.


> > When I input Japanese like below:
> > 
> > term% 日本語の入力の練習です。<cr>
> > 
> > 
> > I cannot now return to rc shell.
> 
> I don't understand.  Do you want just to enter one line of Japanese text?
> The idea was to switch the mode of /dev/cons permanently. I assumed
> your Japanese input methods could provide both ASCII and Japanese text.

Re: [9fans] pipefile

[James A. Robinson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="x-unknown", Size: 668 bytes --]

I think he was thinking of the v2 edition where, with ktrans, you
could hit a ctrl seq and switch into different modes.  I assume that
functionality was always part of ktrans itself, in other words after it's
started it is always running and handles whether or not to do translation.


> > When I input Japanese like below:
> > 
> > term% 日本語の入力の練習です。<cr>
> > 
> > 
> > I cannot now return to rc shell.
> 
> I don't understand.  Do you want just to enter one line of Japanese text?
> The idea was to switch the mode of /dev/cons permanently. I assumed
> your Japanese input methods could provide both ASCII and Japanese text.

Re: [9fans] pipefile

[rob pike]

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

> When I input Japanese like below:
> 
> term% 日本語の入力の練習です。<cr>
> 
> 
> I cannot now return to rc shell.

I don't understand.  Do you want just to enter one line of Japanese text?
The idea was to switch the mode of /dev/cons permanently. I assumed
your Japanese input methods could provide both ASCII and Japanese text.
The pipefile program is a permanent fixture, not useful for just sending
one line and going back to the previous state.

-rob


[-- Attachment #2: Type: message/rfc822, Size: 2128 bytes --]

From: okamoto@granite.cias.osakafu-u.ac.jp
To: 9fans@cse.psu.edu
Subject: Re: [9fans] pipefile
Date: Wed, 2 Aug 2000 16:55:47 0900
Message-ID: <200008020754.DAA15253@cse.psu.edu>

>As I said in the beginning, this trick is suitable for continuous
>files such as devices

I was confused in my earlier mail, because I had no EARGF definition
on my libc.h.  Now, I got the new update, and it works now what you
intended (probably).

Then, now I'm wondering rightly☺ how I can end the input, and 
return to shell prompt, when I hit return key on rio environment.  
Yes, I have read rio sources, but it's beyond my ability.  My only 
understand on this is to send nil length font length to the frame of
the window of rio....  I know this procedure is simple, and works 
under acme, too.

When I input Japanese like below:

term% 日本語の入力の練習です。<cr>


I cannot now return to rc shell.

Kenji

Re: [9fans] pipefile

[okamoto]

>As I said in the beginning, this trick is suitable for continuous
>files such as devices

I was confused in my earlier mail, because I had no EARGF definition
on my libc.h.  Now, I got the new update, and it works now what you
intended (probably).

Then, now I'm wondering rightly☺ how I can end the input, and 
return to shell prompt, when I hit return key on rio environment.  
Yes, I have read rio sources, but it's beyond my ability.  My only 
understand on this is to send nil length font length to the frame of
the window of rio....  I know this procedure is simple, and works 
under acme, too.

When I input Japanese like below:

term% 日本語の入力の練習です。<cr>


I cannot now return to rc shell.

Kenji

Re: [9fans] pipefile

[Skip Tavakkolian]

Could one stack pipefiles?

Also, this may be a totally stupid question, but I am wondering why
there never was a notation for bidirectional pipes in the shell
(say '><') that sets this pipelining?

So, your example would look like:

rc >< readwrite </dev/cons > /dev/cons

It does look to be of limited use.

At 09:14 PM 7/30/00 -0400, rob pike wrote:
>> If you don't mind, could you also say a word as to what made the
>> /dev/cons case special?  Who was writing to /dev/cons all of the 
>> keyboard input so that it worked? (rio?)
>
>/dev/cons is connected to standard in and standard out, that's all.
>I stupidly had file descriptors 0 and 1 wired into the code.
>Nobody was writing any keyboard input of any kind to /dev/cons.
>
>What pipefile does is place filters between the file and
>any subsequent program that opens it for i/o, by binding a pipe
>onto the file and then connecting the filters to the pipe.  The other
>end of the pipe is connected to the underlying file.
>
>Normally you have, in effect,
>
>	</dev/cons  rc   >/dev/cons
>
>but after
>
>	pipefile -r 'readcmd' -w 'writecmd' /dev/cons
>	rc < /dev/cons >/dev/cons
>
>you have, almost literally,
>
>	</dev/cons readcmd | rc | writecmd >/dev/cons
>
>(The only difference is that it uses one full duplex pipe instead
>of two half duplex ones.)
>
>What was special about /dev/cons was that I had this
>example in mind when I wrote the program, so what
>it actually did was closer to
>
>	</fd/0 readcmd | rc | writecmd >/fd/1
>
>The fix was to open the file explicitly.
>
>Hope that helps.
>
>-rob
>
>

Re: [9fans] pipefile

[okamoto]

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


However, I don't know how to off the pipe buffer.

Kenji


[-- Attachment #2: Type: message/rfc822, Size: 1784 bytes --]

From: "rob pike" <rob@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] pipefile
Date: Mon, 31 Jul 2000 00:55:29 -0400
Message-ID: <200007310455.AAA06403@cse.psu.edu>

> What you can do, if you want to change the mode of /dev/cons 
> itself before piped to readcmd?  I'm imaging to pipe to the raw 
> mode input of /dev/cons.

It doesn't affect /dev/consctl.  You can set raw mode independently.

-rob

Re: [9fans] pipefile

[rob pike]

> What you can do, if you want to change the mode of /dev/cons 
> itself before piped to readcmd?  I'm imaging to pipe to the raw 
> mode input of /dev/cons.

It doesn't affect /dev/consctl.  You can set raw mode independently.

-rob

Re: [9fans] pipefile

[okamoto]

Interesting.

>	</dev/cons readcmd | rc | writecmd >/dev/cons

What you can do, if you want to change the mode of /dev/cons 
itself before piped to readcmd?  I'm imaging to pipe to the raw 
mode input of /dev/cons.

Kenji

Re: [9fans] pipefile

[rob pike]

> If you don't mind, could you also say a word as to what made the
> /dev/cons case special?  Who was writing to /dev/cons all of the 
> keyboard input so that it worked? (rio?)

/dev/cons is connected to standard in and standard out, that's all.
I stupidly had file descriptors 0 and 1 wired into the code.
Nobody was writing any keyboard input of any kind to /dev/cons.

What pipefile does is place filters between the file and
any subsequent program that opens it for i/o, by binding a pipe
onto the file and then connecting the filters to the pipe.  The other
end of the pipe is connected to the underlying file.

Normally you have, in effect,

	</dev/cons  rc   >/dev/cons

but after

	pipefile -r 'readcmd' -w 'writecmd' /dev/cons
	rc < /dev/cons >/dev/cons

you have, almost literally,

	</dev/cons readcmd | rc | writecmd >/dev/cons

(The only difference is that it uses one full duplex pipe instead
of two half duplex ones.)

What was special about /dev/cons was that I had this
example in mind when I wrote the program, so what
it actually did was closer to

	</fd/0 readcmd | rc | writecmd >/fd/1

The fix was to open the file explicitly.

Hope that helps.

-rob

Re: [9fans] pipefile

[Steve Harris]

On Sun, 30 Jul 2000 18:17:32 rob pike wrote:

> Here's a version that doesn't implicitly assume /dev/cons.

If you don't mind, could you also say a word as to what made the
/dev/cons case special?  Who was writing to /dev/cons all of the 
keyboard input so that it worked? (rio?)

Re: [9fans] pipefile

[rob pike]

Here's a version that doesn't implicitly assume /dev/cons.
I dropped the -b option because it was too hard to make work.
It's a lot shorter as a result; perhaps it could even be a shell
script.

-rob

#include <u.h>
#include <libc.h>

#define	TEMP	"/n/temp"

void
usage(void)
{
	fprint(2, "usage: pipefile [-r command] [-w command] file\n");
	exits("usage");
}

void
connect(char *cmd, int fd0, int fd1)
{
	switch(rfork(RFPROC|RFFDG|RFREND|RFNOWAIT)){
	case -1:
		sysfatal("fork %s: %r", cmd);
		break;
	default:
		return;
	case 0:
		if(fd0 != 0)
			dup(fd0, 0);
		if(fd1 != 1)
			dup(fd1, 1);
		execl("/bin/rc", "rc", "-c", cmd, nil);
		sysfatal("exec %s: %r", cmd);
		break;
	}
}

void
main(int argc, char *argv[])
{
	char *file;
	char *rcmd, *wcmd;
	int fd0, fd1, ifd0, ifd1;

	rcmd = wcmd = nil;
	ARGBEGIN{
	case 'r':
		rcmd = EARGF(usage());
		break;
	case 'w':
		wcmd = EARGF(usage());
		break;
	default:
		usage();
	}ARGEND

	if(argc!=1 || (rcmd==nil && wcmd==nil))
		usage();
	if(rcmd == nil)
		rcmd = "/bin/cat";
	if(wcmd == nil)
		wcmd = "/bin/cat";

	file = argv[0];
	ifd0 = open(file, OREAD);
	if(ifd0 < 0)
		sysfatal("open %s: %r", file);
	ifd1 = open(file, OWRITE);
	if(ifd1 < 0)
		sysfatal("open %s: %r", file);

	if(bind("#|", TEMP, MREPL) < 0)
		sysfatal("bind pipe %s: %r", TEMP);
	if(bind(TEMP "/data", file, MREPL) < 0)
		sysfatal("bind %s %s: %r", TEMP "/data", file);

	fd0 = open(TEMP "/data1", OREAD);
	if(fd0 < 0)
		sysfatal("open %s: %r", TEMP "/data1");
	connect(wcmd, fd0, ifd1);
	fd1 = open(TEMP "/data1", OWRITE);
	if(fd1 < 0)
		sysfatal("open %s: %r", TEMP "/data1");
	connect(rcmd, ifd0, fd1);
	unmount(nil, TEMP);
	exits(nil);
}

Re: [9fans] pipefile

[rob pike]

> I'm trying to understand this, but I can't figure out how the original 
> file is actually read/written by this code.  

You're right.  I was thinking too far ahead and the code assumes you
were dealing with /dev/cons; hence the duping of fd's 0 and 1 in the
calls to connect.  Dumb. 

I'll send a fix in a while.

-rob

Re: [9fans] pipefile

[Steve Harris]

On Sun, 30 Jul 2000 14:54:30 rob pike wrote:

> The command is called pipefile; it interposes a command
> between you and the named file.  ...

I'm trying to understand this, but I can't figure out how the original 
file is actually read/written by this code.  

I think I'm misunderstanding, but it looks to me like the code produces 
a 
"closed loop" of two pipes with the filter command in between, with one 
side 
"data" bound over and replacing the original file (I'm with it so far I 
think).
But I don't see how the other side of the pipe, "data1", is connected at 
all 
with the contents of the original file ( before it had the 
 	bind(TEMP "/data", file, MREPL) 
done over it ). In fact I don't see how you can access the original file 

contents at all after the bind() call above has been done in the 
namespace.

Or do we not care about the original file at all?  Does rio make 
keyboard
input available for reading through /dev/cons even if we've bound 
something 
over the original file with MREPL?


What am I missing?

Here's the section I don't understand:

> 	file = argv[0];
> 	if(bind("#|", TEMP, MREPL) < 0)
> 		sysfatal("bind pipe %s: %r", TEMP);
> 	if(bind(TEMP "/data", file, MREPL) < 0)
> 		sysfatal("bind %s %s: %r", TEMP "/data", file);
> 
> 	if(bcmd != nil){
> 		fd0 = open(TEMP "/data1", ORDWR);
> 		if(fd0 < 0)
> 			sysfatal("open %s: %r", TEMP "/data1");
> 		connect(bcmd, fd0, fd0);
> 		close(fd0);
> 	}else{
> 		fd0 = open(TEMP "/data1", OREAD);
> 		if(fd0 < 0)
> 			sysfatal("open %s: %r", TEMP "/data1");
> 		connect(wcmd, fd0, 1);
> 		fd1 = open(TEMP "/data1", OWRITE);
> 		if(fd1 < 0)
> 			sysfatal("open %s: %r", TEMP "/data1");
> 		connect(rcmd, 0, fd1);
> 		close(fd0);
> 		close(fd1);
> 	}
> 	unmount(nil, TEMP);
> 	exits(nil);
> }
> 

[9fans] pipefile

[rob pike]

I had an idea while trying to kill groundhogs today.
The command is called pipefile; it interposes a command
between you and the named file.  Options -r and -w
specify a command to interpose when reading or writing;
-b does both, but in that case the command must handle
bidirectional input; most standard commands such as
cat won't work.
Try this:

	pipefile -w 'tr a-z A-Z' /dev/cons
	rc -i < /dev/cons > /dev/cons >[2] /dev/cons

for a shell reminiscent of olden times.  The origin of the
idea was a way to support Asian input. Consider

	pipefile -r 'tr a-z A-Z' /dev/cons
	rio < /dev/cons > /dev/cons >[2] /dev/cons

I leave the rest to the interested Asian reader.

The command leaves the file in an odd state, and can only
work well on continuous files such as devices or with very
special commands interposed, but I offer it as an interesting
idea.

-rob


#include <u.h>
#include <libc.h>

#define	TEMP	"/n/temp"

void
usage(void)
{
	fprint(2, "usage: pipefile [-r command] [-w command] [-b command] file\n");
	exits("usage");
}

void
connect(char *cmd, int fd0, int fd1)
{
	switch(rfork(RFPROC|RFFDG|RFREND|RFNOWAIT)){
	case -1:
		sysfatal("fork %s: %r", cmd);
		break;
	default:
		return;
	case 0:
		if(fd0 != 0)
			dup(fd0, 0);
		if(fd1 != 1)
			dup(fd1, 1);
		execl("/bin/rc", "rc", "-c", cmd, nil);
		sysfatal("exec %s: %r", cmd);
		break;
	}
}

void
main(int argc, char *argv[])
{
	char *file;
	char *rcmd, *wcmd, *bcmd;
	int fd0, fd1;

	rcmd = wcmd = bcmd = nil;
	ARGBEGIN{
	case 'r':
		if(bcmd != nil)
			usage();
		rcmd = EARGF(usage());
		break;
	case 'w':
		if(bcmd != nil)
			usage();
		wcmd = EARGF(usage());
		break;
	case 'b':
		if(rcmd!=nil || wcmd!=nil)
			usage();
		bcmd = EARGF(usage());
		break;
	default:
		usage();
	}ARGEND

	if(argc!=1 || (rcmd==nil && wcmd==nil && bcmd==nil))
		usage();
	if(rcmd==nil && wcmd!=nil)
		rcmd = "/bin/cat";
	if(wcmd==nil && rcmd!=nil)
		wcmd = "/bin/cat";

	file = argv[0];
	if(bind("#|", TEMP, MREPL) < 0)
		sysfatal("bind pipe %s: %r", TEMP);
	if(bind(TEMP "/data", file, MREPL) < 0)
		sysfatal("bind %s %s: %r", TEMP "/data", file);

	if(bcmd != nil){
		fd0 = open(TEMP "/data1", ORDWR);
		if(fd0 < 0)
			sysfatal("open %s: %r", TEMP "/data1");
		connect(bcmd, fd0, fd0);
		close(fd0);
	}else{
		fd0 = open(TEMP "/data1", OREAD);
		if(fd0 < 0)
			sysfatal("open %s: %r", TEMP "/data1");
		connect(wcmd, fd0, 1);
		fd1 = open(TEMP "/data1", OWRITE);
		if(fd1 < 0)
			sysfatal("open %s: %r", TEMP "/data1");
		connect(rcmd, 0, fd1);
		close(fd0);
		close(fd1);
	}
	unmount(nil, TEMP);
	exits(nil);
}