On 1/13/25 2:02 PM, Steffen Nurpmeso wrote:
Chet Ramey wrote in
:
|On 1/12/25 6:25 PM, Steffen Nurpmeso wrote:
|
|> Should be doable for bash in the "no-argument" case, which
|> currently works though POSIX requires at least one argument:
|
|If `read' isn't supplied any variable nam
Chet Ramey wrote in
:
|On 1/12/25 6:25 PM, Steffen Nurpmeso wrote:
|
|> Should be doable for bash in the "no-argument" case, which
|> currently works though POSIX requires at least one argument:
|
|If `read' isn't supplied any variable name arguments, bash assigns the
|unmodified line, with
On 1/13/25 12:55 AM, Robert Elz wrote:
Date:Sun, 12 Jan 2025 22:39:57 -0500
From:Greg Wooledge
Message-ID: <20250113033957.gc27...@wooledge.org>
| At the risk of going a bit off topic, may I ask *why* the shell does
| that? Were there any files or data str
On 1/12/25 8:42 PM, Robert Elz wrote:
chet.ra...@case.edu said:
| Which basically means that the last variable gets everything else on the
| line, including non-whitespace IFS characters.
Whitespace IFS characters are included as well, just not leading, or trailing
IFS whitespace, any oth
On 1/12/25 6:25 PM, Steffen Nurpmeso wrote:
Should be doable for bash in the "no-argument" case, which
currently works though POSIX requires at least one argument:
If `read' isn't supplied any variable name arguments, bash assigns the
unmodified line, without any trailing delimiter, to REPLY.
On Mon, Jan 13, 2025 at 04:11:46 -0500, Lawrence Velázquez wrote:
> What exactly is all of this supposed to demonstrate? mapfile has
> the same terminator-not-separator behavior everyone is kvetching
> about:
>
> $ printf 'a:b:c:' | { mapfile -td:; declare -p MAPFILE; }
> declare -a M
On Mon, Jan 13, 2025, at 3:03 AM, Félix Hauri wrote:
> Re-reading man page and this discussion, I thing either this variable is
> wrongly named "IFS", as `S` stand for "separator"
Okay. Not like it's going to change.
> Btw, the command "mapfile" (readarray) seem more suitable** than "read" for
does the output @ https://0x0.st/8-Fv.txt
make it into the race
by cmd @ https://0x0.st/8-Ft.txt
i can be as well fully off the topic
excuse me then , and plz lemme know ..
On Mon, Jan 13, 2025, 9:03 AM Félix Hauri wrote:
> Le Sun, Jan 12, 2025 at 04:10:03PM -0500, Chet Ramey a écrit :
> >
On Mon, Jan 13, 2025, 4:46 AM Greg Wooledge wrote:
> On Mon, Jan 13, 2025 at 08:42:39 +0700, Robert Elz wrote:
> > It is unexpected, because users believe (from other experience)
> > that the delimiters separate fields, but in sh they don't, they
> > terminate fields.
>
> At the risk of going a b
Le Sun, Jan 12, 2025 at 04:10:03PM -0500, Chet Ramey a écrit :
>
> This is a simplified version how it works: after you remove leading
> and trailing IFS whitespace, you read individual fields from the input
> using the characters in IFS as field terminators.
> If you get to the last variable a
Date:Sun, 12 Jan 2025 22:39:57 -0500
From:Greg Wooledge
Message-ID: <20250113033957.gc27...@wooledge.org>
| At the risk of going a bit off topic, may I ask *why* the shell does
| that? Were there any files or data stream conventions in common use
| in the 1970s
On Mon, Jan 13, 2025 at 08:42:39 +0700, Robert Elz wrote:
> It is unexpected, because users believe (from other experience)
> that the delimiters separate fields, but in sh they don't, they
> terminate fields.
At the risk of going a bit off topic, may I ask *why* the shell does
that? Were there a
Date:Sun, 12 Jan 2025 16:55:05 -0500
From:Greg Wooledge
Message-ID: <20250112215505.gb27...@wooledge.org>
| Right. You explained why it works the way it does. But from a user's
| point of view, it's just unexpected behavior.
It is unexpected, because users beli
Greg Wooledge wrote in
<20250112215505.gb27...@wooledge.org>:
|On Sun, Jan 12, 2025 at 16:26:04 -0500, Chet Ramey wrote:
|>> In this case, we get the "expected" result:
|>
|> You just restated the original example while ignoring the part of my
|> message about looking for additional input af
On 1/12/25 4:55 PM, Greg Wooledge wrote:
On Sun, Jan 12, 2025 at 16:26:04 -0500, Chet Ramey wrote:
In this case, we get the "expected" result:
You just restated the original example while ignoring the part of my
message about looking for additional input after you find a delimiter.
Right. Y
On Sun, Jan 12, 2025 at 16:26:04 -0500, Chet Ramey wrote:
> > In this case, we get the "expected" result:
>
> You just restated the original example while ignoring the part of my
> message about looking for additional input after you find a delimiter.
Right. You explained why it works the way it
On 1/12/25 4:19 PM, Greg Wooledge wrote:
On Sun, Jan 12, 2025 at 16:10:03 -0500, Chet Ramey wrote:
This is a combination of two rules: characters in IFS are field
terminators, not separators, and when `read' is supplied fewer
variables than fields,
"Any remaining input in the original field bei
On Sun, Jan 12, 2025, at 10:19 AM, MacBeth wrote:
> On Sun, Jan 12, 2025 at 8:58 AM MacBeth wrote:
>
>> And here is a version you would have to use without `sed` to get the line
>> first, before you can append the field terminator to it:
>>
>> delim=,
>> {
>> while IFS= read -r row; do
>>
On Sun, Jan 12, 2025 at 16:10:03 -0500, Chet Ramey wrote:
> This is a combination of two rules: characters in IFS are field
> terminators, not separators, and when `read' is supplied fewer
> variables than fields,
>
> "Any remaining input in the original field being processed shall be
> returned t
On 1/11/25 9:54 AM, MacBeth wrote:
Bash Version: 5.2
Patch Level: 37
Release Status: release
Description:
It seems that `read` truncates a trailing delimiter if there is one less
variable argument than input fields and the last field is empty (trailing
delimiter).
This is a combination of tw
On Sun, Jan 12, 2025 at 8:58 AM MacBeth wrote:
> On Sun, Jan 12, 2025 at 8:24 AM Félix Hauri wrote:
>
>> Le Sat, Jan 11, 2025 at 10:49:50AM -0500, Greg Wooledge a écrit :
>> > https://mywiki.wooledge.org/BashPitfalls#pf47
>> > "It's a feature."
>> >
>> -- how do we work around this nonsense?
>>
On Sun, Jan 12, 2025 at 8:24 AM Félix Hauri wrote:
> Le Sat, Jan 11, 2025 at 10:49:50AM -0500, Greg Wooledge a écrit :
> > https://mywiki.wooledge.org/BashPitfalls#pf47
> > "It's a feature."
> >
> -- how do we work around this nonsense?
>
> I've alredy noticed this, but never stictly tested them
Le Sat, Jan 11, 2025 at 10:49:50AM -0500, Greg Wooledge a écrit :
> https://mywiki.wooledge.org/BashPitfalls#pf47
> "It's a feature."
>
-- how do we work around this nonsense?
I've alredy noticed this, but never stictly tested them as:
for row in k{:v1{:v2{:{:{:,},},},:{:{:,},},},:{:{:,},},}
On Sat, Jan 11, 2025 at 08:54:43 -0600, MacBeth wrote:
> It seems that `read` truncates a trailing delimiter if there is one less
> variable argument than input fields and the last field is empty (trailing
> delimiter).
https://mywiki.wooledge.org/BashPitfalls#pf47
"It's a feature."
Configuration Information [Automatically generated, do not change]:
Machine: aarch64
OS: darwin23.4.0
Compiler: clang
Compilation CFLAGS: -DSSH_SOURCE_BASHRC
-DDEFAULT_LOADABLE_BUILTINS_PATH='/opt/homebrew/Cellar/bash/5.2.37/lib/bash:/usr/local/lib/bash:/usr/lib/$
Machine Type: aarch64-apple-darwin
25 matches
Mail list logo
