Re: Another $@ expansion issue

Robert Elz wrote, on 28 Feb 2019: > > | However, given that the most widely used modern shells produce a null > | field, I believe we should make this unspecified rather than forcing > | them to change. > > Then the question becomes just how we do that. [snip] > The problem is a tendency

[1003.1(2016)/Issue7+TC2 0001230]: Require bc implementations to allow arrays as last parameter

The following issue has been RESOLVED. == http://austingroupbugs.net/view.php?id=1230 == Reported By:gavin_howard Assigned To:

[1003.1(2016)/Issue7+TC2 0001185]: Additional 3rd option for getting line size.

The following issue has been RESOLVED. == http://austingroupbugs.net/view.php?id=1185 == Reported By:dannyniu Assigned To:

[1003.1(2013)/Issue7+TC1 0001158]: Please, use dashs (i. e. "-") consistently in the document and make it searchable

The following issue has a resolution that has been APPLIED. == http://austingroupbugs.net/view.php?id=1158 == Reported By:safinaskar

Re: [1003.1(2008)/Issue 7 0000472]: strftime %C does not account for sign character

The new wording still doesn't make explicit padding characters for wider field widths than 3 shall be '0', not , to address Bug 1184. What's on the etherpad does have this. Some may argue the minimum field width for "%+" should be 3, as well, as required sign character ('+'/'-') plus 2 digits;

[1003.1(2016)/Issue7+TC2 0001184]: strftime %C padding character unspecified

The following issue has been set as DUPLICATE OF issue 472. == http://austingroupbugs.net/view.php?id=1184 == Reported By:dennisw

[1003.1(2008)/Issue 7 0000472]: strftime %C does not account for sign character

The issue 0001184 has been set as DUPLICATE OF the following issue. == http://austingroupbugs.net/view.php?id=472 == Reported By:markh

[1003.1(2008)/Issue 7 0000472]: strftime %C does not account for sign character

A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=472 == Reported By:markh Assigned To:ajosey

Re: [1003.1(2008)/Issue 7 0000472]: strftime %C does not account for sign character

Shware Systems wrote, on 28 Feb 2019: > > The new wording still doesn't make explicit padding characters for wider > field widths than 3 shall be '0', not , to address Bug 1184. What's on > the etherpad does have this. The behaviour is explicitly unspecified if a conversion contains a field

[1003.1(2008)/Issue 7 0000472]: strftime %C does not account for sign character

The following issue has been UPDATED. == http://austingroupbugs.net/view.php?id=472 == Reported By:markh Assigned To:ajosey

[1003.1(2016)/Issue7+TC2 0001184]: strftime %C padding character unspecified

The following issue has been CLOSED. == http://austingroupbugs.net/view.php?id=1184 == Reported By:dennisw Assigned To:

[1003.1(2013)/Issue7+TC1 0000680]: pselect EINTR error case clarification

The following issue has been set as RELATED TO issue 0001186. == http://austingroupbugs.net/view.php?id=680 == Reported By:mdempsky Assigned

[1003.1(2016)/Issue7+TC2 0001186]: pselect specification allows for race condition that pselect was created to avoid

The following issue has been set as RELATED TO issue 680. == http://austingroupbugs.net/view.php?id=1186 == Reported By:davmac Assigned

Re: Another $@ expansion issue

Date:Thu, 28 Feb 2019 12:04:25 + From:Geoff Clare Message-ID: <20190228120425.GA10849@lt2.masqnet> To take this in something of a reverse order... | As far as I can see this agrees with the examples in XRAT C.2.5.2. It was intended to - nothing there was