Re: $* within a here-document puts space instead of the first IFS char.

[Robert Elz]

    Date:        Sat, 17 Feb 2024 01:41:11 +0100
    From:        Damien ISSANCHOU <d.issanchou@gmail.com>
    Message-ID:  <cdf26925-098f-476c-a6eb-6698ca41ddb4@gmail.com>

  | Even though the online Bash Reference manual only explicitly states 
  | the POSIX behaviour when the expansion of the special parameter * occurs 
  | within double-quotes, it seems that it is also implemented in other 
  | contexts where field splitting shall not be performed such as within 
  | here strings.

Note that a here doc without a quoted end word (after <<) is essentially
a double quoted string - apart from the " character being nothing special
in it, it shoud be treated exactly as a double quoted string would be.

(If the end word were quoted, then the here doc would be a single
quoted string - except without ' meaning anything - which is a very
boring case.)

The leading tab removal that happens with <<- is a separate issue,
that happens when the here doc is being read, rather than when it
is being expanded (when it is used.)

  |      Maybe bash could implement the POSIX.1 behaviour for $* within 
  | here-documents, which would make the * special parameter and the * 
  | "special" array subscript much more look-alike.

It certainly should.

How the implementation makes this happen is its business, but there's
really just one $* expansion which can be used in all situations.
That is the positional params separated by the first char of $IFS
(with the usual rule for when that is empty or unset applying).

In the cases where the $* was unquoted, and in a context where
field splitting occurs, those IFS characters that were inserted
are all removed again by the field splitting algorithm, so sometimes
it appears as if that is a different expansion kind which doesn't
use IFS at all - and could be implemented that way, but there's
really no need, field splitting still needs to happen, in case
one of the positional params has an IFS char in it, and it can be
tricky to get that right if that char is first or last in the
positional param if the algorithm isn't fully implemented (including
actually splitting based upon the inserted IFS chars between the
positional params).

kre