bin/53550: /bin/sh exit status of a here-doc only command is incorrect

[kre%munnari.OZ.AU@localhost]

>Number:         53550
>Category:       bin
>Synopsis:       /bin/sh exit status of a here-doc only command is incorrect
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Aug 25 02:45:00 +0000 2018
>Originator:     Robert Elz
>Release:        NetBSD 8.99.24
>Organization:
>Environment:
System: NetBSD jinx.noi.kre.to 8.99.17 NetBSD 8.99.17 (GENERIC) #1: Sat May 19 20:03:18 ICT 2018 kre%onyx.coe.psu.ac.th@localhost:/usr/obj/testing/amd64/sys/arch/amd64/compile/GENERIC amd64
Architecture: x86_64
Machine: amd64
>Description:
	In the following (useless) command

		<<EOF
		$(exit 1)
		EOF

	The exit status should be 1, as POSIX requires that in a command
	with no command word (which this is) the exit status shall be
	the exit status of the last command substitition performed,
	which is the "$(exit 1)" here, which obviously has 1 as its
	exit status (or 0 if there is no command substitution).

	We ignore the exit status from here doc evaluation, and always
	return 0.

>How-To-Repeat:
	As above.

>Fix:
	No workaround.   None really needed, this is a pointless example
	that should never arise IRL.   Yet, it should be fixed.  I noticed
	this from reading the code, looking at places where the shell
	exits, while fixing PR bin/53548 (which seems, or looks, to be a
	related problem, but is not).

	This bug has been in the NetBSD sh for ages (it is in netbsd-6
	shells, for example).   Perhaps forever.  Of all modern shells,
	zsh is the only other one which does not produce 1 as the exit
	status of the empty command with a here doc - and I suspect that
	is because they treat it as a shorthand for something else
	(perhaps cat - since they also produce a line of output).

	I will fix this properly sometime soon...  It does not seem urgent.