Robert Elz wrote in
<[email protected]>:
| Date: Tue, 27 Aug 2024 22:02:34 +0200
| From: Steffen Nurpmeso <[email protected]>
| Message-ID: <20240827200234.95X76_wN@steffen%sdaoden.eu>
|
|
|| Any character in IFS delimits a field, adjacent IFS whitespace
|| characters are then ignored.
|
|Not quite. Any sequence of any amount of IFS whitespace, and no
|more than one other IFS character delimits a field.
That confuses me again, unfortunately i got a bug report and
distracted. I mean, i would
1. skip leading whitespace anyhow (IFS or not, which
is a "documented bug" here i would say),
for the shell this would be: leading IFS whitespace,
2. pass by none-to-many non-IFS bytes, the "field data", then
3.
a. if there is a non-IFS-whitespace character:
- delimit the field, even with empty "field data",
b. if there is a IFS-whitespace character:
- delimit the field only with non-empty "field data",
4. skip trailing (new leading) (IFS-) whitespace
|| To the contrary i would now say that with a non-default non-empty
|| $IFS only IFS characters that are not also IFS whitespace create
|| empty fields.
|
|The preconditions there are irrelevant.
|Only IFS chars that are not IFS whitespace create empty fields.
Yes.
|Where IFS is empty, there are no IFS chars, hence nothing delimits
|a field. When IFS is unset (default case) it consists of $' \t\n'
|(there is no difference whatever, for field splitting, or "$*" for
|that matter) between an unset IFS and IFS=$' \t\n'
|
|||You have to look at the definition of IFS whitespace.
|| Already forgotten at that point.
|
|Unfortunately, when reading the standard, you cannot forget a
|single word of it. Everything (normative) applies.
--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)
