make rc support <>{cmd} notation

[russcox_gmail.com, 2009-08-08 18:20:12]

Looks great.  Please make that tiny change
and reupload and I will have it applied.

You can ignore my reply via mail asking
for more information; I hadn't
seen your detailed analysis in the issue yet.

http://codereview.appspot.com/105061/diff/1/2
File src/cmd/rc/havefork.c (right):

http://codereview.appspot.com/105061/diff/1/2#newcode184
Line 184: case READ:	w = nil; break;
please split onto multiple lines

case READ:
    w = nil;
    break;

etc

[russcox_gmail.com, 2009-08-08 20:49:03]

Sorry for the back and forth.
I just read through the issue on code.swtch.com
(I wish the code review and the issue server were
better integrated) and I am hesittant to make the
behavior of <>{cmd} be different than on Plan 9.
Since it seems it is impossible to make it the same
as on Plan 9, maybe it is better to leave this out.

[knieriem, 2009-08-10 23:57:44]

> I just read through the issue on http://code.swtch.com
> (I wish the code review and the issue server were
> better integrated) and I am hesittant to make the
> behavior of <>{cmd} be different than on Plan 9.

Concerning "<>{cmd}" current rc behaves identical on Plan
9 and on plan9port -- it is not supported [more precisely,
due to the way Xpipefd is implemented, which tests only
for READ, the else branch applies, so RDWR is treated the
same as WRITE, i.e. >{cmd} ].

At present Rc(1) and rc.pdf both describe <{cmd} and >{cmd},
but not <>{cmd}.

The suggested patch makes <>{cmd} work in a way that
appears like a combination of <{cmd} and >{cmd}.  In fact
the parent command would get two names: one refering to a
pipe to read from `cmd', one refering to a pipe to talk to
`cmd'. This is similar as if one had specified
	pcmd <{cmd} >{cmd} ,
but with the effect, that < and > would affect the
same `cmd'.

What I like about this is that one can chain together
programs acting like interfaces to each other with
assistence of the shell only.

> Since it seems it is impossible to make it the same
> as on Plan 9, maybe it is better to leave this out.

The patch actually applies cleanly on Plan 9's
rc/havefork.c too, so one could get the same behaviour
also on Plan 9 (tested on 9vx).

As this extends rc's behaviour it would perhaps have
been better to discuss this on 9fans first. I chose the
plan9port site, because I thought there it is of more
use (because in plan9port there is no devsrv, and in
the MinGW version of rc, no mkfifo).

If it would be better, I also could provide a patch
to Plan 9's rc using Plan 9's patch system first,
and you leave it out of plan9port for the nonce.

[russcox_gmail.com, 2009-08-11 02:57:22]

Okay, I think I understand:

1. <>file already parses and works
2. <>{cmd} parses but fails to work,
   because it only redirects cmd's standard
   input, not the standard output.
3. Your proposal is to make <>{cmd}
   redirect both and evaluate to two
   file descriptor paths, one for reading
   and one for writing.  This is a change
   but okay because #2.

This sounds fine to me.  Please 
add a man page change to this
code review, documenting the
behavior.

[knieriem, 2009-08-31 22:17:03]

After the paragraph currently describing <{} and >{} in rc's man
page (*), I would insert the following lines:

  <>{command}
	As above, but the command is executed with both standard
	output and standard input connected to pipes. The value
	of the argument is the names of two files refering to
	the other ends of the pipes, in the order corresponding
	to the symbols < and >.

Does this make sense to you? I first tried to mix it with the
named paragraph, but it seemed too difficult to understand then.

If it's ok I can upload a patch for the manpage.


*) The paragraph in the current man page is
  <{command}
  >{command}
	The command is executed asynchronously with its stan-
	dard output or standard input connected to a pipe.  The
	value of the argument is the name of a file referring
	to the other end of the pipe.  This allows the con-
	struction of non-linear pipelines.  For example, the
	following runs two commands old and new and uses cmp to
	compare their outputs
		cmp <{old} <{new}

[russcox_gmail.com, 2009-09-01 17:08:47]

I'd write it as a standalone paragraph instead of referring
to the above, because the diffs are pretty big.

>   <>{command}
> 	As above, but the command is executed with both standard

The command is executed asynchronously with its standard
input and output each connected to a pipe.  The value of the
argument is a pair of file names referring to the two ends of
the pipe, in the order corresponding to the symbols < and >
(first the pipe connected to the command's standard output,
then the pipe connected to its standard input).
 

the choice of stdout then stdin is surprising but i like
the description of < > to remember it.

[rsc_swtch, 2009-09-13 22:24:19]

thanks again

codebot: apply

rc: implement and document <>{cmd} notation

[old.codebot, 2009-09-13 22:25:30]

# codebot: apply

applied.