All
Enclosed are the minutes from last weeks meeting
regards
Andrew
----
Minutes of the 20th March 2025 Teleconference Austin-1449 Page 1 of 1
Submitted by Andrew Josey, The Open Group. 24th March 2025
Attendees:
Don Cragun, IEEE SA OR
Andrew Josey, The Open Group
Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR
Eric Ackermann, CISPA
Geoff Clare, The Open Group
Eric Blake, Red Hat, The Open Group OR
Haelwenn Monnier, The Open Group
Apologies
Mark Brown
Note that daylight savings times started in the US on 2025-03-09
and so the meetings will be 1 hour earlier in Europe until 2025-03-31.
We confirmed the calendar for upcoming meetings, adding a meeting
on April 3rd.
There is no update on the latest ISO status.
* Open Business
Bug 1876: clarify, whether a trap action that is executed from a OPEN
context where set -e is ignored, would have set -e ignored, too
https://www.austingroupbugs.net/bug_view_page.php?bug_id=1876
Andrew took an action to ask shell developers to comment on this
issue. (completed by sending an email to the reflector:
austin-group-l:archive/latest/37925).
Bug 864: Insufficient specification of storage requirements for synchronization
objects
https://www.austingroupbugs.net/view.php?id=864
AI: Andrew to contact Rich Felker to determine whether or not items
1 an 4 have been resolved by section 2.9.9 and to get suggested
wording for changes to address items 2 and 3. The action was
completed, but no response received as yet.
Bug 1904: LC_TIME era start_date (and end_date) possibly mis-specified
https://www.austingroupbugs.net/bug_view_page.php?bug_id=1904
This was discussed during the 2025-02-13 meeting:
Historically, there was no year 0 and the standard is worded
to reflect this fact. Is this what implementation actually do?
Andrew had completed an action to ask for input on what other implementations
do and some feedback has been received so need to return to this on a future
call.
* Current Business
We skipped over bug 1913 as discussion is ongoing.
Bug 1914: expr: short-circuit evaluation
https://www.austingroupbugs.net/bug_view_page.php?bug_id=1914
Accepted as marked, resolved, tc1-2024 tag.
On page 2916 line 97320 section expr, add a sentence in "Description" column
for "&":
If expr1 is null or zero, it is unspecified whether expr2 is evaluated.
On page 2916 line 97323 section expr, add a sentence in "Description" column
for "|":
If expr1 is neither null nor zero, it is unspecified whether expr2 is
evaluated.
After page 2919 line 97410 section expr (RATIONALE), add a paragraph:
Implementations differ as to whether the '&' and '|' operators
``short-circuit'' (that is, whether they evaluate expr2 if the
return value can be deduced from evaluating just expr1).
Consequently, the observed behavior may differ when evaluating
expr2 would cause an error (or a signal), such as dividing by
zero.
Bug 1915: clarification of 2.6.5 field splitting of 2.5.2 special parameter $*
https://www.austingroupbugs.net/view.php?id=1915
Left for now since there is discussion ongoing on email.
Bug 1857: Several problems with the new "lazy" regex quantifier.
https://www.austingroupbugs.net/bug_view_page.php?bug_id=1857
Reopened, accepted as marked, Interpretation required, tc1-2024 tag.
Timer started 2025-03-21.
We revised the notes to the editors, and have restarted the interpretation
timer.
The interpretation remains unchanged.
On page 179 line 6348 section 9.1, add a sentence:
The matching process is described in [xref to 9.2].
and move the remaining paragraphs of the "matching" definition to
after page 181 line 6413 section 9.2.
On page 179 line 6357 section 9.1, change:
If the pattern permits a variable number of matching characters
and thus there is more than one such sequence starting at that
point, the longest such sequence is matched. For example, the
BRE "bb*" matches the second to fourth characters of the string
"abbbc", and the ERE "(wee|week)(knights|night)" matches all
ten characters of the string "weeknights".
Consistent with the whole match being the longest of the leftmost
matches, each subpattern, from left to right, shall match the
longest possible string.
to:
If the pattern permits a variable number of matching characters
and thus there is more than one such sequence starting at that
point, the match shall be made according to the following rules:
1. For a BRE, or an ERE that does not use the repetition modifier
'?', the match shall be the leftmost longest.
2. If an ERE contains repetitions with and without the repetition
modifier '?', the precedence between the repetitions shall be:
a. Each leftmost shortest match shall match the leftmost
shortest sequence in the string, in descending priority
from left to right.
b. Consistent with rule 2a, the length matched by the entire
regular expression shall be the leftmost longest.
c. Consistent with rules 2a and 2b, each leftmost longest
match shall match the leftmost longest sequence in the
string, in descending priority from left to right.
d. If an attempt is made to match the same sequence of the
string using repetitions both with and without the repetition
modifier '?', the behavior is unspecified. For example, the
ERE ([0-9]+)+? has unspecified behavior.
According to these rules, the BRE "bb*" matches the second to
fourth characters of the string "abbbc", and the ERE
"(wee|week)(knights|night)" matches all ten characters of the
string "weeknights". However, the ERE "(aaa??)*" matches only
the first four characters of the string "aaaaa", not all five,
because in order to match all five, "a??" would match with
length one instead of zero; the ERE "(aaa??)*|(aaa?)*" matches
all five because the longest match is one which does not use
any minimal repetitions.
Consistent with the match for the entire regular expression
being made according to the above rules, each BRE or ERE in a
concatenated set, from left to right, shall match according to
the above rules, applied to that BRE or ERE.
On page 180 line 6367 section 9.1, change:
the subpattern "(.*?)" matches the empty string, since that is
the longest possible match for the ERE ".*?"
to:
the subexpression "(.*?)" matches the empty string, since the
minimal repetition ".*?" has priority and the empty string is
the shortest possible match (zero length) for that repetition.
On page 179 line 6370 section 9.1, change:
the longest sequence shall be measured
to:
the sequence length shall be measured
After page 191 line 6814 section 9.5, add a note:
<small>Note:The grammar defines syntax only and places no
requirements on implementations as to how the parsed BRE or ERE
is used for matching. The matching process is described in [xref
to 9.2].</small>
After XRAT page 3716 line 127617 section A.9.4.6, add a paragraph:
Note that the repetition modifier '?' (<question-mark>) is
specified as changing the matching behavior for the modified
repetition from the leftmost longest possible match to the
leftmost shortest possible match. This does not necessarily
give the same result as matching with the least repetitions.
For example, the ERE "([ab]{6}|a)*?b" matches the first five
characters of the string "aaaabbbb" as this is the shortest for
the minimal repetition "*?". Matching with the least repetitions
would match the first seven characters by using one repetition
of "[ab]{6}" instead of four repetitions of "a". This distinction
is only possible because the alternatives in an ERE alternation
are chosen according to which gives the longest (or shortest)
match. Other types of regular expression exist (notably in perl,
php, and python) where the alternatives are tried in order; for
those there is no difference between longest and most repetitions
or between shortest and least repetitions.
Next Steps
We will start on bug 1913 next time.
The next calls are on
Thu 2025-03-27 (WEBEX meeting - general bugs)
Thu 2025-04-03 (WEBEX meeting - general bugs)
The calls are for 90 minutes
Calls are anchored on US time. (8am Pacific)
Please check the calendar invites for dial in details.
Bugs are at:
https://austingroupbugs.net
An etherpad is usually up for the meeting, with a URL using the date
format as below:
https://posix.rhansen.org/p/20xx-mm-dd
(For write access this uses The Open Group single sign on,
for those individuals with gitlab.opengroup.org accounts.
Please contact Andrew if you need to be setup)
--------
Andrew Josey The Open Group
Austin Group Chair
Email: a.jo...@opengroup.org
Apex Plaza, Forbury Road,Reading,Berks.RG1 1AX,England
To learn how we maintain your privacy, please review The Open Group Privacy
Statement at http://www.opengroup.org/privacy.
To unsubscribe/opt-out from this mailing list login to The Open Group
collaboration portal at
https://collaboration.opengroup.org/operational/portal.php?action=unsub&listid=2481
