On Thu, Feb 3, 2022, 22:14 Alex fxmbsw7 Ratchev <fxmb...@gmail.com> wrote:
> > > On Thu, Feb 3, 2022, 20:02 Chet Ramey <chet.ra...@case.edu> wrote: > >> On 2/2/22 1:30 PM, Robert Elz wrote: >> > Date: Wed, 2 Feb 2022 11:38:30 -0500 >> > From: Chet Ramey <chet.ra...@case.edu> >> > Message-ID: <7c422cbb-bba8-0a57-a565-eeb115120...@case.edu> >> > >> > >> > | > How accurately can you reconstitute? That is, can you maintain >> the >> > | > difference between $(a b) and $( a b ) for example ? How about >> $(a b) ? >> > | >> > | Does it make a semantic difference? >> > >> > No, but that's not the point. >> >> My argument is like yours -- is there a return on the investment of effort >> to make it worth doing, if the current state preserves semantics? >> >> It's clear that POSIX requires recursive parsing during which aliases are >> expanded. Changing the code to do that is worth the effort: it's my effort >> and I get to make that judgement. >> >> It's less clear that POSIX requires the exact original text, and it's just >> as clear that, let's say, implementations differ in this area. >> >> >> > >> > | The only thing I can think of that >> > | might mess it up is when you have something like >> > | >> > | alias l='(' r=')' >> > | echo $(l 4+4 r) >> > | >> > | and you intend, for whatever perverse reason, to have this parsed >> as an >> > | arithmetic expansion. I'm not sure that's worth supporting. >> > >> > Supporting that would be wrong. >> >> And that's why bash doesn't do it. >> > > alias 0='echo ' 1='$(( ' 2=')) ' data=2+3' ' > > thats why this doesnt work, or what > > 0 1 data 2 > > > the eval variant is worse 0 1 data 2 bash: unexpected EOF while looking for matching `)' bash: syntax error: unexpected end of file > > im your example above you misknow that aliases are expanded as only > commands > you specify in $( '(' as the command > you maybe meant like i tried $(( > cause ( is no math expression > no idea why mine failed, bash bug > >> >> >> > The case I had in question with the question about $( a b ) was this >> > one... >> > >> > cat <<$( a b ) >> > hello >> > $( a b ) >> > >> > which works in bash 5.1.16, but doesn't in 5.2-(December 16). In the >> > latter the end line needs to be $(a b). The spaces are lost - >> reconstituting >> > really doesn't work for this purpose. (nb: no aliases involved >> anywhere >> > here). >> >> Refer to my ROI comment above. >> >> > For what it is worth, ksh93 (the version I have anyway) doesn't even >> > get started... >> > >> > ksh93 $ cat <<$( a b ) >> > /usr/pkg/bin/ksh93: syntax error at line 1: `<<b' here-document not >> contained within command substitution >> > >> > And I hate to even imagine what state it got itself into to produce that >> > diagnostic. >> >> The only person reading this with a chance to know that answer is Martijn. >> >> >> > | You need to be able to reconstruct the text of arbitrary commands >> for >> > | `set -x'. It's a very short step from that to rebuilding a command >> > | substitution. >> > >> > There are some things that -x typically does not show anything like >> > as input (in bash, try a case statement for example). What appears >> > is fine for -x output, but not even close for reconstitution. >> >> OK. You need to be able to reconsistute text for `type' output. That >> includes everything, including redirections, because you need it to >> accurately reproduce shell functions. >> >> > >> > This one works in released bash, but not in 5.2-xxx (and no white space >> > tricks with this one to mess things up --- and I also did not try to >> guess >> > what the end delimiter might actually work, if anything): >> > >> > cat <<$(case $x in a) echo found A;; b) echo found B;& *) echo found $x >> ;; esac) >> > hello >> > $(case $x in a) echo found A;; b) echo found B;& *) echo found $x ;; >> esac) >> >> These examples are getting more and more hyperbolic. I'm comfortable with >> not supporting this use case. >> >> >> > cat <<$(cat</dev/null) >> > hello >> > $(cat</dev/null) >> >> It's not because the reconstituted text doesn't include redirections; the >> error message tells you that. And, in fact, this works: >> >> cat <<$(cat</dev/null) >> hello >> $(cat < /dev/null) >> >> though that's neither here nor there. >> >> > If you abandoned reconstituting, and simply saved the string, however >> > difficult that might be none of these issues would arise. >> > >> > It must be possible, the lexer is reading chars from somewhere, all it >> > needs to happen is to be told when to start saving, and when to stop). >> >> Of course it's possible. Is it worth the implementation effort? >> >> Chet >> -- >> ``The lyf so short, the craft so long to lerne.'' - Chaucer >> ``Ars longa, vita brevis'' - Hippocrates >> Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/ >> >>