Thoughts on a builtin read

[culliton@srg.af.mil (Tom Culliton x2278)]

After all the recent discussion about builtin read, it is starting to
sound like something that will happen, at the very least as a common
addon.  Given this, it's time to examine the design options and try to
come up with something reasonable.  After a bit of thought I came up
with the following:

To keep things in the spirit of rc, simplicity should be our guiding
principle.  This shapes most of the design decisions discussed below.

1) One string rather than IFS seperation of fields
	- simplicity
	- preserves information, such as runs of blanks
	- field splitting can always be done later with backquote:
		read x;x=(`{echo -- $x})

2) Single variable rather than multiple variables
	- simplicity
	- you can always split the fields as above and use subscripts

3) Good behaviour on EOF.
	- return 1 on EOF, 0 otherwise
	- save any text on the line before EOF

4) Should strip the newline
	- This makes "read x;echo -- $x" work right.

5) Doesn't honor \ at EOL for continuation
	- simplicity

6) If interactive and compiled with readline, use that to get input.
	- consistency

Aside from the last item, Alan Watson has already presented what looks
like a reasonable implementation way back on May 17th of this year. (It
could be packaged a bit better to fit in with the current addon scheme
and be easier to install.) The case for a builtin read could be much
better evaluated if some folks would try his version and report back on
their experiances.

Tom

PS - with Alan's permission I'll repackage his read routine as a proper
patch so it's easier to try.  Alan?