[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Incorrect alias expansion within command substitution

From: Chet Ramey
Subject: Re: Incorrect alias expansion within command substitution
Date: Sat, 5 Feb 2022 11:48:18 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.4.1

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


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 )

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/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]