Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #15841 > unrolled thread
| Started by | Clint Hepner <clint.hepner@gmail.com> |
|---|---|
| First post | 2020-01-29 10:46 -0500 |
| Last post | 2020-01-29 10:46 -0500 |
| Articles | 1 — 1 participant |
Back to article view | Back to gnu.bash.bug
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: read and inconsistent handling of trailing null field? Clint Hepner <clint.hepner@gmail.com> - 2020-01-29 10:46 -0500
| From | Clint Hepner <clint.hepner@gmail.com> |
|---|---|
| Date | 2020-01-29 10:46 -0500 |
| Subject | Re: read and inconsistent handling of trailing null field? |
| Message-ID | <mailman.38.1580312750.2384.bug-bash@gnu.org> |
> On 2020 Jan 29 , at 10:30 a, Chet Ramey <chet.ramey@case.edu> wrote:
>
> On 1/29/20 10:19 AM, Clint Hepner wrote:
>
>> Bash Version: 5.0
>> Patch Level: 11
>> Release Status: release
>>
>> Description:
>>
>> read seems to incorrectly drop a null field when performing word-splitting and more fields than variables.
>>
>> All the examples below use
>>
>> IFS== read -r n v
>>
>> for some input of the form ``name=var...``
>>
>>
>> The relative bit of the POSIX spec concerns how to set the variables when there are fewer arguments
>> to read than there are fields.
>
> There are exactly two variables and two (split) arguments.
>
> "The shell shall treat each character of the IFS as a delimiter and use the
> delimiters as field terminators to split..."
>
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_05
>
>
Ah, OK. So if I have
IFS=, read -r n v <<< "a,b,c,"
there are two variables and 3 split arguments: "a", "b", and "c". Then according to the
specification for read, "a" is assigned to n, and we assign to v as follows:
1. first add the second field "b": v=b
2. then the delimiter following "b": v=b,
3. The remaining fields and their delimiters: first v=b,c then v=b,c,
So the final "," in the value of v isn't separating c and a mythical null field, but
is terminating the final field c.
Then
IFS=, read -r n v <<< "a,b,,"
has fields "a", "b", and "", and again v is assigned "b", ",", "", ",".
Thanks Chet and Greg (for pointing out https://mywiki.wooledge.org/BashPitfalls#pf47)
--
Clint
Back to top | Article view | gnu.bash.bug
csiph-web