[1003.1(2008)/Issue 7 0000367]: interaction between readonly, export, getopts, and read
The following issue has a resolution that has been APPLIED. == https://austingroupbugs.net/view.php?id=367 == Reported By:eblake Assigned To:ajosey == Project:1003.1(2008)/Issue 7 Issue ID: 367 Category: Shell and Utilities Type: Omission Severity: Objection Priority: normal Status: Applied Name: Eric Blake Organization: Red Hat User Reference: ebb.readonly Section:readonly Page Number:2352 Line Number:74359 Interp Status: Approved Final Accepted Text:See https://austingroupbugs.net/view.php?id=367#c675 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2011-01-06 23:30 UTC Last Modified: 2020-02-14 15:16 UTC == Summary:interaction between readonly, export, getopts, and read == Issue History Date ModifiedUsername FieldChange == 2011-01-06 23:30 eblake New Issue 2011-01-06 23:30 eblake Status New => Under Review 2011-01-06 23:30 eblake Assigned To => ajosey 2011-01-06 23:30 eblake Name => Eric Blake 2011-01-06 23:30 eblake Organization => Red Hat 2011-01-06 23:30 eblake User Reference=> ebb.readonly 2011-01-06 23:30 eblake Section => readonly 2011-01-06 23:30 eblake Page Number => 2352 2011-01-06 23:30 eblake Line Number => 74359 2011-01-06 23:30 eblake Interp Status => --- 2011-01-07 00:26 eblake Note Added: 645 2011-01-07 17:15 geoffclare Note Added: 646 2011-02-10 16:05 eblake Note Added: 673 2011-02-17 17:04 eblake Note Edited: 673 2011-02-17 17:10 eblake Note Edited: 673 2011-02-17 17:14 Don Cragun Note Added: 675 2011-02-17 17:15 Don Cragun Interp Status--- => Pending 2011-02-17 17:15 Don Cragun Final Accepted Text => See https://austingroupbugs.net/view.php?id=367#c675 2011-02-17 17:15 Don Cragun Status Under Review => Interpretation Required 2011-02-17 17:15 Don Cragun Resolution Open => Accepted As Marked 2011-02-17 17:16 Don Cragun Tag Attached: issue8 2011-03-15 14:45 ajosey Interp StatusPending => Proposed 2011-03-15 14:45 ajosey Note Added: 703 2011-04-26 15:10 ajosey Interp StatusProposed => Approved 2011-04-26 15:10 ajosey Note Added: 766 2020-02-14 15:16 geoffclare Status Interpretation Required => Applied ==
[1003.1(2008)/Issue 7 0000368]: Hidden file descriptors should be required to have the FD_CLOEXEC flag set and be closed when no longer needed.
The following issue has a resolution that has been APPLIED. == https://austingroupbugs.net/view.php?id=368 == Reported By:Don Cragun Assigned To:ajosey == Project:1003.1(2008)/Issue 7 Issue ID: 368 Category: System Interfaces Type: Omission Severity: Objection Priority: normal Status: Applied Name: Don Cragun Organization: Self User Reference: Use of hidden file descriptors Section:0 Page Number:0 Line Number:0 Interp Status: --- Final Accepted Text: Resolution: Accepted Fixed in Version: == Date Submitted: 2011-01-09 08:18 UTC Last Modified: 2020-02-14 15:34 UTC == Summary:Hidden file descriptors should be required to have the FD_CLOEXEC flag set and be closed when no longer needed. == Relationships ID Summary -- related to 149 Add fdwalk system interface related to 411 adding atomic FD_CLOEXEC support == Issue History Date ModifiedUsername FieldChange == 2011-01-09 08:18 Don Cragun New Issue 2011-01-09 08:18 Don Cragun Status New => Under Review 2011-01-09 08:18 Don Cragun Assigned To => ajosey 2011-01-09 08:18 Don Cragun Name => Don Cragun 2011-01-09 08:18 Don Cragun Organization => Self 2011-01-09 08:18 Don Cragun User Reference=> Use of hidden file descriptors 2011-01-09 08:18 Don Cragun Section => 0 2011-01-09 08:18 Don Cragun Page Number => 0 2011-01-09 08:18 Don Cragun Line Number => 0 2011-01-09 08:18 Don Cragun Interp Status => --- 2011-01-09 08:32 Don Cragun Note Added: 647 2011-01-09 08:32 Don Cragun Desired Action Updated 2011-01-09 08:33 Don Cragun Desired Action Updated 2011-01-13 16:47 msbrownRelationship added related to 149 2011-01-13 16:54 msbrownStatus Under Review => Resolved 2011-01-13 16:54 msbrownResolution Open => Accepted 2011-01-13 16:54 msbrownTag Attached: issue8 2011-01-13 16:55 Don Cragun Desired Action Updated 2011-01-13 20:22 tahonermannIssue Monitored: tahonermann 2011-04-20 17:03 eblake Relationship added related to 411 2020-02-14 15:34 geoffclare Status Resolved => Applied ==
RE: Is there an atomic compare-swap function/routine in the standard?
Presently, no. There are operations, such as with semaphores, where this sort of functionality might be used but has been left unspecified as many CPUs don't support exchanges; for most older ones only loads and stores are atomic, and the volatile modifier and sigatomic_t types are geared to be used this way. Without direct hardware support, on those systems some aspects of c11s stdatomic interfaces get a performance and code size penalty to emulate robustly; possibly why it's an optional header entirely. On Friday, February 14, 2020 Danny Niu wrote: As asked, is there an CMPXGCHG-like function in the standard? I tried looking for keywords such as cmp, comp, ch, but nothing turned up in the system interfaces list. The C language introduced atomic functions in C11 though.
Is there an atomic compare-swap function/routine in the standard?
As asked, is there an CMPXGCHG-like function in the standard? I tried looking for keywords such as cmp, comp, ch, but nothing turned up in the system interfaces list. The C language introduced atomic functions in C11 though.
Re: [1003.1(2004)/Issue 6 0000267]: time (keyword)
It is certainly a good thing that this has been reopened, as what
was proposed to be inserted is, frankly, nonsense.
It is not that I have anything against a time reserved word, though
being a reserved word rather than a builtin, or special builtin does
make it impossible to redirect (as has been noted) and also raises
questions as to what exactly happens on error (like an invalid format
string in TIMEFORMAT, or a command not found, etc) - does it act like
a special builtin with an error, or a regular command. Those kinds
of things could (and should) be fixed .. but that's more difficult
for a reserved word which doesn't have the utility page with its
standard format in which all of this has a natural place.
But the proposed grammar (and also one of the proposed replacements)
is broken, the "linebreak" non-terminal cannot be used the way it was
(and apparently still is) being proposed - doing so would make the
grammar ambiguous. That might be OK if you're feeding it to yacc,
where the shift/reduce conflict resolution rules will settle on one
interpretation, but is definitely inappropriate to use in a standard.
"linebreak" can only ever be used in a rule when there is at least
one more required syntactic element to follow - that isn't to say
that it cannot be the last element of a rule - but only when that
rule is embedded in another (or which is itself embedded in another)
in which something else (not a command termination) is required.
Or in other words, it is only ever used in places where the current
command cannot possibly end at the current place, and it is desired
to allow a newline to be inserted, such as after most reserved words,
after && || | (and similar, including '(' itself).
So
pipeline : pipe_sequence
| Bang linebreak
| (other stuff)
cannot be correct, as
linebreak : newline_list
| /* empty */
and_or : pipeline
| (other stuff)
list : and_or
|(other stuff)
complete_command : list separator_op
| list
complete_commands: complete_commands newline_list complete_command
| complete_command
program : linebreak complete_commands linebreak
| linebreak
If we were to have simply
!\n
as input (where the \n means a single newline character) then it is
ambiguous whether the newline matches the linebreak that is in "pipeline"
or the one in "program" and while that might seem insignificant, it isn't
for a grammar (and in more complex cases may make a real difference).
This problem is still in Mark's proposed replacement grammar, but isn't
in Stephane's (which is much better).
The original was much worse than this, I don't even want to contemplate
what
pipeline: pipe_sequence
| Bang linebreak
| Bang pipeline
| (even more)
is useful for, or why anyone could conceivably want that.
But since there are proposed replacements without that nonsense, I assume
that you're aware of just how absurd this all is, and so I can stop this
part here.
But the above raises another issue, this bug report is supposed to be
about the "time" reserved word (keyword) - why would any solution to
that be making any changes at all to the way that the ! reserved word
works? Surely that would need to be done in a bug about either ! itself,
or a more general pipeline syntax bug report. Dealing with "time" as a
reserved word is complex enough without trying to slip in modifications
to "!" at the same time (and doing a half baked job of it), for now can
I assume that the proposed changes to the way ! is defined to work will
be dropped from this issue ... if there is some real desire for this
change make it be a new issue (and then I will say why I think it is
a very poor idea there, rather than here).
(The same is true of the changes that seem to make minor unrelated
changes to the grammar, to fix minor issues that were noticed - strictly
they should be separate issues (or at least one) ... it is hard enough
to search for stuff in mantis to see what is in the queue to be changed
already, but it becomes impossible when changes are buried within other
issues that are unrelated ... but as these look to be trivial, and not
controversial at all, unless I missed something, never mind).
Now to the actual subject matter ... first, and comparatively minor,
is it really desirable to make a reserved word ("time") (and I mean
when it is a reserved word, but I'll come to that below) into also
being a command? This would be a first for the shell I believe, until
this, reserved words are only ever syntax, never commands. Even some
of what is often considered syntax is actually implemented as commands.
Have all of the ramifications of this been considered? Note that this
relates to the use of "time" as a command,
[1003.1(2008)/Issue 7 0000370]: addclose should not cause posix_spawn to fail if closing an already closed fd
The following issue has a resolution that has been APPLIED. == https://austingroupbugs.net/view.php?id=370 == Reported By:eblake Assigned To:ajosey == Project:1003.1(2008)/Issue 7 Issue ID: 370 Category: System Interfaces Type: Error Severity: Objection Priority: normal Status: Applied Name: Eric Blake Organization: Red Hat User Reference: ebb.posix_spawn Section:posix_spawn_file_actions_addclose Page Number:1430 Line Number:46882 Interp Status: Approved Final Accepted Text:See https://austingroupbugs.net/view.php?id=370#c718 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2011-01-13 16:48 UTC Last Modified: 2020-02-14 15:38 UTC == Summary:addclose should not cause posix_spawn to fail if closing an already closed fd == Relationships ID Summary -- related to 149 Add fdwalk system interface related to 418 posix_spawn_file_actions_addclose() sho... == Issue History Date ModifiedUsername FieldChange == 2011-01-13 16:48 eblake New Issue 2011-01-13 16:48 eblake Status New => Under Review 2011-01-13 16:48 eblake Assigned To => ajosey 2011-01-13 16:48 eblake Name => Eric Blake 2011-01-13 16:48 eblake Organization => Red Hat 2011-01-13 16:48 eblake User Reference=> ebb.posix_spawn 2011-01-13 16:48 eblake Section => posix_spawn_file_actions_addclose 2011-01-13 16:48 eblake Page Number => 1430 2011-01-13 16:48 eblake Line Number => 46882 2011-01-13 16:48 eblake Interp Status => --- 2011-01-13 17:04 Don Cragun Status Under Review => Resolved 2011-01-13 17:04 Don Cragun Resolution Open => Accepted 2011-01-13 17:04 Don Cragun Tag Attached: issue8 2011-01-13 17:05 Don Cragun Relationship added related to 149 2011-03-24 15:16 Don Cragun Interp Status--- => Pending 2011-03-24 15:16 Don Cragun Note Added: 718 2011-03-24 15:16 Don Cragun Status Resolved => Interpretation Required 2011-03-24 15:17 Don Cragun Final Accepted Text => See https://austingroupbugs.net/view.php?id=370#c718 2011-03-25 05:51 ajosey Interp StatusPending => Proposed 2011-03-25 05:51 ajosey Note Added: 724 2011-04-20 15:03 eblake Note Added: 745 2011-04-28 15:34 Don Cragun Note Edited: 718 2011-04-28 15:34 Don Cragun Resolution Accepted => Accepted As Marked 2011-05-05 20:09 ajosey Interp StatusProposed => Approved 2011-05-05 20:09 ajosey Note Added: 779 2011-06-02 16:10 eblake Relationship added related to 418 2020-02-14 15:38 geoffclare Status Interpretation Required => Applied ==
[1003.1(2008)/Issue 7 0000373]: make should allow dash in macro names
The following issue has a resolution that has been APPLIED. == https://austingroupbugs.net/view.php?id=373 == Reported By:eblake Assigned To:ajosey == Project:1003.1(2008)/Issue 7 Issue ID: 373 Category: Shell and Utilities Type: Omission Severity: Objection Priority: normal Status: Applied Name: Eric Blake Organization: Red Hat User Reference: ebb.make Section:make Page Number:2914 Line Number:95787 Interp Status: --- Final Accepted Text: Resolution: Accepted Fixed in Version: == Date Submitted: 2011-01-28 15:01 UTC Last Modified: 2020-02-14 15:41 UTC == Summary:make should allow dash in macro names == Relationships ID Summary -- related to 573 Please add '+' to the portable filename... == Issue History Date ModifiedUsername FieldChange == 2011-01-28 15:01 eblake New Issue 2011-01-28 15:01 eblake Status New => Under Review 2011-01-28 15:01 eblake Assigned To => ajosey 2011-01-28 15:01 eblake Name => Eric Blake 2011-01-28 15:01 eblake Organization => Red Hat 2011-01-28 15:01 eblake User Reference=> ebb.make 2011-01-28 15:01 eblake Section => make 2011-01-28 15:01 eblake Page Number => 2914 2011-01-28 15:01 eblake Line Number => 95787 2011-01-28 15:01 eblake Interp Status => --- 2011-02-03 16:25 eblake Note Added: 663 2011-09-08 16:30 nick Note Added: 956 2011-11-17 10:54 joerg Note Added: 0001025 2011-12-07 23:25 dwheeler Issue Monitored: dwheeler 2012-05-31 16:21 Don Cragun Status Under Review => Resolved 2012-05-31 16:21 Don Cragun Resolution Open => Accepted 2012-05-31 16:21 Don Cragun Tag Attached: issue8 2012-06-14 15:20 eblake Relationship added related to 573 2012-08-03 22:38 eadler Issue Monitored: eadler 2020-02-14 15:41 geoffclare Status Resolved => Applied ==
Minutes of the 13th February 2020 Teleconference
All Enclosed are the minutes from yesterdays call. Please note that the monday call next week is cancelled. regards Andrew - Minutes of the 13th February 2020 Teleconference Austin-1005 Page 1 of 1 Submitted by Andrew Josey, The Open Group. 14th February 2020 Attendees: Mark Ziegast, SHware Systems Dev. Co. Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR Joerg Schilling, FOKUS FRaunhofer Eric Ackermann, HPI, University of Potsdam Don Cragun, IEEE PASC OR Andrew Josey, The Open Group Eric Blake, Red Hat, Open Group OR Geoff Clare, The Open Group * General news The meeting scheduled for February 17th has been cancelled as this is a public holiday in the USA. The next meeting will be February 20th Nick had circulated an interim draft of C2x to the core team (for the purposes of standardization only). Joerg reported that the gettext proposal was progressing and expected to be submitted in March. * Outstanding actions (Please note that this section has been flushed to shorten the minutes - to locate the previous set of outstanding actions, look to the minutes from 13th June 2019 and earlier) Bug 1254: "asynchronous list" description uses "command" instead of "AND-OR list" OPEN https://austingroupbugs.net/view.php?id=1254 Action: Joerg to investigate how his shell behaves. Bug 700 - Nick to raise this issue with the C committee Bug 713 - Nick to raise with the C committee. Bug 739 - Nick to raise with the C committee. Bug 1216 - Eric to ask if The Open Group is willing to sponsor this interface, referencing bug note 4478. * Current Business Bug 267: time (keyword)Re-opened https://austingroupbugs.net/view.php?id=267#c4771 We continued discussions on this item, and will continue on this item next time. Details are in the etherpad, it now has its own page: https://posix.rhansen.org/p/bug267 Next Steps -- The next calls are on: February 20 2020 (Thursday) This call will be for 90 minutes. February 24 2020 (Monday) (tentative not confirmed) This call will be for 60 minutes. Calls are anchored on US time. (8am Pacific) Please check the calendar invites for dial in details. 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 username=posix password=2115756# 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
