[1003.1(2016)/Issue7+TC2 0001309]: Clarity needed for initial value of $? at start of compound-list compound statements
The following issue has been SUBMITTED.
==
http://austingroupbugs.net/view.php?id=1309
==
Reported By:kre
Assigned To:
==
Project:1003.1(2016)/Issue7+TC2
Issue ID: 1309
Category: Shell and Utilities
Type: Enhancement Request
Severity: Objection
Priority: normal
Status: New
Name: Robert Elz
Organization:
User Reference:
Section:2.9.4
Page Number:2371-4
Line Number:75726-31
Interp Status: ---
Final Accepted Text:
==
Date Submitted: 2019-12-19 02:26 UTC
Last Modified: 2019-12-19 02:26 UTC
==
Summary:Clarity needed for initial value of $? at start of
compound-list compound statements
Description:
Currently, nothing says what the "previous command" is precisely when
beginning execution of one of the lists in the body of a compound
statement.
This is (fortunately) not controversial, as best I can tell, all shells do
it the same way, so all that is needed is to be explicit in the standard
as
to what that way is.
That is, in
(exit $B); if X=$?; echo X=$X; (exit $X); then Y=$?; echo Y=$Y; (exit
$Y);
else Z=$?; echo Z=$Z; (exit $Z); fi; A=$?; echo A=$A; (exit $A)
what values are assigned to X, Y, and Z (the value for A is already
defined)
The reason this might seem tricky, is that when assigning A, the value of
X is completely ignored. Some might reason from that, that the value of
X should be ignored for the purposes of Y and Z as well.
Similar examples can be designed for all of the compound statements.
[Aside: do not treat this example literally - it is obviously designed to
pass through the exit code without changing it ... for more realistic
purposes
we should assume that the "echo $Q; (exit $Q)" part (where Q is X Y or Z)
can be any arbitrary sh statements, producing any arbitrary results.]
My intuition would say (and all the tests I have done confirm) that the
"previous" status for X is always the previous command exit status (from
before the compound statement, or 0 if there was none) and that for Y and
Z
it is the result from the condition evaluation (if there was one) or for
the compounds that have no condition ('{' '(' 'for' 'case') the initial
exit status for the body is that from before the compound statement.
The two cases where it is possible to observe this in a meaningful way are
in the else clause list of an if statement, and the body of an until
That is, if we have
(exit 3) ; if (exit 7); then : ; else echo $?; fi
then what will be printed will be 7, and definitely not 3 or 0.
I believe that this should be made explicit in the standard.
Desired Action:
After line 75731 (the end of the 2.9.4 intro test, just before 2.9.4.1
add a new paragraph something like:
When commencing execution of a compound-list as part of a compound
command,
the "last command executed" for the purposes of determining the value of
the
special parameter '?' and the default value for the exit and resturn
special
built-in commands, shall be the status of the last command executed before
the
compound command in the case of the first compound-list executed, and the
result
of the previous compound-list executed as part of executing the compound
command in the case where more that one compound-list is executed, or
where
compound-lists are repeatedly executed. During execution of a
compound-list
the exit status is updated to reflect the results of each command
executed,
as is defined for each such command.
The exit status after the compound command has completed is as specified
below for each specific compound command.
==
Issue History
Date ModifiedUsername FieldChange
==
2019-12-19 02:26 kreNew Issue
2019-12-19 02:26 kreName => Robert Elz
2019-12-19 02:26 kreSection => 2.9.4
2019-12-19 02:26 krePage Number => 2371-4
2019-12-19 02:26 kreLine Number => 75726-31
==
Re: system() and pthread_atfork()
Hello. Karstens, Nate wrote in : |The current definition of system() does not define if the pthread_atfork() \ ... No head to think about that but.. ... |a new process. The parent process attempts to bind a new socket to \ |a port that it had previously bound to (before the IP address change), \ |only to fail because the child process continues to hold a socket bound \ |to that port. | |The close-on-exec flag (SOCK_CLOEXEC / FD_CLOEXEC) seems like it would \ |help here, but does not because the child process has not called exec() \ |yet. Couldn't that be addressed by SO_REUSEADDR? ... |Any feedback would be much appreciated. ..following that star :) --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
[1003.1(2016)/Issue7+TC2 0001308]: Error in table of addresses for address 7,+
The following issue has been SUBMITTED. == http://austingroupbugs.net/view.php?id=1308 == Reported By:Antonio Diaz Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1308 Category: Shell and Utilities Type: Error Severity: Editorial Priority: normal Status: New Name: Antonio Diaz Diaz Organization: GNU Project User Reference: Section:ed Page Number:0 Line Number:0 Interp Status: --- Final Accepted Text: == Date Submitted: 2019-12-18 23:28 UTC Last Modified: 2019-12-18 23:28 UTC == Summary:Error in table of addresses for address 7,+ Description: In the table of addresses at the end of the ed page we can see (among other rows): Address Addr1 Addr2 7,+ 7 8 7;+ 7 8 But the first row above should be equivalent to '7,.+', not to '7,8'. See http://lists.gnu.org/archive/html/bug-ed/2018-10/msg5.html for an explanation and some tests. Desired Action: Change the Addr2 column for address '7,+' to '.+' like this: Address Addr1 Addr2 7,+ 7 .+ == Issue History Date ModifiedUsername FieldChange == 2019-12-18 23:28 Antonio Diaz New Issue 2019-12-18 23:28 Antonio Diaz Name => Antonio Diaz Diaz 2019-12-18 23:28 Antonio Diaz Organization => GNU Project 2019-12-18 23:28 Antonio Diaz Section => ed 2019-12-18 23:28 Antonio Diaz Page Number => 0 2019-12-18 23:28 Antonio Diaz Line Number => 0 ==
system() and pthread_atfork()
Greetings, The current definition of system() does not define if the pthread_atfork() handlers are called. We ran into a scenario where this caused a problem and wanted to share it with the mailing list to better understand why those handlers are not required and get some advice on how best to proceed. We are running Linux on an embedded system. The platform can change the IP address either according to a proprietary negotiation scheme or a manual setting. The application uses netlink to listen for IP address changes; when this occurs the application closes all of its sockets and re-opens them using the new address. A problem can occur if the application is simultaneously fork/exec-ing a new process. The parent process attempts to bind a new socket to a port that it had previously bound to (before the IP address change), only to fail because the child process continues to hold a socket bound to that port. The close-on-exec flag (SOCK_CLOEXEC / FD_CLOEXEC) seems like it would help here, but does not because the child process has not called exec() yet. Our solution was to use a pthread_atfork() handler to lock a mutex and wait for the child process to close all of its sockets (as signaled through an eventfd) before the parent attempts to create them again. This doesn't work if the application uses system() anywhere (the version of glibc we use does not invoke pthread_atfork() handlers). We changed all calls to system() to instead use fork()/exec(), but are still concerned about third-party libraries. This seems like a scenario where you would want system() to require pthread_atfork() handlers to be called. Aside from that, it seems somewhat contradictory that system() "shall behave as if a child process were created using fork()..." but it is undefined if pthread_atfork() handlers are called. Any feedback would be much appreciated. Thanks, Nate CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you.
[1003.1(2016)/Issue7+TC2 0001290]: arpa/inet.h - origin of socklen_t is unclear
The following issue has been set as RELATED TO issue 606. == http://austingroupbugs.net/view.php?id=1290 == Reported By:joelsherrill Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1290 Category: Base Definitions and Headers Type: Clarification Requested Severity: Editorial Priority: normal Status: Interpretation Required Name: Joel Sherrill Organization: RTEMS.org User Reference: Section:arpa/inet.h Page Number:NA - used web Line Number:NA - used web Interp Status: Proposed Final Accepted Text:See http://austingroupbugs.net/view.php?id=1290#c4615 == Date Submitted: 2019-09-27 19:20 UTC Last Modified: 2019-12-18 19:39 UTC == Summary:arpa/inet.h - origin of socklen_t is unclear == Relationships ID Summary -- related to 606should be required ... related to 0001289 netdb.h - in_port_t and in_addr_t do no... == Issue History Date ModifiedUsername FieldChange == 2019-09-27 19:20 joelsherrill New Issue 2019-09-27 19:20 joelsherrill Name => Joel Sherrill 2019-09-27 19:20 joelsherrill Organization => RTEMS.org 2019-09-27 19:20 joelsherrill Section => arpa/inet.h 2019-09-27 19:20 joelsherrill Page Number => NA - used web 2019-09-27 19:20 joelsherrill Line Number => NA - used web 2019-10-07 15:39 eblake Relationship added related to 0001289 2019-10-07 15:46 nick Note Added: 0004615 2019-10-07 15:47 nick Interp Status => Pending 2019-10-07 15:47 nick Final Accepted Text => See http://austingroupbugs.net/view.php?id=1290#c4615 2019-10-07 15:47 nick Status New => Interpretation Required 2019-10-07 15:47 nick Resolution Open => Accepted As Marked 2019-10-07 15:48 nick Tag Attached: tc3-2008 2019-12-12 17:32 agadminInterp StatusPending => Proposed 2019-12-12 17:32 agadminNote Added: 0004685 2019-12-18 18:59 denniswNote Added: 0004690 2019-12-18 19:39 Don Cragun Relationship added related to 606 ==
[1003.1(2008)/Issue 7 0000606]: should be required to define socklen_t
The following issue has been set as RELATED TO issue 0001290. == http://austingroupbugs.net/view.php?id=606 == Reported By:philip-guenther Assigned To:ajosey == Project:1003.1(2008)/Issue 7 Issue ID: 606 Category: Base Definitions and Headers Type: Omission Severity: Comment Priority: normal Status: Resolved Name: Philip Guenther Organization: OpenBSD User Reference: Section:13 Header, Page Number:222 Line Number:7271 Interp Status: --- Final Accepted Text:See http://austingroupbugs.net/view.php?id=606#c1368 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2012-09-12 23:47 UTC Last Modified: 2012-09-19 16:01 UTC == Summary: should be required to define socklen_t == Relationships ID Summary -- related to 0001290 arpa/inet.h - origin of socklen_t is un... == Issue History Date ModifiedUsername FieldChange == 2012-09-12 23:47 philip-guentherNew Issue 2012-09-12 23:47 philip-guentherStatus New => Under Review 2012-09-12 23:47 philip-guentherAssigned To => ajosey 2012-09-12 23:47 philip-guentherName => Philip Guenther 2012-09-12 23:47 philip-guentherOrganization => OpenBSD 2012-09-12 23:47 philip-guentherSection => 13 Header, 2012-09-12 23:47 philip-guentherPage Number => 222 2012-09-12 23:47 philip-guentherLine Number => 7271 2012-09-19 16:01 Don Cragun Interp Status => --- 2012-09-19 16:01 Don Cragun Final Accepted Text => See http://austingroupbugs.net/view.php?id=606#c1368 2012-09-19 16:01 Don Cragun Note Added: 0001368 2012-09-19 16:01 Don Cragun Status Under Review => Resolved 2012-09-19 16:01 Don Cragun Resolution Open => Accepted As Marked 2012-09-19 16:01 Don Cragun Tag Attached: issue8 2019-12-18 19:39 Don Cragun Relationship added related to 0001290 ==
[1003.1(2016)/Issue7+TC2 0001290]: arpa/inet.h - origin of socklen_t is unclear
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=1290 == Reported By:joelsherrill Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1290 Category: Base Definitions and Headers Type: Clarification Requested Severity: Editorial Priority: normal Status: Interpretation Required Name: Joel Sherrill Organization: RTEMS.org User Reference: Section:arpa/inet.h Page Number:NA - used web Line Number:NA - used web Interp Status: Proposed Final Accepted Text:See http://austingroupbugs.net/view.php?id=1290#c4615 == Date Submitted: 2019-09-27 19:20 UTC Last Modified: 2019-12-18 18:59 UTC == Summary:arpa/inet.h - origin of socklen_t is unclear == Relationships ID Summary -- related to 0001289 netdb.h - in_port_t and in_addr_t do no... == -- (0004690) dennisw (reporter) - 2019-12-18 18:59 http://austingroupbugs.net/view.php?id=1290#c4690 -- I just noticed that the same issue was already reported in http://austingroupbugs.net/view.php?id=606. However that bug was tagged for issue8 which is why it was not fixed in a TC. I think http://austingroupbugs.net/view.php?id=606 should be closed as a duplicate of this bug. Issue History Date ModifiedUsername FieldChange == 2019-09-27 19:20 joelsherrill New Issue 2019-09-27 19:20 joelsherrill Name => Joel Sherrill 2019-09-27 19:20 joelsherrill Organization => RTEMS.org 2019-09-27 19:20 joelsherrill Section => arpa/inet.h 2019-09-27 19:20 joelsherrill Page Number => NA - used web 2019-09-27 19:20 joelsherrill Line Number => NA - used web 2019-10-07 15:39 eblake Relationship added related to 0001289 2019-10-07 15:46 nick Note Added: 0004615 2019-10-07 15:47 nick Interp Status => Pending 2019-10-07 15:47 nick Final Accepted Text => See http://austingroupbugs.net/view.php?id=1290#c4615 2019-10-07 15:47 nick Status New => Interpretation Required 2019-10-07 15:47 nick Resolution Open => Accepted As Marked 2019-10-07 15:48 nick Tag Attached: tc3-2008 2019-12-12 17:32 agadminInterp StatusPending => Proposed 2019-12-12 17:32 agadminNote Added: 0004685 2019-12-18 18:59 denniswNote Added: 0004690 ==
[1003.1(2016)/Issue7+TC2 0001307]: am_pm value in locales that do not distinguish between am and pm (again)
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=1307 == Reported By:geoffclare Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1307 Category: Base Definitions and Headers Type: Clarification Requested Severity: Comment Priority: normal Status: New Name: Geoff Clare Organization: The Open Group User Reference: Section:7.3.5.1 LC_TIME Locale Definition Page Number:160 Line Number:5085 Interp Status: --- Final Accepted Text: == Date Submitted: 2019-12-18 15:35 UTC Last Modified: 2019-12-18 18:54 UTC == Summary:am_pm value in locales that do not distinguish between am and pm (again) == Relationships ID Summary -- related to 081 am_pm value in locales that do not dist... == -- (0004689) shware_systems (reporter) - 2019-12-18 18:54 http://austingroupbugs.net/view.php?id=1307#c4689 -- I'd be more in favor of requiring, at a minimum, ";" be the default value for am_pm, so whatever processing using that sees zero length strings as the associated values, i.e. the search for a ';' will always succeed. This reduces code size as no tests for ';' not found are mandated. A case can be made too that since AM and PM are abbreviations of Latin, this is invariant across all locales also for a Gregorian calendar, with the am_pm value used only to specify if lower, mixed, or upper case versions of those are preferred; there should never be zero length values for either. Even where a country prefers to use a national languge translation for "before noon" or "after noon", an appropriate abbreviation could be represented, e.g. "VM;AM" representing "vor mittag" and "ab mittag" in a german locale. As such %r is valid for all locales too, never unsupported, and a default string of "%I:%M%p" for t_fmt_ampm is appropriate. It is a more a defining specification of locale data does not say an alternate format is required. If a locale definition says always use 24 hour values, or always provide seconds as in the POSIX locale, it's then on that locale data to specify a string like "%H%M" or "%I:%M:%S %p" (as strftime() does), not leave it empty. Even though adding the string to values of a 24 hour usage is nominally superfluous, it still accents the value is a morning or evening time so isn't entirely redundant. I wouldn't preclude values like "%H:%M %p" therefore. Issue History Date ModifiedUsername FieldChange == 2019-12-18 15:35 geoffclare New Issue 2019-12-18 15:35 geoffclare Name => Geoff Clare 2019-12-18 15:35 geoffclare Organization => The Open Group 2019-12-18 15:35 geoffclare Section => 7.3.5.1 LC_TIME Locale Definition 2019-12-18 15:35 geoffclare Page Number => 160 2019-12-18 15:35 geoffclare Line Number => 5085 2019-12-18 15:35 geoffclare Interp Status => --- 2019-12-18 15:36 geoffclare Relationship added related to 081 2019-12-18 15:38 geoffclare Note Added: 0004688 2019-12-18 18:54 shware_systems Note Added: 0004689 ==
[1003.1(2016)/Issue7+TC2 0001307]: am_pm value in locales that do not distinguish between am and pm (again)
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=1307 == Reported By:geoffclare Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1307 Category: Base Definitions and Headers Type: Clarification Requested Severity: Comment Priority: normal Status: New Name: Geoff Clare Organization: The Open Group User Reference: Section:7.3.5.1 LC_TIME Locale Definition Page Number:160 Line Number:5085 Interp Status: --- Final Accepted Text: == Date Submitted: 2019-12-18 15:35 UTC Last Modified: 2019-12-18 15:38 UTC == Summary:am_pm value in locales that do not distinguish between am and pm (again) == Relationships ID Summary -- related to 081 am_pm value in locales that do not dist... == -- (0004688) geoffclare (manager) - 2019-12-18 15:38 http://austingroupbugs.net/view.php?id=1307#c4688 -- Since bug http://austingroupbugs.net/view.php?id=81 does not contain details of a change to be applied in Issue 8, I have removed the issue8 tag from it. It still stands as a formal Interpretation response to the issue that was raised in that bug. Issue History Date ModifiedUsername FieldChange == 2019-12-18 15:35 geoffclare New Issue 2019-12-18 15:35 geoffclare Name => Geoff Clare 2019-12-18 15:35 geoffclare Organization => The Open Group 2019-12-18 15:35 geoffclare Section => 7.3.5.1 LC_TIME Locale Definition 2019-12-18 15:35 geoffclare Page Number => 160 2019-12-18 15:35 geoffclare Line Number => 5085 2019-12-18 15:35 geoffclare Interp Status => --- 2019-12-18 15:36 geoffclare Relationship added related to 081 2019-12-18 15:38 geoffclare Note Added: 0004688 ==
[1003.1(2016)/Issue7+TC2 0001307]: am_pm value in locales that do not distinguish between am and pm (again)
The following issue has been set as RELATED TO issue 081. == http://austingroupbugs.net/view.php?id=1307 == Reported By:geoffclare Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1307 Category: Base Definitions and Headers Type: Clarification Requested Severity: Comment Priority: normal Status: New Name: Geoff Clare Organization: The Open Group User Reference: Section:7.3.5.1 LC_TIME Locale Definition Page Number:160 Line Number:5085 Interp Status: --- Final Accepted Text: == Date Submitted: 2019-12-18 15:35 UTC Last Modified: 2019-12-18 15:36 UTC == Summary:am_pm value in locales that do not distinguish between am and pm (again) == Relationships ID Summary -- related to 081 am_pm value in locales that do not dist... == Issue History Date ModifiedUsername FieldChange == 2019-12-18 15:35 geoffclare New Issue 2019-12-18 15:35 geoffclare Name => Geoff Clare 2019-12-18 15:35 geoffclare Organization => The Open Group 2019-12-18 15:35 geoffclare Section => 7.3.5.1 LC_TIME Locale Definition 2019-12-18 15:35 geoffclare Page Number => 160 2019-12-18 15:35 geoffclare Line Number => 5085 2019-12-18 15:35 geoffclare Interp Status => --- 2019-12-18 15:36 geoffclare Relationship added related to 081 ==
[1003.1(2008)/Issue 7 0000081]: am_pm value in locales that do not distinguish between am and pm
The following issue has been set as RELATED TO issue 0001307. == http://austingroupbugs.net/view.php?id=81 == Reported By:geoffclare Assigned To:ajosey == Project:1003.1(2008)/Issue 7 Issue ID: 81 Category: Base Definitions and Headers Type: Clarification Requested Severity: Objection Priority: normal Status: Interpretation Required Name: Petr Baudis Organization: SUSE Labs / Novell User Reference: Section:LC_TIME Page Number:159 Line Number:4921 Interp Status: Approved Final Accepted Text:http://austingroupbugs.net/view.php?id=81#c133 == Date Submitted: 2009-06-29 09:40 UTC Last Modified: 2009-10-09 16:57 UTC == Summary:am_pm value in locales that do not distinguish between am and pm == Relationships ID Summary -- related to 0001307 am_pm value in locales that do not dist... == Issue History Date ModifiedUsername FieldChange == 2009-06-29 09:40 geoffclare New Issue 2009-06-29 09:40 geoffclare Status New => Under Review 2009-06-29 09:40 geoffclare Assigned To => ajosey 2009-06-29 09:40 geoffclare Name => Geoff Clare 2009-06-29 09:40 geoffclare Organization => The Open Group 2009-06-29 09:40 geoffclare Section => LC_TIME 2009-06-29 09:40 geoffclare Page Number => 0 2009-06-29 09:40 geoffclare Line Number => 0 2009-06-29 09:41 geoffclare Tag Attached: real bug in aardvark 2009-06-29 09:44 geoffclare Note Added: 133 2009-06-29 09:44 geoffclare Status Under Review => Interpretation Required 2009-06-29 09:44 geoffclare Resolution Open => Accepted As Marked 2009-06-29 09:47 geoffclare Final Accepted Text => Note: 133 2009-06-29 09:53 geoffclare Final Accepted Text Note: 133 => http://austingroupbugs.net/view.php?id=81#c133 2009-06-29 09:54 geoffclare Tag Attached: needs page and line numbers 2009-07-02 18:02 Don Cragun Name Geoff Clare => Petr Baudis 2009-07-02 18:02 Don Cragun Organization The Open Group => SUSE Labs / Novell 2009-07-02 18:02 Don Cragun Page Number 0 => 159 2009-07-02 18:02 Don Cragun Line Number 0 => 4921 2009-07-02 18:02 Don Cragun Tag Detached: needs page and line numbers 2009-08-06 15:51 Don Cragun Tag Detached: real bug in aardvark 2009-08-06 15:52 ajosey Note Added: 179 2009-08-11 16:34 Don Cragun Interp Status => Pending 2009-09-17 15:41 nick Interp StatusPending => Proposed 2009-10-09 16:56 ajosey Note Edited: 133 2009-10-09 16:56 ajosey Note Deleted: 179 2009-10-09 16:57 ajosey Interp StatusProposed => Approved 2010-09-20 09:22 geoffclare Tag Attached: issue8 2019-12-18 15:36 geoffclare Relationship added related to 0001307 ==
[1003.1(2016)/Issue7+TC2 0001307]: am_pm value in locales that do not distinguish between am and pm (again)
The following issue has been SUBMITTED. == http://austingroupbugs.net/view.php?id=1307 == Reported By:geoffclare Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1307 Category: Base Definitions and Headers Type: Clarification Requested Severity: Comment Priority: normal Status: New Name: Geoff Clare Organization: The Open Group User Reference: Section:7.3.5.1 LC_TIME Locale Definition Page Number:160 Line Number:5085 Interp Status: --- Final Accepted Text: == Date Submitted: 2019-12-18 15:35 UTC Last Modified: 2019-12-18 15:35 UTC == Summary:am_pm value in locales that do not distinguish between am and pm (again) Description: The Notes to the Editor in the Interpretation response in bug http://austingroupbugs.net/view.php?id=81 say:Consider as a revision for a future edition, requiring that am_pm be empty if t_fmt_ampm is an empty string This would also need to be noted in the APPLICATION USAGE of related utilities/functions. This is an instruction to the working group to consider making a change, not an instruction to the editor to make a change. I am submitting this bug so that we can duly consider precisely what, if any, changes to make. Desired Action: Change:The operand shall consist of two strings, separated by a , each surrounded by double-quotes. The first string shall represent the ante-meridiem designation, the last string the post-meridiem designation.to:If the t_fmt_ampm string is not empty, the am_pm operand shall consist of two strings, separated by a , each surrounded by double-quotes; the first string shall represent the ante-meridiem designation, the last string the post-meridiem designation. If the t_fmt_ampm string is empty, the am_pm operand shall be an empty string. If this change is agreed, then work out what other changes are needed. == Issue History Date ModifiedUsername FieldChange == 2019-12-18 15:35 geoffclare New Issue 2019-12-18 15:35 geoffclare Name => Geoff Clare 2019-12-18 15:35 geoffclare Organization => The Open Group 2019-12-18 15:35 geoffclare Section => 7.3.5.1 LC_TIME Locale Definition 2019-12-18 15:35 geoffclare Page Number => 160 2019-12-18 15:35 geoffclare Line Number => 5085 2019-12-18 15:35 geoffclare Interp Status => --- ==
[1003.1(2008)/Issue 7 0000051]: sh exit status not clear for built-in terminated by a signal
The following issue is UNDER REVIEW. == http://austingroupbugs.net/view.php?id=51 == Reported By:geoffclare Assigned To:ajosey == Project:1003.1(2008)/Issue 7 Issue ID: 51 Category: Shell and Utilities Type: Clarification Requested Severity: Comment Priority: normal Status: Under Review Name: Geoff Clare Organization: The Open Group User Reference: Section:sh Page Number:3175 Line Number:105726 Interp Status: --- Final Accepted Text:http://austingroupbugs.net/view.php?id=51#c90 == Date Submitted: 2009-06-25 13:04 UTC Last Modified: 2019-12-18 15:02 UTC == Summary:sh exit status not clear for built-in terminated by a signal == -- (0004687) geoffclare (manager) - 2019-12-18 15:02 http://austingroupbugs.net/view.php?id=51#c4687 -- Reopening because the instructions in the Notes to the Editor in http://austingroupbugs.net/view.php?id=51#c90 regarding the getrlimit() and setrlimit() functions are unclear. Specifically, should all of the RLIMIT_* constants in become mandatory, or only RLIMIT_CORE? The stated rationale for moving these functions to Base only requires RLIMIT_CORE to be mandated; the others could remain XSI. If the other constants are mandated, then this will have wide ranging effects elsewhere in the standard, e.g. SIGXCPU and SIGXFSZ in , and all text relating to the file size limit that is currently shaded XSI will need to have the shading removed. Issue History Date ModifiedUsername FieldChange == 2009-06-25 13:04 Don Cragun New Issue 2009-06-25 13:04 Don Cragun Status New => Under Review 2009-06-25 13:04 Don Cragun Assigned To => ajosey 2009-06-25 13:04 Don Cragun Name => Geoff Clare 2009-06-25 13:04 Don Cragun Organization => The Open Group 2009-06-25 13:04 Don Cragun Section => sh 2009-06-25 13:04 Don Cragun Page Number => 3175 2009-06-25 13:04 Don Cragun Line Number => 105726 2009-06-25 13:07 Don Cragun Note Added: 089 2009-06-25 13:11 Don Cragun Note Added: 090 2009-06-25 13:11 Don Cragun Reporter Don Cragun => geoffclare 2009-06-25 13:11 Don Cragun Status Under Review => Interpretation Required 2009-06-25 13:11 Don Cragun Resolution Open => Accepted As Marked 2009-06-25 16:38 Don Cragun Tag Attached: real bug in aardvark 2009-06-26 06:29 Don Cragun Note Edited: 089 2009-06-26 08:49 Don Cragun Final Accepted Text => Note 090 2009-06-26 09:31 Don Cragun Final Accepted Text Note 090 => http://austingroupbugs.net/view.php?id=51#c90 2009-07-30 16:09 Don Cragun Tag Detached: real bug in aardvark 2009-08-11 16:22 Don Cragun Interp Status => Pending 2009-09-17 15:41 nick Interp StatusPending => Proposed 2009-10-09 16:01 ajosey Note Edited: 090 2009-10-09 16:01 ajosey Interp StatusProposed => Approved 2009-11-02 22:33 user83 Note Added: 275 2009-11-02 22:33 user83 Note Added: 276 2009-11-02 23:10 user83 Note Deleted: 275 2009-11-02 23:10 user83 Note Deleted: 276 2010-09-20 09:03 geoffclare Tag Attached: issue8 2019-12-18 15:02 geoffclare Interp StatusApproved => --- 2019-12-18 15:02 geoffclare Note Added: 0004687 2019-12-18 15:02 geoffclare Status Interpretation Required => Under Review 2019-12-18 15:02 geoffclare Resolution Accepted As Marked => Reopened ==
