On Sunday, February 19, 2012 04:25:46 PM Chet Ramey wrote:
> On 2/17/12 6:22 PM, Dan Douglas wrote:
> > My favorite is probably the parser ignoring any valid redirection syntax
> > with the special command substitutions.
> >
> > ~ $ { echo "$({xxxxxxxxxxxxxxxxxxxx}</dev/stdin)"; } <<<'hi'
> >
> > hi
>
> Bash does the same thing as ksh93 here, though for the wrong reasons.
> I think ksh93 counts an input redirection that saves the file descriptor
> into a variable as sufficient to kick in the `equivalent to cat file'
> clause.
>
> > ~ $ { echo "$(1111111111111111111111</dev/stdin)"; } <<<'hi'
> >
> > hi
>
> This is a bug. It should be a file descriptor out of range error, or
> it should treat the string of digits as a word, since the value
> exceeds the largest intmax_t.
>
> > That one really is ignored. No variable named xxx... is actually set.
>
> I assume you mean the first one. It doesn't matter whether or not the
> variable is set as a side effect of the redirection -- it's in a
> subshell and disappears.
>
> Chet
Oh so a subshell is created after all, and that really is a command
substitution + redirect! I just chalked it up to Bash recycling the way
redirects were parsed.
I think I ran across that quirk in trying to determine whether $(<file) was a
special command substitution or it's own kind of expansion but couldn't think
of a way to test it. I tried in ksh93 something like:
: "$(</dev/null${ echo ${.sh.subshell} >&2;})"
...only to discover that ${ cmd;} also increments .sh.subshell anyway (like
BASH_SUBSHELL), and there was no BASHPID equivalent so that was a dead end.
--
Dan Douglas
