> 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
