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