The output of sh(1) from the base and of dash from the ports (shells/dash) is different. Here's the script to reproduce this issue: ``` #! /bin/sh - set -u # Unset variable. cat << EOF > /dev/null && echo ok || echo error $unsetvar EOF ``` Output of `sh test.sh`: > testcase-2.sh: unsetvar: parameter not set > ok Output of `dash test.sh`: > testcase-2.sh: 6: testcase-2.sh: unsetvar: parameter not set > error I'm running sh(1) from 12.0-ALPHA6 r338797 and dash 0.5.10.2 from ports.
Although dash is not necessarily a good reference (since it has various bugs and shortcuts of itself), I checked this against bash --posix and ksh93 and the common behaviour seems to be that an expansion error in a here-document is treated as a redirection error (so the redirected command is not executed and for some types of command the shell aborts). When I last changed here-document expansion in SVN r246288, I left the error and side effect behaviour unchanged from what it was to minimize the risk of breaking existing scripts. A related test case: sh -c 'd=/dev/null; : <"${d#$((a=1))}"; true <"${d#$((b=2))}"; /usr/bin/true <"${d#$((c=3))}"; echo "a=$a b=$b c=$c"' Most shells seem to agree that this should output a=1 b=2 c=3. Bash (POSIX mode as well as default mode) has different behaviour between true (keeps side effects) and /usr/bin/true (discards side effects). This seems incorrect.
I think the behaviour here can be improved, but how it should work is not immediately clear. This should take into account our previous behaviour, the behaviour of other shells and POSIX (with the most recent interpretations). The effect of expansions and errors in redirections varies depending on what kind of command the redirection is applied to (special builtin, other simple command, subshell, compound command). Different from what I wrote in my previous comment, bash also has a different error behaviour between true (shell aborts) and /usr/bin/true (shell continues with non-zero exit status).
Created attachment 203269 [details] experimental patch to stop ignoring here-document expansion errors The simplest thing that could possibly work is to treat an expansion error in a here-document the same way as an expansion error in a redirection filename or file descriptor number. Such an error will cause the script or subshell to be aborted ('command .' and 'command eval' can also "catch" such an error). Trying to build a few ports using that does not appear to cause breakage.