The following issue has been SUBMITTED.
==
http://austingroupbugs.net/view.php?id=1123
==
Reported By:kre
Assigned To:
===
A NOTE has been added to this issue.
==
http://austingroupbugs.net/view.php?id=1123
==
Reported By:kre
Assigned To:
=
A NOTE has been added to this issue.
==
http://austingroupbugs.net/view.php?id=1123
==
Reported By:kre
Assigned To:
=
A NOTE has been added to this issue.
==
http://austingroupbugs.net/view.php?id=1123
==
Reported By:kre
Assigned To:
=
A NOTE has been added to this issue.
==
http://austingroupbugs.net/view.php?id=1123
==
Reported By:kre
Assigned To:
=
A NOTE has been added to this issue.
==
http://austingroupbugs.net/view.php?id=1123
==
Reported By:kre
Assigned To:
=
The following issue has been set as RELATED TO issue 0001193.
==
http://austingroupbugs.net/view.php?id=1123
==
Reported By:kre
Assigned To:
The following issue has been RESOLVED.
==
http://austingroupbugs.net/view.php?id=1123
==
Reported By:kre
Assigned To:
===
The issue 0001297 has been set as DUPLICATE OF the following issue.
==
http://austingroupbugs.net/view.php?id=1123
==
Reported By:kre
Assigne
The following issue has a resolution that has been APPLIED.
==
http://austingroupbugs.net/view.php?id=1123
==
Reported By:kre
Assigned To:
The following issue has been CLOSED
==
https://austingroupbugs.net/view.php?id=1123
==
Reported By:kre
Assigned To:
=
For anyone who follows this stuff from the mailing list
messages, rather than viewing the issues web page,
note that I made 3 small edits to note 4070 as it was
sent to the list (all inconsequentially really, but...)
Two of them were to fix the range of line numbers in the
third last line of the n
> --
> (0004073) kre (reporter) - 2018-08-06 15:06
> http://austingroupbugs.net/view.php?id=1123#c4073
> --
> Thanks for note 4072.
>
> Upon reflection, the
Date:Mon, 6 Aug 2018 16:48:29 +0100
From:Geoff Clare
Message-ID: <20180806154829.GA30598@lt2.masqnet>
| For step 1 this would conflict with 2.5.2 which says that empty fields
| resulting from expanding @ and * _may_ be discarded. Your suggestion
| would require
Robert Elz wrote, on 06 Aug 2018:
>
> | For step 1 this would conflict with 2.5.2 which says that empty fields
> | resulting from expanding @ and * _may_ be discarded. Your suggestion
> | would require them to be discarded instead of it being optional.
>
> Is that any different from what i
Geoff Clare wrote, on 07 Aug 2018:
>
> Robert Elz wrote, on 06 Aug 2018:
> >
> > | For step 1 this would conflict with 2.5.2 which says that empty fields
> > | resulting from expanding @ and * _may_ be discarded. Your suggestion
> > | would require them to be discarded instead of it being
Date:Fri, 10 Aug 2018 09:02:47 +0100
From:Geoff Clare
Message-ID: <20180810080247.GA20183@lt2.masqnet>
| The paragraph should be deleted.
Unfortunately, that is not good enough.There needs to be text somewhere
allowing empty fields to be removed (aside from whe
Robert Elz wrote, on 10 Aug 2018:
>
> set --; A=; for x in a $A b $* c; do printf "[%s]\n" "$x"; done
>
> needs to produce
>
> [a]
> [b]
> [c]
[...]
> So, perhaps back to something more like the proposed text for
> this paragraph in note 4071, but changed from "an empty
Geoff Clare wrote, on 10 Aug 2018:
>
> Robert Elz wrote, on 10 Aug 2018:
> >
> > set --; A=; for x in a $A b $* c; do printf "[%s]\n" "$x"; done
> >
> > needs to produce
> >
> > [a]
> > [b]
> > [c]
[...]
> > A=: ; IFS=: ; for x in a $A b; do printf "[%s]\n" "$x"; done
> >
On this issue, I have also finally realised the answer to another thing
that had perplexed me for ages (not about the standard, well, perhaos
a fix is required, but not all that significant) and certainly not about
what the shells should, or do, produce, which is clear, but about how
people speak a
Robert Elz wrote, on 10 Aug 2018:
>
> For this, I'd suggest rewriting the offending paragraph of 2.6 to be:
>
> Tilde expansions, parameter expansions, command substitutions,
> arithmetic expansions, and quote removals that occur within a single
> word expand to a single field.
Date:Fri, 10 Aug 2018 14:33:37 +0100
From:Geoff Clare
Message-ID: <2018081017.GA24957@lt2.masqnet>
| I don't see the need to have an intermediate fix in 1123; it will just
| create extra work to edit both bugs. They will both go into the next
| update to th
Robert Elz wrote, on 10 Aug 2018:
>
> | I don't see the need to have an intermediate fix in 1123; it will just
> | create extra work to edit both bugs. They will both go into the next
> | update to the standard, whatever that is (TC3 or Issue 8).
>
> You are presuming that 1193 will not be
Date:Fri, 10 Aug 2018 13:30:28 +0100
From:Geoff Clare
Message-ID: <20180810123028.GA23963@lt2.masqnet>
| Actually, I think the existing description of Field Splitting handles
| it correctly.
I disagree, but not for the reason that I think you believe...
| It m
Robert Elz wrote, on 10 Aug 2018:
>
> But given the way that the text is written (lines 74994-5):
>
> It is only field splitting or pathname expansion that can create
> multiple
> fields from a single word. The single exception...
>
> it is really hard to read it as "0 is permitted"
Date:Fri, 10 Aug 2018 16:26:13 +0100
From:Geoff Clare
Message-ID: <20180810152613.GA26492@lt2.masqnet>
| Brace expansion is widely implemented, so the chance it will be rejected
| is zero.
I agree that something needs to be done, but it might not be 1193.
To me
Date:Fri, 10 Aug 2018 16:48:29 +0100
From:Geoff Clare
Message-ID: <20180810154829.GA26874@lt2.masqnet>
| Wouldn't simply changing
| "multiple fields" to "multiple fields or no fields" solve it?
I am sure there are many ways it could be solved. That is one,
if
Date:Fri, 10 Aug 2018 16:48:29 +0100
From:Geoff Clare
Message-ID: <20180810154829.GA26874@lt2.masqnet>
| Wouldn't simply changing
| "multiple fields" to "multiple fields or no fields" solve it?
There was one more thing I meant to say about that solution,
which I
On 8/10/18 9:15 AM, Robert Elz wrote:
> On this issue, I have also finally realised the answer to another thing
> that had perplexed me for ages (not about the standard, well, perhaos
> a fix is required, but not all that significant) and certainly not about
> what the shells should, or do, produce
Date:Wed, 15 Aug 2018 11:52:26 -0400
From:Chet Ramey
Message-ID: <15dace22-8fe3-ea87-fa7b-3ed9f2e77...@case.edu>
| > Expands to the positional parameters, starting from one, initially
| > producing one field for each positional parameter that is set.
|
| T
Date:Thu, 16 Aug 2018 06:16:26 +0700
From:Robert Elz
Message-ID: <19788.1534374...@jinx.noi.kre.to>
| when quoted "$*" was just "$1 $2 $3 ..." (I am not sure I really understood
IFS
| back then, or even if the first implementation used it
I checked, it didn't,
Robert Elz wrote:
> But from my first introduction to the Bourne shell (1979) I never thought
> that $* or $@ meant anything different than $1 $2 $3 ... and that when
> quoted "$*" was just "$1 $2 $3 ..." (I am not sure I really understood IFS
> back then, or even if the first implementation used
Date:Thu, 16 Aug 2018 11:02:08 +0200
From:Joerg Schilling
Message-ID: <5b753d90.jtPS/gtrnxgoklle%joerg.schill...@fokus.fraunhofer.de>
| $@ has been introduced in 1986 after people discovered that $* is not
useful to
| forward an arg vector without modifying it.
Robert Elz wrote:
> Date:Thu, 16 Aug 2018 11:02:08 +0200
> From:Joerg Schilling
> Message-ID:
> <5b753d90.jtPS/gtrnxgoklle%joerg.schill...@fokus.fraunhofer.de>
>
> | $@ has been introduced in 1986 after people discovered that $* is not
> useful to
> | forward
On 8/16/18 6:55 AM, Joerg Schilling wrote:
> I took the information from:
>
> https://www.in-ulm.de/~mascheck/bourne/
>
> and it mentions "modern $@"
`Modern "$@"' means the current expansion behavior of "$@" when there are
no positional parameters. This eliminated the need for the ${1+"$@"} id
On 8/15/18 7:16 PM, Robert Elz wrote:
> That is, they existed as a way for a script to write out all the positional
> parameters one after another, without knowing how many there were.
>
> With that view, how they should work has never been even slightly
> confusing.But perhaps others learned
Joerg Schilling wrote in <5b755811.4gvXMuw2qARTfcZr%Joerg.Schilling@foku\
s.fraunhofer.de>:
|Robert Elz wrote:
|> Date:Thu, 16 Aug 2018 11:02:08 +0200
|> From:Joerg Schilling
|> Message-ID: <5b753d90.jtPS/GTrnxGokLLE%Joerg.Schilling@fokus.fraunho\
|> fer.de>
Date:Thu, 16 Aug 2018 12:55:13 +0200
From:Joerg Schilling
Message-ID: <5b755811.4gvxmuw2qartfczr%joerg.schill...@fokus.fraunhofer.de>
| and it mentions "modern $@"
|
| Maybe at that time, they changed the behavior to become useful.
That might be when the "$@" w
Robert Elz wrote, on 11 Aug 2018:
>
> | Wouldn't simply changing
> | "multiple fields" to "multiple fields or no fields" solve it?
>
> There was one more thing I meant to say about that solution,
> which I forgot originally, and then again when I last replied to this.
>
> If you do it this
Geoff Clare wrote, on 10 Aug 2018:
>
> Actually, I think the existing description of Field Splitting handles
> it correctly.
[...]
> So I think just deleting that paragraph, as bugnote 4082 currently has
> it, is the right thing to do.
I decided that this was worth an explicit mention in Field S
Date:Fri, 24 Aug 2018 10:26:06 +0100
From:Geoff Clare
Message-ID: <20180824092606.GA18062@lt2.masqnet>
First, wrt your previous message (earlier in the week) ... the comments of
mine to which you referred were based upon an even earlier message of
yours, and what I th
Robert Elz wrote, on 24 Aug 2018:
>
> | On page 2359 line 75273 section 2.6.5, change:
> |
> | If the value of IFS is null, no field splitting shall be performed.
> |
> | to:
> |
> | If the value of IFS is null, field splitting shall have no effect,
> | except that if t
42 matches
Mail list logo
