Parser issue with $(...) command substitution and here document (worked fine with bash 3)

Binary package hint: bash

Source package: http://packages.ubuntu.com/source/karmic/bash

Hi,

after doing some research and discussions with other people, I got the impression that this is really a bug in bash which has been introduced with some bash 4 version (while first I thought I simply did something wrong).

The following code works fine with bash 3 (e.g. in Ubuntu 8.04, SLES 10 and 11), but the parser of bash 4 doesn't accept it (found in Ubuntu 9.10, with all available updates; package version: "4.0-5ubuntu2"; bash --version: "GNU bash,
Version 4.0.33(1)-release (x86_64-pc-linux-gnu)"):

TEST=$(cat <<EOF | sort -u
abc
geh
def
abc
EOF
)

Expected result: The expression is evaluated and the variable ends with value "abc def geh".

However, on Ubuntu 9.10, the parser expects the expression to be completed after the closing parentheses, i.e. it assumes the "command substitution" part is still incomplete (-> I get another "> " on the next line to continue the expression). When I put the code into a script file and run it, consequently I get the following error message: -bash: <script name>: line <line>: unexpected EOF while looking for matching `)'

Interestingly, it works fine even on Ubuntu 9.10 if I just remove the "-u" parameter to "sort", like this:

TEST=$(cat <<EOF | sort
abc
geh
def
abc
EOF
)

By now, my impression is that, as soon as there's either
- some parameter after "sort" (resp. the respective command in my real script, which now fails on Ubuntu 9.10) or
- some more pipes with additional commands afterwards,
the parser fails like this. Only in this very short variant (only single pipe + receiving command without parameters), it accepts the code.

Additionally, I found that, replacing "$(...)" by the old (?) notation "`...`" (i.e. using backticks), the code is also accepted, so the issue doesn't seem to be related to command substitution in general, but only to the variant using the "$(...)" notation (which I understood is the recommended one).

Please check whether this is really a bug (or whether there's still something in my code, which I cannot really imagine any more now).

Thanks and best regards
Heiko