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 Mon, 13 Jan 2025, Chet Ramey wrote:
>> NEWS, bash-5.1, item 1.o. says:
>> o. Bash posix mode now treats assignment statements preceding shell
>> function definitions the same as in its default mode, since POSIX
>> has changed and no longer requires those assignments to persist after
>> t
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 1/10/25 1:12 PM, Ulrich Müller wrote:
NEWS, bash-5.1, item 1.o. says:
o. Bash posix mode now treats assignment statements preceding shell function
definitions the same as in its default mode, since POSIX has changed and
no longer requires those assignments to persist after the functio
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
12 matches
Mail list logo
