Re: Incorrect alias expansion within command substitution

[Chet Ramey]

On 2/4/22 3:06 PM, Alex fxmbsw7 Ratchev wrote:

> > it was my mind shell
> >
> > does it mean it wont ever get to be the regex /<<([^ \t\f\v\r\n;]+)
> >
> > that is, after << is parsed a read word till next space, no shell expansion
> > logic of separated functional structures in the topic of flat data is
> > overruling, you are overseeing

No, that's not how it works. You read a shell WORD, which can include
constructs that contain a space or other metacharacter.

> the data functional topic here would be alike 'data has to be parsed,
> as simple as possible, till eof marker is reached'

I suppose it's the difference between something simple like strtok(3) and
real shell lexical analysis.

> now changing this to dynamic eof marker ( not like it would recognize
> not dynamic already so ) beyond
> would be easily nested ( in eval or so ) possible, but else invalid in
> code parsing

Nobody I know is thinking about a dynamic here-doc delimiter. That would be
awful.


> example
>
> cat <<$( printf leet )
> $(  printf leet )
> $( printf leet )
> notice the two spaces in the middle to not match eof

Yes, that's the exact use case we've been discussing here.

> thats valid code, cause eof is written twice ( the $( .. ) code )
> but
>
> cat <<$(  printf end )
> $( printf end )
> # here it should already end the heredoc parser

No, it should not.

> but bash doesnt eval far enough

What does this mean? You mean performing word expansions while reading here
document data?

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