Re: Question on $@ vs $@$@

[Steffen Nurpmeso]

Robert Elz wrote in
 <26326.1724474200@jacaranda.noi.kre.to>:
 |    Date:        Fri, 23 Aug 2024 23:47:06 +0200
 |    From:        Steffen Nurpmeso <steffen@sdaoden.eu>
 |    Message-ID:  <20240823214706.oskn9OEF@steffen%sdaoden.eu>
 |
 || So IFS whitespace only if part of $IFS.
 |
 |That is the definition of IFS whitespace.
 |
 || So this "adjacent" even if *not* part of $IFS.
 |
 |No, only characters that are in IFS are ever delimiters (really terminat\
 |ors).
 |
 || So this means that *regardless* of whatever $IFS is, the three IFS
 || whitespace characters are $IFS anyway *if* that is set to
 || a nin-empty non-default value.
 |
 |No.   Only if they are in IFS.   If we have IFS=': ' then colon and
 |space are IFS characters, space is IFS whitespace, and tab and newline
 |are simply characters.

Hm i have to think about this on Monday.  That is not what i read
from the standard, and here it started working once i checked
those in addition in the case where IFS is set non-NUL and
non-default.

 |What is important about space (0x20) tab (0x09) and newline (0x0a)
 |is that if they appear in IFS, they are IFS whitespace.   Whether
 |other characters for which isspace() might return true (or the wide
 |equivalent thereof where appropriate) are IFS whitespace or not
 |is implementation defined (and usually, not).
 |
 |Since you're clearly looking at the new (Issue 8) standard, look
 |at the 6th paragraph of XCU 2.6.5 which starts "For the purposes
 |of this section,..." and goes on to define exactly what the
 |term "IFS whitespace" means.

I will read that again.

 ||  If the  value  of IFS is null, no word splitting occurs.
 |
 |Correct.
 |
 || I have to say i still have a lot of problems wrapping my head
 || against the term
 |
 |Almost everyone has problems understanding how field splitting
 |really works.   It is odd (historically odd).
 |
 || It seems to me, now, that the actual point here is that IFS
 || whitespace can give no empty output in say a IFS=: case, whereas
 || the colon in $IFS *can* create empty output tokens.
 |
 |First, fields, not tokens.   Tokens are what passes from lexical
 |analysis to the parser (and IFS has nothing whatever to do with that)
 |- there is no parsing happening here (doing field splitting).
 |
 |But Yes.   With F=foo::bar and G='foo  bar' (two spaces) then
 |with IFS=' :' (the order only matters when expanding "$*")
 |argc $F gives 3 and argc $G gives 2.   [argc() is just argc() { echo $#; }]
 |
 |If H were ' foo:  : bar: ' argc $H would be 3  ("foo" "" and "bar").
 |
 |kre
 |
 |ps: the hope was that the text that is now in 2.6.5 would finally be
 |explicit enough that it would be possible to read that, completely,
 |and then implement it properly.

This particular 2.6.5 is a terribly worded section, very hard to
grasp.  The bash manual is much easier, it says

  A sequence of IFS whitespace characters is also treated as
  a delimiter.

 --End of <26326.1724474200@jacaranda.noi.kre.to>

A nice Sunday dear kre@, list,
Ciao from Germany,

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)