Summary: | sh(1): Using unset variables in here-doc with set -u does not cause the script to exit | ||||||
---|---|---|---|---|---|---|---|
Product: | Base System | Reporter: | Mateusz Piotrowski <0mp> | ||||
Component: | bin | Assignee: | freebsd-bugs (Nobody) <bugs> | ||||
Status: | Open --- | ||||||
Severity: | Affects Only Me | CC: | jilles | ||||
Priority: | --- | Keywords: | patch | ||||
Version: | CURRENT | ||||||
Hardware: | Any | ||||||
OS: | Any | ||||||
Attachments: |
|
Description
Mateusz Piotrowski
2018-10-12 12:49:12 UTC
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.
|