Re: Availability of 202x Draft 4.1
Hi Andrew, I'm new to this, so bear with me if this isn't the right way to report this small issue: On page 3732, "New features in Issue 8", the new _Fork() function introduced on page 574 and described starting at page 983 seems to be missing. Is that somehow deliberate? Thanks, Corinna On Feb 16 17:44, Andrew Josey via austin-group-l at The Open Group wrote: > > hi all, > > I'm pleased to announce the availability of draft 4.1 of the 202x revision of > the standard. > > The draft can be obtained from the login page of the Austin Group at: > https://www.opengroup.org/austin/login.html > > This is intended as the final draft, and is undergoing a 10 day recirculation > at IEEE and the Sanity review at The Open Group. > > Since this is a recirculation draft, narrowing down rules apply and you may > only comment on sections of the document that have changed as a result of the > comments made against draft 4 > which are a small number of editorials. > > A separate report is available with the draft. > Any comments should be submitted to the Austin Group reflector. > > > regards > Andrew > > > 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=2481 > > > > >
Availability of 202x Draft 4.1
hi all, I'm pleased to announce the availability of draft 4.1 of the 202x revision of the standard. The draft can be obtained from the login page of the Austin Group at: https://www.opengroup.org/austin/login.html This is intended as the final draft, and is undergoing a 10 day recirculation at IEEE and the Sanity review at The Open Group. Since this is a recirculation draft, narrowing down rules apply and you may only comment on sections of the document that have changed as a result of the comments made against draft 4 which are a small number of editorials. A separate report is available with the draft. Any comments should be submitted to the Austin Group reflector. regards Andrew Andrew JoseyThe 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=2481
Minutes of the 15th February 2024 Teleconference
hi all Enclosed are the minutes from yesterday’s meeting regards Andrew -- Minutes of the 15th February 2024 TeleconferenceAustin-1385 Page 1 of 1 Submitted by Andrew Josey, The Open Group. 16th February 2024 Attendees: Don Cragun, IEEE SA OR Nick Stoughton, Logitech/USENIX, ISO/IEC JTC 1/SC 22 OR Geoff Clare, The Open Group Eric Ackermann, CISPA Andrew Josey, The Open Group Eric Blake, Red Hat, The Open Group OR Mark Ziegast, SHware Systems Dev. * General news We finalized the cover letter for Draft 4.1 and that will be released shortly for the Sanity review at The Open Group, and a 10 day recirculation at IEEE. We discussed the IEEE roster, which had triggered several emails to those attending the call. Andrew reported that he had commenced work on the html conversion process. The plan is to encapsulate this in a docker image, with the aim to integrate to the current gitlab project which creates the pdf. * Current Business 1797: strftime "%s" should be able to examine tm_gmtoff OPEN https://austingroupbugs.net/bug_view_page.php?bug_id=1797 Andrew took an action to invite Paul Eggert to the call on February 22nd. Bug 1801: xargs: add -P optionAccepted as Marked https://austingroupbugs.net/view.php?id=1801 This item is tagged for Issue 9 . Change line 123162 from: [-s size] [utility [argument...]] to: [-P maxprocs] [-s size] [utility [argument...]] Add at line 123252: -P maxprocs Parallel mode: execute at most maxprocs invocations of utility concurrently. If the value of maxprocs is non-positive, the behavior is unspecified. Remove the FUTURE DIRECTIONS entry added by 0001811. Bug 1811: xargs: add -P option to FUTURE DIRECTIONS section Accepted https://austingroupbugs.net/view.php?id=1811 This item is tagged for TC1-2024. 1798: Must posix_getdents remember file offsets across exec? OPEN https://austingroupbugs.net/view.php?id=1798 Notes are in the etherpad from a previous meeting, this item to be continued. Next Steps -- The next call is on: Mon 2024-02-19 (Zoom meeting - general bugs) Thu 2024-02-22 (Zoom 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 JoseyThe 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=2481
[Issue 8 drafts 0001813]: generic xargs description cleanups
The following issue has been SUBMITTED.
==
https://austingroupbugs.net/view.php?id=1813
==
Reported By:kre
Assigned To:
==
Project:Issue 8 drafts
Issue ID: 1813
Category: Shell and Utilities
Type: Error
Severity: Editorial
Priority: normal
Status: New
Name: Robert Elz
Organization:
User Reference:
Section:XCU 3 / xargs
Page Number:3600-3603
Line Number:123177-8 123183 123184-6 123228-32 123233-7 123252-3
123263 123304-6
Final Accepted Text:
==
Date Submitted: 2024-02-16 14:42 UTC
Last Modified: 2024-02-16 14:42 UTC
==
Summary:generic xargs description cleanups
Description:
Since "xargs" has "been in the news" recently...And while this issue
is
specified to apply to Issue 8 Draft 4 (which is where the page/line
numbers
are from) I would assume it would eventually be moved to Issue 8, after it
is published, and probably be considered for Issue 8 TC 1.
Most of this is just text that should be worded better, but there are a
few omissions that ought to be included.
Lines 123177-8 - two different issues here. First, arguments are said
to be delimited by an alternation of 3 terms - unquoted , unescaped
or newline. The problem is that nothing quoted can be escaped,
and nothing escaped can be quoted, hence any that appears is
either
an unquoted or an unescaped and hence is a delimiter
character
according to that definition.
Second (same lines, but continuing perhaps) we have quoting, and escaping,
but nothing here actually says that the quoting " or ' chharacters, or the
excaping \ character are removed from the arg text - which is what I
assume
should happen, ie: in "abc def'"'ghi\jkl'\ m I would assume the argument
string is to be abc def'ghi\jkl m with the quoting and escaping
characters removed. But nothing says that, one could also read the text
as including those chars in the arg string, with the quoting or escaping
simply avoiding enclosed characters from being delimiters (and
quoted or escaped quote or escape characters from being quote or escape
characters).
Line 123183 "Any unquoted character" can be escaped, must include
as that's certainly a character, and isn't allowed to be quoted
(incidentally
nothing says what is to be done if a appears after an initial
opening quote before its companion closing quote - that might be intended
to
be treated as an error, or the might just terminate the quoting,
or the might just be a single unquoted character (which would be
a delimiter if -0 is not used) in the middle of otherwise quoted text, so
'abc
def'
would be two args, "abc" (and any invisible here following chars),
and those leading chars followed by "def". Unlikely, but
possible.
That was a side issue ... for line 123183, the issue is what does an
escaped
mean - at line 123178 it doesn't say that only non-escaped
chars are delimiters, all characters are,. About all I can see
about escaped is that the results are unspecified if the eof
string
follows one of those. I might guess that an escaped is intended
to
be removed from the input (both the escape and the but at the
minute
I don't see where anything says that.
Lines 123228-32: In the first bullet point, if -s is not specified, then
if number generates a command line longer than LINE_MAX but shorter than
{ARG_MAX}-2048 then it seems to imply that less than number args must be
used, to keep the command line length shorter than LINE_MAX. Why? That
seems like a thinko, lines 123202-3 just say that the default command line
length is at least LINE_MAX - in most cases it will be considerably
larger.
Then, same lines, the second bullet point says that fewer args (that
number)
shall be used if the last iteration has fewer than number operands
remaining
(that makes sense) - but not if there are zero. A strict reading of that
would result in the interpretation that the last invocation in that case
must
be padded to have number args ... (no idea how to accomplish that) - but
that's clearly not what it intended to say. More importantly, if there
are
zero args remaining, the previous iteration wouild have been the last,
this
one would not exist. Normally - there's still the case where the last
iteration is the first iteration, and -r was not given. In that case,
one
would assume that the utility should be run with no args (as it would if
there
[Issue 8 drafts 0001801]: xargs: add -P option
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1801 == Reported By:mohd_akram Assigned To: == Project:Issue 8 drafts Issue ID: 1801 Category: Shell and Utilities Type: Enhancement Request Severity: Editorial Priority: normal Status: Resolved Name: Mohamed Akram Organization: User Reference: Section:xargs Page Number:3600-3601 Line Number:123162, 123252 Final Accepted Text:See https://austingroupbugs.net/view.php?id=1801#c6657. Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2024-01-25 21:39 UTC Last Modified: 2024-02-16 11:31 UTC == Summary:xargs: add -P option == Relationships ID Summary -- related to 0001811 xargs: add -P option to FUTURE DIRECTIO... == -- (0006660) kre (reporter) - 2024-02-16 11:31 https://austingroupbugs.net/view.php?id=1801#c6660 -- Please, I thought the bad old days of just copying man page descriptions were beyond us - things really need to be better than this. There's not nearly enough description of what is supposed to be happening with this option to expect an implementation to do what is expected (whatever that is). For example, how are the args read from stdin supposed to be apportioned amongst the parallel invocations of the utility? One might expect that perhaps the idea is to read enough args until the command line limit is reached, and then start reading more for the next parallel invocation. But that means that if there happen to be not all that many args, then perhaps no parallelism would be achieved, when if less args had been allocated to each invocation, more parallel instances could have been invoked. Or, we could allocate the args to intended utility invocations round-robin, first arg read to the first invocation, 2nd to the second, ... until there have been maxprocs args read (assuming there are that many on stdin) after which we add a second arg to the first invocation, etc. This avoids the issue mentioned for the previous style, but does mean that xargs doesn't start invoking anything for longer - if utility is fast enough, it might be able to process its args faster than xargs is able to read from stdin and prepare the args for the subsequent process - resulting in an overall slowdown from running in parallel, rather than a speedup. Beyond that, "execute ... concurrently" might be read as meaning that all the (up to maxprocs) invvocations should be made to run at the same time. To achieve that, the implementation would need to start them all at the same time, otherwise the first started might finish before the last is ready to commence, so they wouldn't be running concurrently. I doubt that's what is intended, but perhaps. And even more, how are these parallel invocations expected to interact with the CONSEQUENCES OF ERRORS section of the spec (page 3603 in D4 of I8). That is, if an invocation of utility does exit 255, or is killed by a signal, how is xargs supposed to terminate without processing any further input, when it has already processed more, and started more invocations of the utility? And what is to be done with those other invocations still running when one exits in one of those ways - are they to be killed, orphaned, or is xargs to wait for them to finish before terminating? In that latter case, should more diagnostic messages be written if more of the invocations also exit 255, or via a signal? There may be more issues I haven't yet realised. This needs to go back to the drawing board and start all over again, with a much more comprehensive and standards worthy wording added. But there's no hurry, as this is to be an Issue 9 change, there is perhaps a decade or two before an actual resolution is needed. Issue History Date ModifiedUsername FieldChange == 2024-01-25 21:39 mohd_akram New Issue
[1003.1(2008)/Issue 7 0001812]: Support xargs -P 0
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1812 == Reported By:dwheeler Assigned To:ajosey == Project:1003.1(2008)/Issue 7 Issue ID: 1812 Category: Shell and Utilities Type: Enhancement Request Severity: Editorial Priority: normal Status: Under Review Name: David A. Wheeler Organization: The Linux Foundation User Reference: Section:xargs Page Number:3600-3601 Line Number:123252 Interp Status: --- Final Accepted Text: == Date Submitted: 2024-02-15 20:53 UTC Last Modified: 2024-02-16 11:39 UTC == Summary:Support xargs -P 0 == -- (0006661) kre (reporter) - 2024-02-16 11:39 https://austingroupbugs.net/view.php?id=1812#c6661 -- I agree with https://austingroupbugs.net/view.php?id=1812#c6659 (had intended to say much the same thing), other than the possible use of SC_NPROCESSORS_ONLN probably (maybe that's better than nothing, but probably not). While that value has its uses, apportioning cpus to tasks isn't one of them, as not all cpus in a system are created equal any more - some are more suited for one kind of task, and others for different activities (which doesn't even begin to address whether the peculiar "hyperthreading" cpus count for any of this). I certainly agree with deferring a decision on this, and all other issue 9 matters (probably even Issue 8 TC1 matters) until after issue 8 is published (no reason why discussions cannot happen leading to a potential resolution however). Issue History Date ModifiedUsername FieldChange == 2024-02-15 20:53 dwheeler New Issue 2024-02-15 20:53 dwheeler Status New => Under Review 2024-02-15 20:53 dwheeler Assigned To => ajosey 2024-02-15 20:53 dwheeler Name => David A. Wheeler 2024-02-15 20:53 dwheeler Organization => The Linux Foundation 2024-02-15 20:53 dwheeler Section => xargs 2024-02-15 20:53 dwheeler Page Number => 3600-3601 2024-02-15 20:53 dwheeler Line Number => 123252 2024-02-16 10:28 geoffclare Note Added: 0006659 2024-02-16 11:39 kreNote Added: 0006661 ==
[1003.1(2008)/Issue 7 0001812]: Support xargs -P 0
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1812 == Reported By:dwheeler Assigned To:ajosey == Project:1003.1(2008)/Issue 7 Issue ID: 1812 Category: Shell and Utilities Type: Enhancement Request Severity: Editorial Priority: normal Status: Under Review Name: David A. Wheeler Organization: The Linux Foundation User Reference: Section:xargs Page Number:3600-3601 Line Number:123252 Interp Status: --- Final Accepted Text: == Date Submitted: 2024-02-15 20:53 UTC Last Modified: 2024-02-16 10:28 UTC == Summary:Support xargs -P 0 == -- (0006659) geoffclare (manager) - 2024-02-16 10:28 https://austingroupbugs.net/view.php?id=1812#c6659 -- The wording "as many processes as possible" is problematic. An implementation could conform to this by just forking until it gets EAGAIN, which would not be good. Slightly better would be "an implementation-defined maximum number of processes", but this would still allow the same poor implementation: it would just need to document that number as being CHILD_MAX. In Issue 8 we have sysconf(SC_NPROCESSORS_ONLN) so perhaps we should involve that somehow, but we would need to assess whether existing implementations would conform to the new requirement. The best time to make a decision on this would probably be after we begin work on Issue 9, rather than now. Issue History Date ModifiedUsername FieldChange == 2024-02-15 20:53 dwheeler New Issue 2024-02-15 20:53 dwheeler Status New => Under Review 2024-02-15 20:53 dwheeler Assigned To => ajosey 2024-02-15 20:53 dwheeler Name => David A. Wheeler 2024-02-15 20:53 dwheeler Organization => The Linux Foundation 2024-02-15 20:53 dwheeler Section => xargs 2024-02-15 20:53 dwheeler Page Number => 3600-3601 2024-02-15 20:53 dwheeler Line Number => 123252 2024-02-16 10:28 geoffclare Note Added: 0006659 ==
[Issue 8 drafts 0001798]: Must posix_getdents remember file offsets across exec?
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1798 == Reported By:eblake Assigned To: == Project:Issue 8 drafts Issue ID: 1798 Category: System Interfaces Type: Clarification Requested Severity: Objection Priority: normal Status: New Name: Eric Blake Organization: Red Hat User Reference: ebb.posix_getdents Section:XSH posix_getdents Page Number:1567 Line Number:52609 Final Accepted Text: == Date Submitted: 2024-01-22 15:13 UTC Last Modified: 2024-02-16 10:18 UTC == Summary:Must posix_getdents remember file offsets across exec? == -- (0006658) corinna_vinschen (reporter) - 2024-02-16 10:18 https://austingroupbugs.net/view.php?id=1798#c6658 -- >From Cygwin's side, the problem is this: The underlying non-POSIXy kernel does not allow lseek(2) operations on directory descriptors, not even requesting a position within the directory. The only available seek-like operation is equivalent to lseek(dirfd, SEEK_SET, 0). Therefore we have to use a DIR* and the entire operation of position bookkeeping is performed in user space. If the standard strives to allow implementing posix_getdents() using DIR* under the hood, the standard should be clear on the subject that DIR is not dup(2)'able the same way as the dir descriptor given as argument to posix_getdents(). DIR is, by and large, a user-space object while the descriptor is a kernel object. DIR has never been meant as a dup'able object and there's no precedent for such a functionality. As such, there's no way to keep the dup'ed DIR* in sync after such a duplication. The same problem occurs with fork(2), which is just a more thorough dup(2) in terms of descriptors. Bottom line is, with user-space DIR* with enforced user space bookkeeping, there's no way after dup(2)/fork(2) to keep the directory position info in sync. Consequentially, there should be no assumption made how posix_getdents() behaves after dup(2) or fork(2). I.e. using the descriptors with posix_getdents() or readdir() in parallel should be undefined behaviour. If you're interested in code, I invite you to take a look into the current, preliminary implementation of posix_getdents() in Cygwin: https://cygwin.com/cgit/newlib-cygwin/commit/?id=62ca95721a14 As the commit outlines, the code does not try to keep track of the hidden DIR at all. Thanks, Corinna Issue History Date ModifiedUsername FieldChange == 2024-01-22 15:13 eblake New Issue 2024-01-22 15:13 eblake Name => Eric Blake 2024-01-22 15:13 eblake Organization => Red Hat 2024-01-22 15:13 eblake User Reference=> ebb.posix_getdents 2024-01-22 15:13 eblake Section => XSH posix_getdents 2024-01-22 15:13 eblake Page Number => 1567 2024-01-22 15:13 eblake Line Number => 52609 2024-01-22 15:30 eblake Note Added: 0006632 2024-01-22 15:39 eblake Note Edited: 0006632 2024-02-16 10:18 corinna_vinschenNote Added: 0006658 ==
