>Number:         16358
>Category:       bin
>Synopsis:       /bin/sh doesn't support `read' in a posix-like manner
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Apr 15 03:09:01 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     Luke Mewburn
>Release:        NetBSD 1.5ZA
>Organization:
Luke Mewburn  <lukem@wasabisystems.com>  http://www.wasabisystems.com
Luke Mewburn     <lukem@netbsd.org>      http://www.netbsd.org
Wasabi Systems - NetBSD hackers for hire
NetBSD - the world's most portable UNIX-like operating system
>Environment:
System: NetBSD argo.mewburn.net 1.5ZA NetBSD 1.5ZA (ARGO) #0: Tue Jan 22 11:21:31 EST 2002 lukem@hippolyte:/var/scratch/obj.i386/sys/ARGO i386
Architecture: i386
Machine: i386
>Description:
	sh(1) claims to be in the process of being changed to POSIX 1003.2
	conformance.  It's currently broken with respect to
	information piped to `read'.  E.g,
		echo 1 2 3 | read a b c
		echo $a
	prints a blank line.

	I'm told that this is the "traditional" shell behaviour, yet I
	understand that POSIX states that $a should contain `1' at
	this point.

	The workaround is to either not use `read', or to do
		echo 1 2 3 > tmpfile
		read a b c < tmpfile
		rm tmpfile

	For what it's worth, Solaris 2.6's /usr/xpg4/bin/sh and /bin/ksh
	correctly prints `1', and its /bin/sh prints a blank line as well.


>How-To-Repeat:
	See above.

>Fix:
	Ask our /bin/sh maintainers nicely? :-)
	/bin/ksh is similarly broken.
>Release-Note:
>Audit-Trail:
>Unformatted: