Re: Incorrect alias expansion within command substitution

[Robert Elz]

    Date:        Thu, 3 Feb 2022 13:31:52 -0500
    From:        Chet Ramey <chet.ramey@case.edu>
    Message-ID:  <46753625-7fcc-8296-c31e-7a5d1fc38b75@case.edu>

  | 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?

Sure, I understand that, for most uses, no-one cares what the actual word
text is, as long as it has the desired effect.   It's just this odd here doc
end word usage, where the word isn't used like everywhere else, but as
a literal string (after quote removal).


  | It's less clear that POSIX requires the exact original text,

No, that's clear - that always has been.

  | and it's just
  | as clear that, let's say, implementations differ in this area.

Aside from bash 5.2, not really.   There are lots of implementation bugs
are limitations, but not really any expectation that the here doc end
word text can be modified (beyond quote removal).

  | > Supporting that would be wrong.  
  | And that's why bash doesn't do it.

Yes, though in the previous message, where you gave that example, you just said
"I'm not sure that's worth supporting" rather than "shouldn't work, forget it".


  | OK. You need to be able to reconsistute text for `type' output.

Yes, another example where getting the meaning right, and not caring
about the layout is all that matters.

FWIW our equivalent doesn't bother including here doc data in those
either (just like our -x output) ...

        $ hash -v foo
        function foo() { cat <<...; }

(type just says:
        $ type foo
        foo is a shell function
)

But we don't do exported functions, which need all the details,
so writing the code to include here doc contents there never seemed
to be worth the effort.

  | > 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.

Yes.   But it is exactly these edge cases that test the standard, and
the implementations.

  | I'm comfortable with not supporting this use case.

Fine, I doubt you'll ever encounter anything like that in the wild, but you
are breaking backwards compat with bash up to 5.1 when you do that.


  | > 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.

No err message, bash (5.2-xxx) just sat there (at PS2) waiting for more
input, until I SIGINT'd it.   I do most of these tests interactively, not
in scripts, unless there is a real need (or they are very long).

  | Of course it's possible. Is it worth the implementation effort?

I have been looking at it today.   Aside from the mem management issues
the only tricky part looks to be correctly handling the truly odd cases
like
        cat <<$(cat <<$(cat <<$(foobar)))
(expand that however you need to make it syntax legal for you).

It was playing with all of this where I encountered the

        cat<<$((1+1))

case that you will (I assume by now) have seen queried on the austin group
list.

kre