[9fans] Making read(1) an rc(1) builtin?

[quanstro@quanstro.net (erik quanstrom)]

> Each line that's read by the script causes it to fork a new process,

we're not running out.  even with a mere four billion odd to choose from.

> I understand the Unix/Plan 9 philosophy of connecting tools that do one
> job and do it well.  But I don't think /bin/read and /bin/test are
> places where that philosophy is practical (i.e., efficient).  After all,
> reading input lines really is the perogative of any program that
> processes line-oriented data (like rc(1) does).  In addition, /bin/read
> represents a simple and fairly stable interface that's not likely to
> change appreciably in the future.

could you be concrete about your performance problem.
if you don't have a performance problem, then there's no
point to optimizing.

> I'm also a bit stumped by the fact that rc(1) doesn't have anything
> analogous to bash(1)'s string parsing operations: ${foo#bar},
> ${foo##bar}, ${foo%bar}, ${foo%%bar}, or ${foo/bar/baz}.  Is there any
> way to extract substrings (or single characters) from a string in rc(1)
> without having to fork a dd, awk, or sed?  I've tried setting ifs='' and
> using foo=($"bar), but rc(1) always splits bar on spaces.  

false.

	ifs=? {x=`{echo -n  'a b c ? d e f'}}
	; whatis x
	x=('a b c ' ' d e f')
	; echo $#x
	2

(you might not want to try splitting on non-ascii with the rc
on sources.  i'm unsure about p9p.)

> (As a side note, if anyone goes into rc(1)'s source to implement any of
> this, please add a "--" option (or similar) to the "echo" builtin while
> you're there.  Having to wrap echo in:

when exactly does this come up?

- erik