On 6/18/14, 4:27 PM, Dan Douglas wrote:
> On Wed, Jun 18, 2014 at 2:49 PM, Chet Ramey wrote:
>> Yes, since bash can parse the same construct without any problems if you
>> use command substitution, it looks like a bug. I'll take a look.
>
> It brings to mind all those unbalanced paren case..esac
On Wed, Jun 18, 2014 at 2:49 PM, Chet Ramey wrote:
> Yes, since bash can parse the same construct without any problems if you
> use command substitution, it looks like a bug. I'll take a look.
It brings to mind all those unbalanced paren case..esac bugs that
affected every shell ever.
I suppose
On 6/17/14, 5:54 PM, Tim Friske wrote:
> Hi,
>
> see my question
> http://unix.stackexchange.com/questions/137506/how-to-combine-bashs-process-substitution-with-here-document
> for a description.
>
> Could the described behavior be a bug?
Yes, since bash can parse the same construct without any
I've heard process substitutions considerably complicate parsing. zsh
and ksh93 are the only others that have process substitutions that I
know of, and zsh can't handle unbalanced parentheses in that situation
either.
$ zsh -c $'cat <(cat <<"EOF"\n(test)(foo\nEOF\n)'
zsh:4: parse error near `<(ca