On 8/26/24 8:21 PM, Steffen Nurpmeso wrote:
Chet Ramey wrote in
<bcb2ec08-42a1-4dff-9941-9f562f123...@case.edu>:
|On 8/23/24 5:47 PM, Steffen Nurpmeso wrote:
|> If IFS has a value other than the default, then sequences of the
|> whitespace characters space, tab, and newline are ignored at the
|> beginning and end of the word, as long as the whitespace
|> character is in the value of IFS (an IFS whitespace charac‐
|> ter).
So an IFS whitespace character is one that is in the value of IFS.
|>
|> So IFS whitespace only if part of $IFS.
|>
|> Any character in IFS that is not IFS whitespace, along
|> with any adjacent IFS whitespace characters, delimits a field.
|>
|> So this "adjacent" even if *not* part of $IFS.
|
|I am genuinely curious how you concluded this, given the definition you
|previously quoted.
It is only skipping ("trimming away") further data without further
delimiting if only IFS whitespace is seen.
The definition of IFS whitespace requires that the characters be part of
the value of IFS, so I'm wondering how you arrived at the "not part of
$IFS" above. Do you mean that IFS whitespace characters are the only ones
where multiple instances of those characters can delimit a single field?
If I can increase that section's clarity, I'm all for it. It's a confusing
topic.
|> A sequence of IFS whitespace characters is also treated as
|> a delimiter.
|>
|> 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.
|
|Nonsense.
How you interpret this "also" if not so, that is the question.
My impression was that you had an eye on the standard text and
tried to vaporise it down to the core. Very well.
You have to look at the definition of IFS whitespace.
--
``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/
