Re: Command or process substitution resets alias name tracking during alias expansion?

2016-11-23 Thread Dan Douglas 
On Wed, Nov 23, 2016 at 1:25 PM, Chet Ramey  wrote:
> On 11/22/16 5:46 PM, Dan Douglas wrote:
>> Hi. Here's a change between bash 4.1 and 4.2 that persists in 4.4.
>> (Added the counter to make it stop).
>
> Thanks for the incredibly obscure report.  This will be fixed in the next
> push to the devel branch.

There's an incredibly obscure ksh flavour too :-)

 $ ksh -c $'alias @=\'echo test >&2; )$( @ \'\n$( @ )' 2>&1 | head -n3
test
test
test

Ok I'm done. (unless maybe backticks...)

Re: Command or process substitution resets alias name tracking during alias expansion?

2016-11-23 Thread Chet Ramey 
On 11/22/16 5:46 PM, Dan Douglas wrote:
> Hi. Here's a change between bash 4.1 and 4.2 that persists in 4.4.
> (Added the counter to make it stop).

Thanks for the incredibly obscure report.  This will be fixed in the next
push to the devel branch.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Command or process substitution resets alias name tracking during alias expansion?

2016-11-22 Thread Dan Douglas 
Hi. Here's a change between bash 4.1 and 4.2 that persists in 4.4.
(Added the counter to make it stop).

ormaajtest@smorgbox $ ( bash-4.2 ) <<\EOF
shopt -s expand_aliases; n=0
alias @='((n >= 5)) && alias @="unalias @; echo"
printf "$((n++)) " $()
@'
@
EOF

0 1 2 3 4 5

ormaajtest@smorgbox $ ( bash-4.1 ) <<\EOF
shopt -s expand_aliases; n=0
alias @='((n >= 5)) && alias @="unalias @; echo"
printf "$((n++)) " $()
@'
@
EOF

The empty command expansion triggers this. I don't think it's an alias
quirk I've known about though. (Too bad because it's faster than eval
and I don't know of another way to make this happen).

If an alias that's read lexically outside of any other command in the
"global context" generates two "complete commands" on separate lines,
why is the second command considered within the scope of the current
alias expansion even though it technically hasn't been "read" yet?
Isn't it extra work for bash to remember exactly what code was
generated by which aliases just to keep track of which words to
ignore? I would think the first command would be evaluated before the
second command is read even if it's the product of an alias.