On Sun, 02 Apr 2023 09:32:20 +0700
Robert Elz wrote:
> Date:Sat, 1 Apr 2023 19:44:10 -0400
> From:Saint Michael
> Message-ID:
>
>
> | The compelling reason is: I may not know how many values are stored in the
> | comma-separated list.
>
> Others have told
Date:Sat, 1 Apr 2023 18:49:56 -0600
From:Felipe Contreras
Message-ID:
| Fortunately kre did listen.
Not really.I agree that what POSIX currently says is not correct,
which is why the defect report got filed (you may have noticed that there
was no new wording
Date:Sat, 1 Apr 2023 19:44:10 -0400
From:Saint Michael
Message-ID:
| The compelling reason is: I may not know how many values are stored in the
| comma-separated list.
Others have told you you're wrong, but this is not any kind of compelling
reason - you
On Sat, Apr 1, 2023, at 9:27 PM, Kerin Millar wrote:
> On Sat, 1 Apr 2023 19:44:10 -0400
> Saint Michael wrote:
>
>> There is an additional problem with IFS and the command read
>>
>> Suppose I have variable $line with a string "a,b,c,d"
>> IFS=',' read -r x1 <<< $line
>> Bash will assign the
On Sat, 1 Apr 2023 19:44:10 -0400
Saint Michael wrote:
> There is an additional problem with IFS and the command read
>
> Suppose I have variable $line with a string "a,b,c,d"
> IFS=',' read -r x1 <<< $line
> Bash will assign the whole line to x1
> echo $x1
> line="a,b,c,d";IFS=',' read -r x1
point, you are missing mine
Begin forwarded message:
> From: Emanuele Torre
> Subject: Re: IFS field splitting doesn't conform with POSIX
> Date: March 30, 2023 at 1:48:54 PM EDT
> To: Felipe Contreras
> Cc: bug-bash@gnu.org
>
> On Thu, Mar 30, 2023 at 11:35:08AM -0600, Fel
On Sat, Apr 1, 2023 at 6:35 PM Lawrence Velázquez wrote:
>
> On Sat, Apr 1, 2023, at 8:02 PM, Felipe Contreras wrote:
> > In that example they are discussing whether or not to make that
> > behavior a *requirement*. That is prescriptive.
>
> You're so busy pretending this is debate club that
On Sat, Apr 1, 2023, at 8:02 PM, Felipe Contreras wrote:
> In that example they are discussing whether or not to make that
> behavior a *requirement*. That is prescriptive.
You're so busy pretending this is debate club that you're completely
missing everyone's point, which is that the Austin
On Thu, Mar 30, 2023 at 1:20 PM Lawrence Velázquez wrote:
> On Thu, Mar 30, 2023, at 2:25 PM, Felipe Contreras wrote:
> > The challenge is in deciding what they *should* do, which is not
> > descriptive, but prescriptive.
>
> The Austin Group does not see its role as prescriptive, although
>
On Sat, Apr 01, 2023 at 07:44:10PM -0400, Saint Michael wrote:
> There is an additional problem with IFS and the command read
>
> Suppose I have variable $line with a string "a,b,c,d"
> IFS=',' read -r x1 <<< $line
[...]
https://mywiki.wooledge.org/BashPitfalls#pf47
There is an additional problem with IFS and the command read
Suppose I have variable $line with a string "a,b,c,d"
IFS=',' read -r x1 <<< $line
Bash will assign the whole line to x1
echo $x1
line="a,b,c,d";IFS=',' read -r x1 <<< $line;echo $x1;
a,b,c,d
but if I use two variables
On Sat, Apr 01, 2023 at 03:27:47PM -0400, Lawrence Velázquez wrote:
> On Fri, Mar 31, 2023, at 2:10 PM, Chet Ramey wrote:
> > kre filed an interpretation request to get the language cleaned up.
>
> For those who might be interested:
>
> https://austingroupbugs.net/view.php?id=1649
Thanks for
On Fri, Mar 31, 2023, at 2:10 PM, Chet Ramey wrote:
> kre filed an interpretation request to get the language cleaned up.
For those who might be interested:
https://austingroupbugs.net/view.php?id=1649
--
vq
On 3/30/23 3:18 PM, Lawrence Velázquez wrote:
In my view if POSIX was merely descriptive, then the Austin Group
would have no need to discuss much, as it's fairly easy to describe
what current shells do.
Composing technical specifications that describe implementations'
shared behaviors while
On 3/30/23 12:51 PM, Felipe Contreras wrote:
It could very well mean that all shells are implementing POSIX wrong.
Except zsh.
No, interpretations have confirmed that not generating a final empty field
is correct. It's just not clear enough in the text.
--
``The lyf so short, the craft so
On 3/30/23 7:12 AM, Felipe Contreras wrote:
Hi,
Consider this example:
IFS=,
str='foo,bar,,roo,'
printf '"%s"\n' $str
There is a discrepancy between how this is interpreted between bash
and zsh: in bash the last comma doesn't generate a field and is
ignored, in zsh a last empty
On Mär 30 2023, Felipe Contreras wrote:
> On Thu, Mar 30, 2023 at 10:10 AM Oğuz İsmail Uysal
> wrote:
>>
>> On 3/30/23 2:12 PM, Felipe Contreras wrote:
>> > IFS=,
>> > str='foo,bar,,roo,'
>> > printf '"%s"\n' $str
>> zsh is the only shell that generates an empty last field, no
On Thu, Mar 30, 2023, at 2:25 PM, Felipe Contreras wrote:
> On Thu, Mar 30, 2023 at 11:48 AM Oğuz İsmail Uysal
> wrote:
>>
>> On 3/30/23 7:51 PM, Felipe Contreras wrote:
>> > So? This is argumentum ad populum. The fact that most shells do X
>> > doesn't imply that POSIX says X.
>
>> POSIX
On Thu, 30 Mar 2023 11:52:06 -0600
Felipe Contreras wrote:
> Chet wrote:
> > Alternately, you can think of the NUL at the end of the string as an
> > additional field terminator,
>
> Except if you do that, then 'a,' has two fields since the end of the
> string is an additional field terminator,
On Thu, Mar 30, 2023 at 11:48 AM Oğuz İsmail Uysal
wrote:
>
> On 3/30/23 7:51 PM, Felipe Contreras wrote:
> > So? This is argumentum ad populum. The fact that most shells do X
> > doesn't imply that POSIX says X.
> POSIX documents existing practice.
Your definition of what a standard is and
On Thu, Mar 30, 2023 at 11:52:06AM -0600, Felipe Contreras wrote:
> Not to mention the small detail that the Internal Field Separator is
> not a *separator*, but a terminator (with certain exceptions).
POSIX itself admits that the name is confusing. From sh(1posix):
RATIONALE
[...]
On Thu, Mar 30, 2023 at 11:22 AM Kerin Millar wrote:
>
> On Thu, 30 Mar 2023 07:51:59 -0600
> Felipe Contreras wrote:
>
> > On Thu, Mar 30, 2023 at 5:23 AM Greg Wooledge wrote:
> > >
> > > On Thu, Mar 30, 2023 at 05:12:46AM -0600, Felipe Contreras wrote:
> > > > IFS=,
> > > >
On Thu, Mar 30, 2023 at 11:35:08AM -0600, Felipe Contreras wrote:
> > How can you say that the current implementation that bash, dash, etc.
> > use is not compliant to the POSIX specification?
>
> I have never said that.
The title of this thread is "IFS field splitting doe
On 3/30/23 7:51 PM, Felipe Contreras wrote:
So? This is argumentum ad populum. The fact that most shells do X
doesn't imply that POSIX says X.
POSIX documents existing practice. If what it says differs from what the
majority of shells do, then it's POSIX that is wrong. And this mailing
list
On Thu, Mar 30, 2023 at 9:52 AM Emanuele Torre wrote:
>
> On Thu, Mar 30, 2023 at 07:51:59AM -0600, Felipe Contreras wrote:
> > But you can't replicate 'a,b' that way, because b does not have a
> > terminator. Obviously we'll want 'b' as a field, therefore one has to
> > assume either 1) the end
On Thu, Mar 30, 2023 at 10:51:58AM -0600, Felipe Contreras wrote:
> On Thu, Mar 30, 2023 at 10:10 AM Oğuz İsmail Uysal
> wrote:
> >
> > On 3/30/23 2:12 PM, Felipe Contreras wrote:
> > > IFS=,
> > > str='foo,bar,,roo,'
> > > printf '"%s"\n' $str
> > zsh is the only shell that
On Thu, 30 Mar 2023 07:51:59 -0600
Felipe Contreras wrote:
> On Thu, Mar 30, 2023 at 5:23 AM Greg Wooledge wrote:
> >
> > On Thu, Mar 30, 2023 at 05:12:46AM -0600, Felipe Contreras wrote:
> > > IFS=,
> > > str='foo,bar,,roo,'
> > > printf '"%s"\n' $str
> > >
> > > There is a
On Thu, Mar 30, 2023 at 10:10 AM Oğuz İsmail Uysal
wrote:
>
> On 3/30/23 2:12 PM, Felipe Contreras wrote:
> > IFS=,
> > str='foo,bar,,roo,'
> > printf '"%s"\n' $str
> zsh is the only shell that generates an empty last field, no other shell
> exhibits this behavior.
So? This is
On 3/30/23 2:12 PM, Felipe Contreras wrote:
IFS=,
str='foo,bar,,roo,'
printf '"%s"\n' $str
zsh is the only shell that generates an empty last field, no other shell
exhibits this behavior.
Besides your link says:
>The shell shall treat each character of the IFS as a delimiter
On Thu, Mar 30, 2023 at 07:51:59AM -0600, Felipe Contreras wrote:
> But you can't replicate 'a,b' that way, because b does not have a
> terminator. Obviously we'll want 'b' as a field, therefore one has to
> assume either 1) the end of the string is considered an implicit
> terminator, or 2) the
On Thu, Mar 30, 2023 at 5:23 AM Greg Wooledge wrote:
>
> On Thu, Mar 30, 2023 at 05:12:46AM -0600, Felipe Contreras wrote:
> > IFS=,
> > str='foo,bar,,roo,'
> > printf '"%s"\n' $str
> >
> > There is a discrepancy between how this is interpreted between bash
> > and zsh: in bash the
how spooky , cant get read / mapfile to separate right
very sad
On Thu, Mar 30, 2023, 15:19 Felipe Contreras
wrote:
> Hi,
>
> Consider this example:
>
> IFS=,
> str='foo,bar,,roo,'
> printf '"%s"\n' $str
>
> There is a discrepancy between how this is interpreted between bash
> and
Hi,
Consider this example:
IFS=,
str='foo,bar,,roo,'
printf '"%s"\n' $str
There is a discrepancy between how this is interpreted between bash
and zsh: in bash the last comma doesn't generate a field and is
ignored, in zsh a last empty field is generated. Initially I was going
to
On Thu, Mar 30, 2023 at 05:12:46AM -0600, Felipe Contreras wrote:
> IFS=,
> str='foo,bar,,roo,'
> printf '"%s"\n' $str
>
> There is a discrepancy between how this is interpreted between bash
> and zsh: in bash the last comma doesn't generate a field and is
> ignored,
... which is
Hi,
Consider this example:
IFS=,
str='foo,bar,,roo,'
printf '"%s"\n' $str
There is a discrepancy between how this is interpreted between bash
and zsh: in bash the last comma doesn't generate a field and is
ignored, in zsh a last empty field is generated. Initially I was going
to
35 matches
Mail list logo
