Re: printf '%s\n' "$@" versus <<< redirection

[Greg Wooledge]

On Tue, Feb 21, 2023 at 12:44:02AM +0100, Mike Jonkmans wrote:
> On Mon, Feb 20, 2023 at 10:40:13AM -0500, Chet Ramey wrote:
> > On 2/18/23 12:45 PM, Mike Jonkmans wrote:
> > 
> > > > "If IFS is unset, or its value is exactly <space><tab><newline>, the 
> > > > default, then sequences of <space>, <tab>, and <newline> at the 
> > > > beginning and end of the results of the previous expansions are 
> > > > ignored, and any sequence of IFS characters not at the beginning or end 
> > > > serves to delimit words."
> > > 
> > > If IFS is unset then it is slightly ambiguous as to what the IFS 
> > > characters are,
> > > in the last part of this sentence.
> > 
> > If IFS is unset, word splitting and other uses behave as if it had the
> > default value of space, tab, newline.
> 
> True.
> But, if i have not overlooked this, it is not stated in the documentation.
> 
> Perhaps your text could be added to the description of IFS
> in the 'Shell Variables' section.

You have to start with the POSIX documentation, because in most cases
the bash documentation follows the POSIX wording, in whole or in part.

Field splitting is documented at
<https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_05>
and says, in part:

 1. If the value of IFS is a <space>, <tab>, and <newline>, or if it is
    unset, any sequence of <space>, <tab>, or <newline> characters at
    the beginning or end of the input shall be ignored and any sequence
    of those characters within the input shall delimit a field.

 [...]

 3. a. IFS white space shall be ignored at the beginning and end of the input.

This is where the crazy wording comes from.  Instead of just saying
"IFS whitespace is ignored at the beginning and end of the input" and
"If IFS is unset, it behaves like <space><tab><newline>" it uses this
redundant wording.

The wording implies that $' \t\n' is special and should somehow be
treated differently from $'\t \n' or any other rearrangement when it
comes to field splitting, but it's not.  It's just confusing.

All the shell documentation which starts from this definition is going
to inherit that confusion.