Re: A patch to add builtin read (small bug)

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

> The patch dropped in nicely in my virgin 1.4, no problems.

At least one of those bug fixes I mentioned prevents a crash, you really
should look into them.

> I was just wondering about the following case:
> 
> 	; x=(foo bar)
> 	; read x < /dev/null
> 	; echo $status
> 	1
> 	; whatis x
> 	x=(foo bar)
> 
> This suggests that something has been read before encountering EOF,
> which is obviously not the case, so I assume the read should set x to ''.

Doing:

	read x </etc/passwd

doesn't work either, but my brain isn't working well emough at the
moment to figure out why.  Anybody got a clue?

>   |For Chris, if you don't care about setting a different ifs, you can
>   |split the line without a fork by using eval:
>   |	read x;eval 'x=('$x')'
>
> This doesn't work:

(Examples with embedded '#' and '=' deleted)

Yeah, it's a stunt, and I should have made the standard disclaimer that
pathalogical cases would kill it.

> If a read function is added, why not make it a bit more practical by using
> $ifs? If makes it more useful, and the code above a bit more elegant.
> I wouldn't mind adding this myself, but I'm not too familiar with the
> rc internals.
> 
> 	Gert-Jan

Because you lose information that you can't get back.  For example if
you are trying to parse the entries from /etc/passwd to find the home
directories, and the comment field is blank:

	joeblow:x:200:50::/usr/joeblow:/bin/rc

You get the following list:

	x=(joeblow x 200 50 /usr/joeblow /bin/rc)

and when you try to retrieve $x(6) which should be the directory you get
/bin/rc instead!  This may not be the worlds best example but I hope my
point is clear.  The way read works now preserves potentially important
information.

Tom