[1003.1(2013)/Issue7+TC1 0001007]: iconv function not allowed to fail to convert valid sequences

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1007 
== 
Reported By:sebor
Assigned To:ajosey
== 
Project:1003.1(2013)/Issue7+TC1
Issue ID:   1007
Category:   Base Definitions and Headers
Type:   Omission
Severity:   Objection
Priority:   normal
Status: Under Review
Name:   Martin Sebor 
Organization:
User Reference:  
Section:iconv function 
Page Number:1109-1110 
Line Number: 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2015-11-16 20:37 UTC
Last Modified:  2016-08-10 14:58 UTC
== 
Summary:iconv function not allowed to fail to convert valid
sequences
== 

-- 
 (0003330) geoffclare (manager) - 2016-08-10 14:58
 http://austingroupbugs.net/view.php?id=1007#c3330 
-- 
These are the changes I believe are needed to add the common subset of
Solaris 11 and glibc iconv_open() extensions (//IGNORE and //TRANSLIT),
plus Solaris's //NON_IDENTICAL_DISCARD.  This is intended as a starting
point to which further changes can be added if the group so decides.

On page 1109 line 37310 section iconv()

Change:If a sequence of input bytes does not form a valid
character in the specified codeset, conversion shall stop after the
previous successfully converted character.to:If a
sequence of input bytes does not form a valid character or shift sequence
in the input codeset:If the //IGNORE indicator suffix was specified
when the conversion descriptor cd was opened and the byte sequence
is immediately followed by a valid character or shift sequence, the
sequence of bytes shall be discarded and conversion shall continue from the
immediately following valid character or shift sequence.  This shall not be
treated as an error.If the //IGNORE indicator suffix was not
specified when the conversion descriptor cd was opened, conversion
shall stop after the previous successfully converted character or shift
sequence.

On page 1109 line 37323 section iconv()

Change:If iconv() encounters a character in the input
buffer that is valid, but for which an identical character does not exist
in the target codeset, iconv() shall perform an
implementation-defined conversion on this
character.to:If iconv() encounters a
character in the input buffer that is valid, but for which an identical
character does not exist in the output codeset:If either the
//IGNORE or the //NON_IDENTICAL_DISCARD indicator suffix was specified when
the conversion descriptor cd was opened, the character shall be
discarded but shall still be counted in the return value of the
iconv() call.If the //TRANSLIT indicator suffix was
specified when the conversion descriptor cd was opened, an
implementation-defined transliteration shall be performed, if possible, to
convert the character into one or more characters of the output codeset
that best resemble the input character.  The character shall be counted as
one character in the return value of the iconv() call, regardless of
the number of output characters.If no indicator suffix was
specified when the conversion descriptor cd was opened, or the
//TRANSLIT indicator suffix was specified but no transliteration of the
character is possible, iconv() shall perform an
implementation-defined conversion on the character and it shall be counted
in the return value of the iconv() call.

On page 1109 line 37327 section iconv()

Change:The iconv() function shall update the variables
pointed to by the arguments to reflect the extent of the conversion and
return the number of non-identical conversions performed. If the entire
string in the input buffer is converted, the value pointed to by
inbytesleft shall be 0.to:The
iconv() function shall update the variables pointed to by the
arguments to reflect the extent of the conversion and shall return the
number of input characters that could not be converted to an identical
output character.  If the entire string in the input buffer is converted,
except for any byte sequences discarded as a result of the //IGNORE
indicator suffix, the value pointed to by inbytesleft shall be
0.
On page 1110 line 37364 section iconv()

Add a new paragraph to APPLICATION USAGE:When the //IGNORE
indicator suffix was 

[1003.1(2013)/Issue7+TC1 0001007]: iconv function not allowed to fail to convert valid sequences

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1007 
== 
Reported By:sebor
Assigned To:ajosey
== 
Project:1003.1(2013)/Issue7+TC1
Issue ID:   1007
Category:   Base Definitions and Headers
Type:   Omission
Severity:   Objection
Priority:   normal
Status: Under Review
Name:   Martin Sebor 
Organization:
User Reference:  
Section:iconv function 
Page Number:1109-1110 
Line Number: 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2015-11-16 20:37 UTC
Last Modified:  2016-08-11 14:36 UTC
== 
Summary:iconv function not allowed to fail to convert valid
sequences
== 

-- 
 (0003334) shware_systems (reporter) - 2016-08-11 14:36
 http://austingroupbugs.net/view.php?id=1007#c3334 
-- 
The following, as an element of //IGNORE, I feel should be included also,
and should be simple for glibc to add. An application may not care about
illegal sequences, but may want to pop up a prompt for how to transliterate
non-identical sequences so would need to get notified when they occur.
Having just //IGNORE doesn't permit this usage.

//ILLEGAL_DISCARD
When specified, during subsequent iconv() code conversion, a sequence of
illegal input bytes that does not form a valid character in the codeset
specified by the fromcode argument is silently discarded as if there are no
such illegal bytes in the input buffer and the conversion continues. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-11-16 20:37 sebor  New Issue
2015-11-16 20:37 sebor  Status   New => Under Review 
2015-11-16 20:37 sebor  Assigned To   => ajosey  
2015-11-16 20:37 sebor  Name  => Martin Sebor
2015-11-16 20:37 sebor  Section   => iconv function  
2015-11-16 20:37 sebor  Page Number   => 1109-1110   
2015-11-16 22:38 steffenNote Added: 0002965  
2015-11-17 17:02 geoffclare Project  1003.1(2008)/Issue 7 =>
1003.1(2013)/Issue7+TC1
2015-11-17 21:39 shware_systems Note Added: 0002968  
2015-11-17 21:41 shware_systems Note Edited: 0002968 
2015-11-18 00:03 sebor  Note Added: 0002969  
2016-02-07 11:07 milanbvNote Added: 0003068  
2016-07-28 23:14 shware_systems Note Added: 0003311  
2016-07-28 23:14 shware_systems Note Added: 0003312  
2016-07-29 09:13 geoffclare Note Added: 0003313  
2016-07-29 09:35 shware_systems Note Deleted: 0003312
2016-07-30 13:56 steffenNote Added: 0003314  
2016-08-02 16:09 geoffclare Note Added: 0003323  
2016-08-03 11:45 steffenNote Added: 0003324  
2016-08-04 15:48 Don Cragun Note Added: 0003325  
2016-08-04 20:57 eblake Note Added: 0003327  
2016-08-10 14:58 geoffclare Note Added: 0003330  
2016-08-10 15:02 geoffclare Note Edited: 0003330 
2016-08-11 14:36 shware_systems Note Added: 0003334  
==

[1003.1(2013)/Issue7+TC1 0001008]: 1. clarify iconv(3) reset usage; 2. truly support Unicode character input

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1008 
== 
Reported By:steffen
Assigned To:ajosey
== 
Project:1003.1(2013)/Issue7+TC1
Issue ID:   1008
Category:   System Interfaces
Type:   Clarification Requested
Severity:   Objection
Priority:   normal
Status: Resolved
Name:   steffen 
Organization:
User Reference:  
Section:Vol.2, System Interfaces, iconv 
Page Number:1109 
Line Number:37302 ff. 
Interp Status:  --- 
Final Accepted Text:http://austingroupbugs.net/view.php?id=1008#c3326 
Resolution: Accepted As Marked
Fixed in Version:   
== 
Date Submitted: 2015-11-16 22:24 UTC
Last Modified:  2016-08-11 15:23 UTC
== 
Summary:1. clarify iconv(3) reset usage; 2. truly support
Unicode character input
== 

-- 
 (0003335) geoffclare (manager) - 2016-08-11 15:23
 http://austingroupbugs.net/view.php?id=1008#c3335 
-- 
http://austingroupbugs.net/view.php?id=1008#c3326 was edited during the
2016-08-11 teleconference to add the
last sentence. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-11-16 22:24 steffenNew Issue
2015-11-16 22:24 steffenStatus   New => Under Review 
2015-11-16 22:24 steffenAssigned To   => ajosey  
2015-11-16 22:24 steffenName  => steffen 
2015-11-16 22:24 steffenSection   => Vol.2, System
Interfaces, iconv
2015-11-16 22:24 steffenPage Number   => 1109
2015-11-16 22:24 steffenLine Number   => 37302 ff.   
2015-11-17 16:59 steffenNote Added: 0002966  
2015-11-17 17:03 geoffclare Project  1003.1(2008)/Issue 7 =>
1003.1(2013)/Issue7+TC1
2016-08-04 16:35 geoffclare Note Added: 0003326  
2016-08-04 16:35 geoffclare Interp Status => --- 
2016-08-04 16:35 geoffclare Final Accepted Text   =>
http://austingroupbugs.net/view.php?id=1008#c3326
2016-08-04 16:35 geoffclare Status   Under Review =>
Resolved
2016-08-04 16:35 geoffclare Resolution   Open => Accepted As
Marked
2016-08-04 16:36 geoffclare Tag Attached: tc3-2008   
2016-08-11 15:22 geoffclare Note Edited: 0003326 
2016-08-11 15:23 geoffclare Note Added: 0003335  
==

[1003.1(2013)/Issue7+TC1 0001006]: PS1 should be subject to command substitution and arithmetic expansion

[Austin Group Bug Tracker]

The following issue has been set as RELATED TO issue 0001038. 
== 
http://austingroupbugs.net/view.php?id=1006 
== 
Reported By:rhansen
Assigned To:
== 
Project:1003.1(2013)/Issue7+TC1
Issue ID:   1006
Category:   Shell and Utilities
Type:   Omission
Severity:   Editorial
Priority:   normal
Status: Interpretation Required
Name:   Richard Hansen 
Organization:   BBN 
User Reference:  
Section:2.5.3 PS1 
Page Number:2326 
Line Number:73833 
Interp Status:  Pending 
Final Accepted Text:http://austingroupbugs.net/view.php?id=1006#c3310 
== 
Date Submitted: 2015-11-13 08:23 UTC
Last Modified:  2016-08-11 15:29 UTC
== 
Summary:PS1 should be subject to command substitution and
arithmetic expansion
==
Relationships   ID  Summary
--
related to  0001038 Specification relies upon unspecified b...
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-11-13 08:23 rhansenNew Issue
2015-11-13 08:23 rhansenName  => Richard Hansen  
2015-11-13 08:23 rhansenOrganization  => BBN 
2015-11-13 08:23 rhansenSection   => 2.5.3 PS1   
2015-11-13 08:23 rhansenPage Number   => 2326
2015-11-13 08:23 rhansenLine Number   => 73833   
2015-11-13 08:23 rhansenInterp Status => --- 
2015-11-13 10:34 joerg  Note Added: 0002906  
2015-11-13 13:51 kreNote Added: 0002907  
2015-11-13 15:44 random832  Note Added: 0002909  
2015-11-13 16:04 random832  Note Edited: 0002909 
2015-11-13 16:11 geoffclare Note Added: 0002911  
2015-11-13 16:33 shware_systems Note Added: 0002913  
2015-11-13 16:36 random832  Note Added: 0002914  
2015-11-13 16:40 random832  Note Edited: 0002914 
2015-11-13 16:47 random832  Note Edited: 0002914 
2015-11-13 16:49 random832  Note Edited: 0002914 
2015-11-13 16:49 random832  Note Edited: 0002914 
2015-11-13 18:21 kreNote Added: 0002918  
2015-11-13 18:29 kreNote Added: 0002919  
2015-11-13 18:31 random832  Note Added: 0002920  
2015-11-14 01:39 rhansenNote Added: 0002932  
2015-11-14 01:40 rhansenNote Added: 0002933  
2015-11-14 01:41 rhansenNote Edited: 0002933 
2015-11-14 01:44 rhansenNote Edited: 0002933 
2015-11-14 01:50 rhansenNote Added: 0002934  
2015-11-14 10:06 geoffclare Note Added: 0002939  
2015-11-14 13:43 kreNote Added: 0002940  
2015-11-14 13:49 kreNote Edited: 0002940 
2015-11-14 14:01 random832  Note Added: 0002941  
2015-11-14 17:26 shware_systems Note Added: 0002944  
2015-11-14 17:27 shware_systems Note Edited: 0002944 
2015-11-14 21:03 random832  Note Added: 0002945  
2015-11-14 21:04 random832  Note Edited: 0002945 
2015-11-15 03:26 rhansenNote Added: 0002946  
2015-11-15 03:43 rhansenNote Edited: 0002946 
2015-11-15 04:22 rhansenNote Added: 0002947  
2015-11-15 07:28 kreNote Added: 0002948  
2015-11-15 07:55 kreNote Edited: 0002940 
2015-11-15 09:14 kreNote Added: 0002949  
2015-11-15 09:25 kre

[1003.1(2013)/Issue7+TC1 0001006]: PS1 should be subject to command substitution and arithmetic expansion

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1006 
== 
Reported By:rhansen
Assigned To:
== 
Project:1003.1(2013)/Issue7+TC1
Issue ID:   1006
Category:   Shell and Utilities
Type:   Omission
Severity:   Editorial
Priority:   normal
Status: Interpretation Required
Name:   Richard Hansen 
Organization:   BBN 
User Reference:  
Section:2.5.3 PS1 
Page Number:2326 
Line Number:73833 
Interp Status:  Pending 
Final Accepted Text:http://austingroupbugs.net/view.php?id=1006#c3310 
== 
Date Submitted: 2015-11-13 08:23 UTC
Last Modified:  2016-08-11 17:09 UTC
== 
Summary:PS1 should be subject to command substitution and
arithmetic expansion
==
Relationships   ID  Summary
--
related to  0001038 Specification relies upon unspecified b...
== 

-- 
 (0003341) shware_systems (reporter) - 2016-08-11 17:09
 http://austingroupbugs.net/view.php?id=1006#c3341 
-- 
How about:
Instead of: The default value shall be "$ ". 

Use:
If PS1 is unset or a zero length value, the shell shall use the string "$ "
as the sequence to output without evaluation for expansion as the default
value. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-11-13 08:23 rhansenNew Issue
2015-11-13 08:23 rhansenName  => Richard Hansen  
2015-11-13 08:23 rhansenOrganization  => BBN 
2015-11-13 08:23 rhansenSection   => 2.5.3 PS1   
2015-11-13 08:23 rhansenPage Number   => 2326
2015-11-13 08:23 rhansenLine Number   => 73833   
2015-11-13 08:23 rhansenInterp Status => --- 
2015-11-13 10:34 joerg  Note Added: 0002906  
2015-11-13 13:51 kreNote Added: 0002907  
2015-11-13 15:44 random832  Note Added: 0002909  
2015-11-13 16:04 random832  Note Edited: 0002909 
2015-11-13 16:11 geoffclare Note Added: 0002911  
2015-11-13 16:33 shware_systems Note Added: 0002913  
2015-11-13 16:36 random832  Note Added: 0002914  
2015-11-13 16:40 random832  Note Edited: 0002914 
2015-11-13 16:47 random832  Note Edited: 0002914 
2015-11-13 16:49 random832  Note Edited: 0002914 
2015-11-13 16:49 random832  Note Edited: 0002914 
2015-11-13 18:21 kreNote Added: 0002918  
2015-11-13 18:29 kreNote Added: 0002919  
2015-11-13 18:31 random832  Note Added: 0002920  
2015-11-14 01:39 rhansenNote Added: 0002932  
2015-11-14 01:40 rhansenNote Added: 0002933  
2015-11-14 01:41 rhansenNote Edited: 0002933 
2015-11-14 01:44 rhansenNote Edited: 0002933 
2015-11-14 01:50 rhansenNote Added: 0002934  
2015-11-14 10:06 geoffclare Note Added: 0002939  
2015-11-14 13:43 kreNote Added: 0002940  
2015-11-14 13:49 kreNote Edited: 0002940 
2015-11-14 14:01 random832  Note Added: 0002941  
2015-11-14 17:26 shware_systems Note Added: 0002944  
2015-11-14 17:27 shware_systems Note Edited: 0002944 
2015-11-14 21:03 random832  Note Added: 0002945  
2015-11-14 21:04 random832  Note Edited: 0002945 
2015-11-15 03:26 rhansenNote Added: 0002946  

[1003.1(2013)/Issue7+TC1 0001006]: PS1 should be subject to command substitution and arithmetic expansion

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1006 
== 
Reported By:rhansen
Assigned To:
== 
Project:1003.1(2013)/Issue7+TC1
Issue ID:   1006
Category:   Shell and Utilities
Type:   Omission
Severity:   Editorial
Priority:   normal
Status: Interpretation Required
Name:   Richard Hansen 
Organization:   BBN 
User Reference:  
Section:2.5.3 PS1 
Page Number:2326 
Line Number:73833 
Interp Status:  Pending 
Final Accepted Text:http://austingroupbugs.net/view.php?id=1006#c3310 
== 
Date Submitted: 2015-11-13 08:23 UTC
Last Modified:  2016-08-11 16:45 UTC
== 
Summary:PS1 should be subject to command substitution and
arithmetic expansion
==
Relationships   ID  Summary
--
related to  0001038 Specification relies upon unspecified b...
== 

-- 
 (0003339) rhansen (manager) - 2016-08-11 16:45
 http://austingroupbugs.net/view.php?id=1006#c3339 
-- 
There's another change to the proposed wording that we may want to
make:Escaping the  character with another
 character (that is, "!!") shall place the
literal  character in the prompt.should be
something like:Escaping the  character with
another  character (that is, "!!") shall expand
to a single  character.because the
exclamation point expansion might happen first and thus the ! might not end
up in the prompt. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-11-13 08:23 rhansenNew Issue
2015-11-13 08:23 rhansenName  => Richard Hansen  
2015-11-13 08:23 rhansenOrganization  => BBN 
2015-11-13 08:23 rhansenSection   => 2.5.3 PS1   
2015-11-13 08:23 rhansenPage Number   => 2326
2015-11-13 08:23 rhansenLine Number   => 73833   
2015-11-13 08:23 rhansenInterp Status => --- 
2015-11-13 10:34 joerg  Note Added: 0002906  
2015-11-13 13:51 kreNote Added: 0002907  
2015-11-13 15:44 random832  Note Added: 0002909  
2015-11-13 16:04 random832  Note Edited: 0002909 
2015-11-13 16:11 geoffclare Note Added: 0002911  
2015-11-13 16:33 shware_systems Note Added: 0002913  
2015-11-13 16:36 random832  Note Added: 0002914  
2015-11-13 16:40 random832  Note Edited: 0002914 
2015-11-13 16:47 random832  Note Edited: 0002914 
2015-11-13 16:49 random832  Note Edited: 0002914 
2015-11-13 16:49 random832  Note Edited: 0002914 
2015-11-13 18:21 kreNote Added: 0002918  
2015-11-13 18:29 kreNote Added: 0002919  
2015-11-13 18:31 random832  Note Added: 0002920  
2015-11-14 01:39 rhansenNote Added: 0002932  
2015-11-14 01:40 rhansenNote Added: 0002933  
2015-11-14 01:41 rhansenNote Edited: 0002933 
2015-11-14 01:44 rhansenNote Edited: 0002933 
2015-11-14 01:50 rhansenNote Added: 0002934  
2015-11-14 10:06 geoffclare Note Added: 0002939  
2015-11-14 13:43 kreNote Added: 0002940  
2015-11-14 13:49 kreNote Edited: 0002940 
2015-11-14 14:01 random832  Note Added: 0002941  
2015-11-14 17:26 shware_systems Note Added: 0002944  
2015-11-14 17:27 shware_systems Note Edited: 0002944 
2015-11-14 21:03 

[1003.1(2013)/Issue7+TC1 0001006]: PS1 should be subject to command substitution and arithmetic expansion

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1006 
== 
Reported By:rhansen
Assigned To:
== 
Project:1003.1(2013)/Issue7+TC1
Issue ID:   1006
Category:   Shell and Utilities
Type:   Omission
Severity:   Editorial
Priority:   normal
Status: Interpretation Required
Name:   Richard Hansen 
Organization:   BBN 
User Reference:  
Section:2.5.3 PS1 
Page Number:2326 
Line Number:73833 
Interp Status:  Pending 
Final Accepted Text:http://austingroupbugs.net/view.php?id=1006#c3310 
== 
Date Submitted: 2015-11-13 08:23 UTC
Last Modified:  2016-08-11 16:10 UTC
== 
Summary:PS1 should be subject to command substitution and
arithmetic expansion
==
Relationships   ID  Summary
--
related to  0001038 Specification relies upon unspecified b...
== 

-- 
 (0003336) rhansen (manager) - 2016-08-11 16:10
 http://austingroupbugs.net/view.php?id=1006#c3336 
-- 
> I object to this interpretation being applied until after issue 1038 is
resolved.

This bug report and http://austingroupbugs.net/view.php?id=1038 touch the same
text, but they are logically
independent and thus the order we resolve them doesn't really matter.  We
will get to http://austingroupbugs.net/view.php?id=1038 eventually; when we do,
the proposed text will say
something like "After applying the changes from
http://austingroupbugs.net/view.php?id=1006, change ... to
...". 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-11-13 08:23 rhansenNew Issue
2015-11-13 08:23 rhansenName  => Richard Hansen  
2015-11-13 08:23 rhansenOrganization  => BBN 
2015-11-13 08:23 rhansenSection   => 2.5.3 PS1   
2015-11-13 08:23 rhansenPage Number   => 2326
2015-11-13 08:23 rhansenLine Number   => 73833   
2015-11-13 08:23 rhansenInterp Status => --- 
2015-11-13 10:34 joerg  Note Added: 0002906  
2015-11-13 13:51 kreNote Added: 0002907  
2015-11-13 15:44 random832  Note Added: 0002909  
2015-11-13 16:04 random832  Note Edited: 0002909 
2015-11-13 16:11 geoffclare Note Added: 0002911  
2015-11-13 16:33 shware_systems Note Added: 0002913  
2015-11-13 16:36 random832  Note Added: 0002914  
2015-11-13 16:40 random832  Note Edited: 0002914 
2015-11-13 16:47 random832  Note Edited: 0002914 
2015-11-13 16:49 random832  Note Edited: 0002914 
2015-11-13 16:49 random832  Note Edited: 0002914 
2015-11-13 18:21 kreNote Added: 0002918  
2015-11-13 18:29 kreNote Added: 0002919  
2015-11-13 18:31 random832  Note Added: 0002920  
2015-11-14 01:39 rhansenNote Added: 0002932  
2015-11-14 01:40 rhansenNote Added: 0002933  
2015-11-14 01:41 rhansenNote Edited: 0002933 
2015-11-14 01:44 rhansenNote Edited: 0002933 
2015-11-14 01:50 rhansenNote Added: 0002934  
2015-11-14 10:06 geoffclare Note Added: 0002939  
2015-11-14 13:43 kreNote Added: 0002940  
2015-11-14 13:49 kreNote Edited: 0002940 
2015-11-14 14:01 random832  Note Added: 0002941  
2015-11-14 17:26 shware_systems Note Added: 0002944  
2015-11-14 17:27 

[1003.1(2013)/Issue7+TC1 0001006]: PS1 should be subject to command substitution and arithmetic expansion

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1006 
== 
Reported By:rhansen
Assigned To:
== 
Project:1003.1(2013)/Issue7+TC1
Issue ID:   1006
Category:   Shell and Utilities
Type:   Omission
Severity:   Editorial
Priority:   normal
Status: Interpretation Required
Name:   Richard Hansen 
Organization:   BBN 
User Reference:  
Section:2.5.3 PS1 
Page Number:2326 
Line Number:73833 
Interp Status:  Pending 
Final Accepted Text:http://austingroupbugs.net/view.php?id=1006#c3310 
== 
Date Submitted: 2015-11-13 08:23 UTC
Last Modified:  2016-08-11 16:48 UTC
== 
Summary:PS1 should be subject to command substitution and
arithmetic expansion
==
Relationships   ID  Summary
--
related to  0001038 Specification relies upon unspecified b...
== 

-- 
 (0003340) kre (reporter) - 2016-08-11 16:48
 http://austingroupbugs.net/view.php?id=1006#c3340 
-- 
wrt note 3336:

This bug report and 0001038 touch the same text,

Actually, no, they don't.  The text here (and/or that which it is
replacing)
provides the motivation that requires 1038 to be fixed, but the fix for
1038
will go elsewhere, I hope.

but they are logically independent

that was my point.   They are not.  In the text in note 3310 (the
resolution)
the default value of PS1 is stated to be "$ " (which is obviously what it
should be) and that it is subject to parameter expansion.

As soon as you specify that, you're specifying undefined behaviour, as a
space after a '$' is explicitly unspecified (see section 2.6)   That is,
given the required default value of PS1 and its required processing, the
shell is permitted to do anything at all.   You cannot seriously mean
that?

We will get to 0001038 eventually;

I'm sure you will, and that's fine - but until that is resolved, you
cannot
in good conscience decide to incorporate this text.   After all, when 1038
is discussed. the resolution may be that a space after a '$' should remain
unspecified, and that it should not be used in any conforming application.
That would mean that PS1="$ " would be both non-conforming, and required.

All that is required is for this issue be suspended until after 1038 is
dealt with, after which what should be in this text can be determined
(and most likely, I hope, what is there now will be fine ... aside from
that
! nonsense, which is a different issue entirely.) 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-11-13 08:23 rhansenNew Issue
2015-11-13 08:23 rhansenName  => Richard Hansen  
2015-11-13 08:23 rhansenOrganization  => BBN 
2015-11-13 08:23 rhansenSection   => 2.5.3 PS1   
2015-11-13 08:23 rhansenPage Number   => 2326
2015-11-13 08:23 rhansenLine Number   => 73833   
2015-11-13 08:23 rhansenInterp Status => --- 
2015-11-13 10:34 joerg  Note Added: 0002906  
2015-11-13 13:51 kreNote Added: 0002907  
2015-11-13 15:44 random832  Note Added: 0002909  
2015-11-13 16:04 random832  Note Edited: 0002909 
2015-11-13 16:11 geoffclare Note Added: 0002911  
2015-11-13 16:33 shware_systems Note Added: 0002913  
2015-11-13 16:36 random832  Note Added: 0002914  
2015-11-13 16:40 random832  Note Edited: 0002914 
2015-11-13 16:47 random832  Note Edited: 0002914 
2015-11-13 16:49 random832  Note Edited: 0002914 
2015-11-13 16:49 random832  Note Edited: 0002914 
2015-11-13 18:21 kreNote Added: 

[1003.1(2013)/Issue7+TC1 0001006]: PS1 should be subject to command substitution and arithmetic expansion

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1006 
== 
Reported By:rhansen
Assigned To:
== 
Project:1003.1(2013)/Issue7+TC1
Issue ID:   1006
Category:   Shell and Utilities
Type:   Omission
Severity:   Editorial
Priority:   normal
Status: Interpretation Required
Name:   Richard Hansen 
Organization:   BBN 
User Reference:  
Section:2.5.3 PS1 
Page Number:2326 
Line Number:73833 
Interp Status:  Pending 
Final Accepted Text:http://austingroupbugs.net/view.php?id=1006#c3310 
== 
Date Submitted: 2015-11-13 08:23 UTC
Last Modified:  2016-08-11 17:41 UTC
== 
Summary:PS1 should be subject to command substitution and
arithmetic expansion
==
Relationships   ID  Summary
--
related to  0001038 Specification relies upon unspecified b...
== 

-- 
 (0003342) kre (reporter) - 2016-08-11 17:41
 http://austingroupbugs.net/view.php?id=1006#c3342 
-- 
Re note 3341

First, don't even consider treating a zero length PS1 (or PS2 or PS4)
as the same as unset - setting the prompt to null is very useful in
some circumstances (like when you're scripting and ddon't want
junk corrupting the script).

Apart from that, that could be a solution, but why?   Do you really want
to make it unspecified if someone explicitly sets PS1 to its defined
default value?   To me that makes no sense.   Nor would it be anything
like traditional for a shell to leave PS1 undefined and then just output '$
'
in that case - while not exactly safe, I have seen scripts that examine
the value of PS1 to decide if they're running as root or not - and other
scripts that save and restore it.

Seems simpler to me to simply make space after '$' stop being unspecified,
and have it mean a literal $ followed by space (as it always has.)  That
is
just fix the wording in 2.6 (and I think somewhere else) and be done with
it - it doesn't have to be solved in this issue, just because this one was
raised first. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-11-13 08:23 rhansenNew Issue
2015-11-13 08:23 rhansenName  => Richard Hansen  
2015-11-13 08:23 rhansenOrganization  => BBN 
2015-11-13 08:23 rhansenSection   => 2.5.3 PS1   
2015-11-13 08:23 rhansenPage Number   => 2326
2015-11-13 08:23 rhansenLine Number   => 73833   
2015-11-13 08:23 rhansenInterp Status => --- 
2015-11-13 10:34 joerg  Note Added: 0002906  
2015-11-13 13:51 kreNote Added: 0002907  
2015-11-13 15:44 random832  Note Added: 0002909  
2015-11-13 16:04 random832  Note Edited: 0002909 
2015-11-13 16:11 geoffclare Note Added: 0002911  
2015-11-13 16:33 shware_systems Note Added: 0002913  
2015-11-13 16:36 random832  Note Added: 0002914  
2015-11-13 16:40 random832  Note Edited: 0002914 
2015-11-13 16:47 random832  Note Edited: 0002914 
2015-11-13 16:49 random832  Note Edited: 0002914 
2015-11-13 16:49 random832  Note Edited: 0002914 
2015-11-13 18:21 kreNote Added: 0002918  
2015-11-13 18:29 kreNote Added: 0002919  
2015-11-13 18:31 random832  Note Added: 0002920  
2015-11-14 01:39 rhansenNote Added: 0002932  
2015-11-14 01:40 rhansenNote Added: 0002933  
2015-11-14 01:41 rhansenNote Edited: 0002933 
2015-11-14 01:44 rhansen

[1003.1(2013)/Issue7+TC1 0001006]: PS1 should be subject to command substitution and arithmetic expansion

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1006 
== 
Reported By:rhansen
Assigned To:
== 
Project:1003.1(2013)/Issue7+TC1
Issue ID:   1006
Category:   Shell and Utilities
Type:   Omission
Severity:   Editorial
Priority:   normal
Status: Interpretation Required
Name:   Richard Hansen 
Organization:   BBN 
User Reference:  
Section:2.5.3 PS1 
Page Number:2326 
Line Number:73833 
Interp Status:  Pending 
Final Accepted Text:http://austingroupbugs.net/view.php?id=1006#c3310 
== 
Date Submitted: 2015-11-13 08:23 UTC
Last Modified:  2016-08-11 19:40 UTC
== 
Summary:PS1 should be subject to command substitution and
arithmetic expansion
==
Relationships   ID  Summary
--
related to  0001038 Specification relies upon unspecified b...
== 

-- 
 (0003343) rhansen (manager) - 2016-08-11 19:40
 http://austingroupbugs.net/view.php?id=1006#c3343 
-- 
>> but they are logically independent
>
> that was my point. They are not. In the text in
http://austingroupbugs.net/view.php?id=1006#c3310 (the
resolution)
> the default value of PS1 is stated to be "$ " (which is obviously what
it
> should be) and that it is subject to parameter expansion.
>
> As soon as you specify that, you're specifying undefined behaviour

Yes, but the standard already said that PS1 was subject to parameter
expansion and that the default value is "$ ".  The changes in
http://austingroupbugs.net/view.php?id=1006#c3310
do not change the nature of the flaw described in
http://austingroupbugs.net/view.php?id=1038.  That's what
I mean by logically independent. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-11-13 08:23 rhansenNew Issue
2015-11-13 08:23 rhansenName  => Richard Hansen  
2015-11-13 08:23 rhansenOrganization  => BBN 
2015-11-13 08:23 rhansenSection   => 2.5.3 PS1   
2015-11-13 08:23 rhansenPage Number   => 2326
2015-11-13 08:23 rhansenLine Number   => 73833   
2015-11-13 08:23 rhansenInterp Status => --- 
2015-11-13 10:34 joerg  Note Added: 0002906  
2015-11-13 13:51 kreNote Added: 0002907  
2015-11-13 15:44 random832  Note Added: 0002909  
2015-11-13 16:04 random832  Note Edited: 0002909 
2015-11-13 16:11 geoffclare Note Added: 0002911  
2015-11-13 16:33 shware_systems Note Added: 0002913  
2015-11-13 16:36 random832  Note Added: 0002914  
2015-11-13 16:40 random832  Note Edited: 0002914 
2015-11-13 16:47 random832  Note Edited: 0002914 
2015-11-13 16:49 random832  Note Edited: 0002914 
2015-11-13 16:49 random832  Note Edited: 0002914 
2015-11-13 18:21 kreNote Added: 0002918  
2015-11-13 18:29 kreNote Added: 0002919  
2015-11-13 18:31 random832  Note Added: 0002920  
2015-11-14 01:39 rhansenNote Added: 0002932  
2015-11-14 01:40 rhansenNote Added: 0002933  
2015-11-14 01:41 rhansenNote Edited: 0002933 
2015-11-14 01:44 rhansenNote Edited: 0002933 
2015-11-14 01:50 rhansenNote Added: 0002934  
2015-11-14 10:06 geoffclare Note Added: 0002939  
2015-11-14 13:43 kreNote Added: 0002940  
2015-11-14 13:49 kreNote Edited: 0002940  

[1003.1(2013)/Issue7+TC1 0001066]: Solution proposal to the 2038 problem.

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1066 
== 
Reported By:dannyniu
Assigned To:
== 
Project:1003.1(2013)/Issue7+TC1
Issue ID:   1066
Category:   Base Definitions and Headers
Type:   Enhancement Request
Severity:   Editorial
Priority:   normal
Status: New
Name:   DannyNiu/NJF 
Organization:
User Reference:  
Section:Base Definition. 8.3 Other Environment Variables 
Page Number:New 
Line Number:New 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2016-08-11 03:22 UTC
Last Modified:  2016-08-11 20:41 UTC
== 
Summary:Solution proposal to the 2038 problem.
== 

-- 
 (0003344) Vincent Lefevre (reporter) - 2016-08-11 20:41
 http://austingroupbugs.net/view.php?id=1066#c3344 
-- 
Binary compatibility is not just the size of the types, but also the
behavior. If I understand correctly, the tricks you mentioned change the
behavior of applications that would deal with dates before 25 Nov 1932.
This may not be common, but I would not say that binary compatibility is
retained with these tricks. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-08-11 03:22 dannyniu   New Issue
2016-08-11 03:22 dannyniu   Name  => DannyNiu/NJF
2016-08-11 03:22 dannyniu   Section   => Base Definition.
8.3 Other Environment Variables
2016-08-11 03:22 dannyniu   Page Number   => New 
2016-08-11 03:22 dannyniu   Line Number   => New 
2016-08-11 09:30 joerg  Note Added: 0003331  
2016-08-11 09:31 joerg  Note Edited: 0003331 
2016-08-11 10:01 EdSchouten Note Added: 0003332  
2016-08-11 10:23 joerg  Note Added: 000  
2016-08-11 20:41 Vincent LefevreNote Added: 0003344  
==

[1003.1(2013)/Issue7+TC1 0001006]: PS1 should be subject to command substitution and arithmetic expansion

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1006 
== 
Reported By:rhansen
Assigned To:
== 
Project:1003.1(2013)/Issue7+TC1
Issue ID:   1006
Category:   Shell and Utilities
Type:   Omission
Severity:   Editorial
Priority:   normal
Status: Interpretation Required
Name:   Richard Hansen 
Organization:   BBN 
User Reference:  
Section:2.5.3 PS1 
Page Number:2326 
Line Number:73833 
Interp Status:  Pending 
Final Accepted Text:http://austingroupbugs.net/view.php?id=1006#c3310 
== 
Date Submitted: 2015-11-13 08:23 UTC
Last Modified:  2016-08-11 22:07 UTC
== 
Summary:PS1 should be subject to command substitution and
arithmetic expansion
==
Relationships   ID  Summary
--
related to  0001038 Specification relies upon unspecified b...
== 

-- 
 (0003345) shware_systems (reporter) - 2016-08-11 22:07
 http://austingroupbugs.net/view.php?id=1006#c3345 
-- 
The idea is, for interactive use, something standard gets visibly
displayed. Both unset and zero length don't have any chars that can be
construed as their value to attempt expansion with, or will be visible. It
is little different from IFS using it's default value when zero length, so
there is precedent. From the user's perspective I feel that is simplest.
Otherwise there's no visible means to tell a previous application may have
finished processing if it does not output a "Yes, I'm done" message of its
own. When processing a script PS1 isn't evaluated anyways. PS4 might be,
but this refinement is for PS1 because the default uses '$' and the others
don't. Also, expansion is limited to the value PS1 is set to. The text does
not say PS1 shall be set to the default value, which would imply "$ " is
expected to be evaluated, just that this is the value that will be used
(for output). Someone can use a zero display width string as prompt, such
as  or  chars, if they don't want anything visible. Saying "no
prompt is visible if the expansion result is zero length" can be rolled
into privileges appropriate alternative too.

As it is, tokenization of "$ " is specified in XCU 2.3 by items 5 and 7, 8,
and 10 for a conforming shell. Item 9 covers the "$#" sequence. Item 5
makes '$' a candidate for expansion, yes, but the immediately following ' '
makes it a non-candidate trailer to the current WORD token, by Item 7, as
the specified behavior. Similarly for other following chars, if not a legal
expansion continuation that changes the state from expansion candidate to
pending expansion, the '$' and following char are simply appended to the
current token value as text by Item 8 or start a new token by Item 10.
Those are the first rules that apply since the conditions for Item 5 to
apply aren't met. Where XCU 2.6 is in error is the list of continuing chars
just before XCU 2.6.1 is correct, but to me it should say "the current
token is appended to as if the $ was escaped, plus any non-delimiter char,
per XCU 2.3" not "the result is unspecified". Unspecified leaves open the
possibility for extensions when not in conforming mode, granted, or saying
it is a syntax error, but I see the behavior as defined for strictly
conforming. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-11-13 08:23 rhansenNew Issue
2015-11-13 08:23 rhansenName  => Richard Hansen  
2015-11-13 08:23 rhansenOrganization  => BBN 
2015-11-13 08:23 rhansenSection   => 2.5.3 PS1   
2015-11-13 08:23 rhansenPage Number   => 2326
2015-11-13 08:23 rhansenLine Number   => 73833   
2015-11-13 08:23 rhansenInterp Status => --- 
2015-11-13 10:34 joerg  Note Added: 0002906  
2015-11-13 13:51 kreNote Added: 0002907 

[1003.1(2013)/Issue7+TC1 0001067]: missing socket() error for unsupported socket type

[Austin Group Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://austingroupbugs.net/view.php?id=1067 
== 
Reported By:geoffclare
Assigned To:
== 
Project:1003.1(2013)/Issue7+TC1
Issue ID:   1067
Category:   System Interfaces
Type:   Omission
Severity:   Objection
Priority:   normal
Status: New
Name:   Geoff Clare 
Organization:   The Open Group 
User Reference:  
Section:socket 
Page Number:1984 
Line Number:63551-63559 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2016-08-11 08:34 UTC
Last Modified:  2016-08-11 08:34 UTC
== 
Summary:missing socket() error for unsupported socket type
Description: 
The ERRORS section for socket() does not list an error number to be
used when the socket type is not supported by the address family.
This is different from the condition listed for EPROTOTYPE: "The
socket type is not supported by the protocol" because, in
particular, the latter does not cover the case when the protocol
argument is zero.

I have observed three different behaviours on existing systems.
It looks like System V derivatives use EPROTOTYPE for this even
though no protocol was specified (tested on Solaris 11 and HP-UX 11).
OS X uses EPROTONOSUPPORT and Linux uses a non-standard error number
(ESOCKTNOSUPPORT).

The call I used to test this was socket(AF_INET, SOCK_SEQPACKET, 0).

The socketpair() page has the same problem.

Desired Action: 
There are seven options (some only included for completeness and not
worth considering):

1. Only allow EPROTOTYPE

2. Only allow EPROTONOSUPPORT

3. Only allow ESOCKTNOSUPPORT

4. Allow EPROTOTYPE or EPROTONOSUPPORT

5. Allow EPROTOTYPE or ESOCKTNOSUPPORT

6. Allow EPROTONOSUPPORT or ESOCKTNOSUPPORT

7. Allow all three.

I will propose wording changes for socket() and socketpair() once the
group chooses one of these options.

== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-08-11 08:34 geoffclare New Issue
2016-08-11 08:34 geoffclare Name  => Geoff Clare 
2016-08-11 08:34 geoffclare Organization  => The Open Group  
2016-08-11 08:34 geoffclare Section   => socket  
2016-08-11 08:34 geoffclare Page Number   => 1984
2016-08-11 08:34 geoffclare Line Number   => 63551-63559 
2016-08-11 08:34 geoffclare Interp Status => --- 
==

[1003.1(2013)/Issue7+TC1 0001050]: Add support for the hyphen character in alias names and shell names

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1050 
== 
Reported By:steffen
Assigned To:
== 
Project:1003.1(2013)/Issue7+TC1
Issue ID:   1050
Category:   Base Definitions and Headers
Type:   Enhancement Request
Severity:   Editorial
Priority:   normal
Status: New
Name:   steffen 
Organization:
User Reference:  
Section:3. Definitions 
Page Number:34, 70 
Line Number:1168, 2015 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2016-04-30 14:43 UTC
Last Modified:  2016-08-11 23:10 UTC
== 
Summary:Add support for the hyphen character in alias names
and shell names
== 

-- 
 (0003346) Don Cragun (manager) - 2016-08-11 23:10
 http://austingroupbugs.net/view.php?id=1050#c3346 
-- 
Why would we want to add am ambiguity into the meaning of arithmetic
expansions?  If - is allowed in a variable name, what output should:
x=3
y=2
x-y=5
echo $((x-y))

Furthermore, scripts using a shell conforming to the current standard
expect the command (assuming the assignments in the above example are still
in effect) expect the command:
echo $x-y
to print:
3-y
not:
5 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-04-30 14:43 steffenNew Issue
2016-04-30 14:43 steffenName  => steffen 
2016-04-30 14:43 steffenSection   => 3. Definitions  
2016-04-30 14:43 steffenPage Number   => 34, 70  
2016-04-30 14:43 steffenLine Number   => 1168, 2015  
2016-04-30 14:55 shware_systems Note Added: 0003189  
2016-04-30 14:58 shware_systems Note Edited: 0003189 
2016-04-30 15:17 shware_systems Note Edited: 0003189 
2016-04-30 16:50 kreNote Added: 0003190  
2016-04-30 16:51 kreNote Edited: 0003190 
2016-05-02 12:53 steffenNote Added: 0003191  
2016-05-02 14:58 kreNote Added: 0003192  
2016-05-02 18:59 dwheeler   Note Added: 0003193  
2016-05-02 21:19 kreNote Added: 0003194  
2016-05-26 13:52 ormaaj Note Added: 0003232  
2016-08-11 23:10 Don Cragun Note Added: 0003346  
==

[1003.1(2013)/Issue7+TC1 0001050]: Add support for the hyphen character in alias names and shell names

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1050 
== 
Reported By:steffen
Assigned To:
== 
Project:1003.1(2013)/Issue7+TC1
Issue ID:   1050
Category:   Base Definitions and Headers
Type:   Enhancement Request
Severity:   Editorial
Priority:   normal
Status: New
Name:   steffen 
Organization:
User Reference:  
Section:3. Definitions 
Page Number:34, 70 
Line Number:1168, 2015 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2016-04-30 14:43 UTC
Last Modified:  2016-08-11 23:28 UTC
== 
Summary:Add support for the hyphen character in alias names
and shell names
== 

-- 
 (0003347) kre (reporter) - 2016-08-11 23:28
 http://austingroupbugs.net/view.php?id=1050#c3347 
-- 
It is quite clear that shell variable names cannot be allowed to
contain '-' (and lots of other non-alphanumeric chars)- but there is no
reason at all that alias names, function names, etc need to use the same
syntax as variable names.

In fact, they should not - they should both use the same syntax as command
names, which in shell grammar, is "word". 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-04-30 14:43 steffenNew Issue
2016-04-30 14:43 steffenName  => steffen 
2016-04-30 14:43 steffenSection   => 3. Definitions  
2016-04-30 14:43 steffenPage Number   => 34, 70  
2016-04-30 14:43 steffenLine Number   => 1168, 2015  
2016-04-30 14:55 shware_systems Note Added: 0003189  
2016-04-30 14:58 shware_systems Note Edited: 0003189 
2016-04-30 15:17 shware_systems Note Edited: 0003189 
2016-04-30 16:50 kreNote Added: 0003190  
2016-04-30 16:51 kreNote Edited: 0003190 
2016-05-02 12:53 steffenNote Added: 0003191  
2016-05-02 14:58 kreNote Added: 0003192  
2016-05-02 18:59 dwheeler   Note Added: 0003193  
2016-05-02 21:19 kreNote Added: 0003194  
2016-05-26 13:52 ormaaj Note Added: 0003232  
2016-08-11 23:10 Don Cragun Note Added: 0003346  
2016-08-11 23:10 Don Cragun Note Edited: 0003346 
2016-08-11 23:11 Don Cragun Note Edited: 0003346 
2016-08-11 23:28 kreNote Added: 0003347  
==

[1003.1(2013)/Issue7+TC1 0001050]: Add support for the hyphen character in alias names and shell names

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1050 
== 
Reported By:steffen
Assigned To:
== 
Project:1003.1(2013)/Issue7+TC1
Issue ID:   1050
Category:   Base Definitions and Headers
Type:   Enhancement Request
Severity:   Editorial
Priority:   normal
Status: New
Name:   steffen 
Organization:
User Reference:  
Section:3. Definitions 
Page Number:34, 70 
Line Number:1168, 2015 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2016-04-30 14:43 UTC
Last Modified:  2016-08-11 23:39 UTC
== 
Summary:Add support for the hyphen character in alias names
and shell names
== 

-- 
 (0003348) philip-guenther (reporter) - 2016-08-11 23:39
 http://austingroupbugs.net/view.php?id=1050#c3348 
-- 
> Why would we want to add am ambiguity into the meaning of arithmetic
expansions?
> If - is allowed in a variable name,   <...>

Given the summary of this bug, that isn't what is wanted.  To achieve what
is wanted, the use of 'name' in section 2.5 "Parameters and Variables":
 A parameter can be denoted by a name, a number, or one of the special
 characters listed in Section 2.5.2. A variable is a parameter denoted
 by a name.

will need to be changed.  I would suggest that a new definition be added
"Variable Name", which matches the current "Name" definition, ala:
 In the shell command language, a word for designating a variable,
consisting
 solely of underscores, digits, and alphabetics from the portable
character
 set. The first character of a variable name is not a digit.

...and then 2.5 updated to reference that, ala:
 A parameter can be denoted by a variable name, a number, or one of the
special
 characters listed in Section 2.5.2. A variable is a parameter denoted
 by a variable name. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-04-30 14:43 steffenNew Issue
2016-04-30 14:43 steffenName  => steffen 
2016-04-30 14:43 steffenSection   => 3. Definitions  
2016-04-30 14:43 steffenPage Number   => 34, 70  
2016-04-30 14:43 steffenLine Number   => 1168, 2015  
2016-04-30 14:55 shware_systems Note Added: 0003189  
2016-04-30 14:58 shware_systems Note Edited: 0003189 
2016-04-30 15:17 shware_systems Note Edited: 0003189 
2016-04-30 16:50 kreNote Added: 0003190  
2016-04-30 16:51 kreNote Edited: 0003190 
2016-05-02 12:53 steffenNote Added: 0003191  
2016-05-02 14:58 kreNote Added: 0003192  
2016-05-02 18:59 dwheeler   Note Added: 0003193  
2016-05-02 21:19 kreNote Added: 0003194  
2016-05-26 13:52 ormaaj Note Added: 0003232  
2016-08-11 23:10 Don Cragun Note Added: 0003346  
2016-08-11 23:10 Don Cragun Note Edited: 0003346 
2016-08-11 23:11 Don Cragun Note Edited: 0003346 
2016-08-11 23:28 kreNote Added: 0003347  
2016-08-11 23:39 philip-guentherNote Added: 0003348  
==

[1003.1(2016)/Issue7+TC2 0001118]: Clarify meaning of "file lock"

[Austin Group Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://austingroupbugs.net/view.php?id=1118 
== 
Reported By:rpalethorpe
Assigned To:
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1118
Category:   Base Definitions and Headers
Type:   Clarification Requested
Severity:   Comment
Priority:   normal
Status: New
Name:   Richard Palethorpe 
Organization:   SUSE 
User Reference:  
Section:fork, fcntl, flockfile 
Page Number:fork 
Line Number:20ish 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2017-01-20 13:05 UTC
Last Modified:  2017-01-20 13:05 UTC
== 
Summary:Clarify meaning of "file lock"
Description: 
In http://pubs.opengroup.org/onlinepubs/9699919799/ (fork) it states that
"File locks set by the parent process shall not be inherited by the child
process.".

As far as I can tell, the phrase 'file lock', is not explicitly defined and
there are at least two types of lock which could be described as a 'file
lock'. One is the type of lock established by fcntl(), which states in its
rationale that locks are not inherited through fork(). The other is a lock
established by flockfile() which makes no mention of fork().

Furthermore, in this context, the term 'inherited' could be taken to mean
that the lock's data structures are copied to the child or that the
ownership of the lock is inherited by the child (i.e. the child can access
a file locked by the parent) or that the child is subject to restrictions
imposed by the locks (i.e. it can't access a locked file).

This may or may not be related to:
http://austingroupbugs.net/view.php?id=1112
Desired Action: 
1. Explicitly state the types of lock meant by 'file lock'
2. Elaborate on the term 'inherit' in the context of file locks during a
process fork or cite its definition.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2017-01-20 13:05 rpalethorpeNew Issue
2017-01-20 13:05 rpalethorpeName  => Richard Palethorpe
2017-01-20 13:05 rpalethorpeOrganization  => SUSE
2017-01-20 13:05 rpalethorpeSection   => fork, fcntl,
flockfile
2017-01-20 13:05 rpalethorpePage Number   => fork
2017-01-20 13:05 rpalethorpeLine Number   => 20ish   
==

[1003.1(2008)/Issue 7 0001119]: When the file named by the operand does not exist, `file` should not exit with zero status

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1119 
== 
Reported By:mhjacobson
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   1119
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Objection
Priority:   normal
Status: Under Review
Name:   Matt Jacobson 
Organization:
User Reference:  
Section:file 
Page Number:0 
Line Number:0 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2017-02-15 01:48 UTC
Last Modified:  2017-02-21 12:06 UTC
== 
Summary:When the file named by the  operand does not
exist, `file` should not exit with zero status
== 

-- 
 (0003564) joerg (reporter) - 2017-02-21 12:06
 http://austingroupbugs.net/view.php?id=1119#c3564 
-- 
Besides the fact that such a change could break existing scripts, file's
task is to return information about the path name and:

LC_ALL=C file /tmp/missing 
/tmp/missing:  cannot open: No such file or directory

may be seen as "information" about the path in question. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2017-02-15 01:48 mhjacobson New Issue
2017-02-15 01:48 mhjacobson Status   New => Under Review 
2017-02-15 01:48 mhjacobson Assigned To   => ajosey  
2017-02-15 01:48 mhjacobson Name  => Matt Jacobson   
2017-02-15 01:48 mhjacobson Section   => file
2017-02-15 01:48 mhjacobson Page Number   => 0   
2017-02-15 01:48 mhjacobson Line Number   => 0   
2017-02-21 01:55 Vincent LefevreNote Added: 0003563  
2017-02-21 12:06 joerg  Note Added: 0003564  
==

[1003.1(2008)/Issue 7 0001119]: When the file named by the operand does not exist, `file` should not exit with zero status

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1119 
== 
Reported By:mhjacobson
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   1119
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Objection
Priority:   normal
Status: Under Review
Name:   Matt Jacobson 
Organization:
User Reference:  
Section:file 
Page Number:0 
Line Number:0 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2017-02-15 01:48 UTC
Last Modified:  2017-02-21 14:07 UTC
== 
Summary:When the file named by the  operand does not
exist, `file` should not exit with zero status
== 

-- 
 (0003565) shware_systems (reporter) - 2017-02-21 14:07
 http://austingroupbugs.net/view.php?id=1119#c3565 
-- 
Also, note the ellipsis on the file operand. If it was required to return
non-zero if any operand was not present, a script wouldn't know which
operand the return applied to anyways. This proposal could be an extension
behavior for the limiting case of only one file operand, but 'test -e file'
already provides the same info unambiguously. The Exit Status section could
be more descriptive that >0 returns relate to system conditions like
utility not found/not executable or out of memory/file handles, and not
about a particular operand.

As an aid to parsing, numbering the file types expected to be reported and
including this in the output for each file, using "%s:%2d %s" as first part
of format strings, would be more the way I'd expect an extension to be
implemented. This can be added to the current outputs anyways without
affecting conformance, but then the number assignments would be more prone
to vary among implementations. This would also distinguish the 'does not
exist' case from the 'cannot read/write only' case. A new switch, e.g.
-n[umber code], could control whether this format is used instead of the
current one for backwards compatibility purposes. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2017-02-15 01:48 mhjacobson New Issue
2017-02-15 01:48 mhjacobson Status   New => Under Review 
2017-02-15 01:48 mhjacobson Assigned To   => ajosey  
2017-02-15 01:48 mhjacobson Name  => Matt Jacobson   
2017-02-15 01:48 mhjacobson Section   => file
2017-02-15 01:48 mhjacobson Page Number   => 0   
2017-02-15 01:48 mhjacobson Line Number   => 0   
2017-02-21 01:55 Vincent LefevreNote Added: 0003563  
2017-02-21 12:06 joerg  Note Added: 0003564  
2017-02-21 14:07 shware_systems Note Added: 0003565  
==

[1003.1(2013)/Issue7+TC1 0001006]: PS1 should be subject to command substitution and arithmetic expansion

[Austin Group Bug Tracker]

The following issue has been UPDATED. 
== 
http://austingroupbugs.net/view.php?id=1006 
== 
Reported By:rhansen
Assigned To:
== 
Project:1003.1(2013)/Issue7+TC1
Issue ID:   1006
Category:   Shell and Utilities
Type:   Omission
Severity:   Editorial
Priority:   normal
Status: Interpretation Required
Name:   Richard Hansen 
Organization:   BBN 
User Reference:  
Section:2.5.3 PS1 
Page Number:2326 
Line Number:73833 
Interp Status:  Approved 
Final Accepted Text:http://austingroupbugs.net/view.php?id=1006#c3310 
== 
Date Submitted: 2015-11-13 08:23 UTC
Last Modified:  2017-02-22 08:31 UTC
== 
Summary:PS1 should be subject to command substitution and
arithmetic expansion
==
Relationships   ID  Summary
--
related to  0001038 Specification relies upon unspecified b...
== 

-- 
 (0003567) ajosey (manager) - 2017-02-22 08:31
 http://austingroupbugs.net/view.php?id=1006#c3567 
-- 
Interpretation approved: 22 Feb 2017 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-11-13 08:23 rhansenNew Issue
2015-11-13 08:23 rhansenName  => Richard Hansen  
2015-11-13 08:23 rhansenOrganization  => BBN 
2015-11-13 08:23 rhansenSection   => 2.5.3 PS1   
2015-11-13 08:23 rhansenPage Number   => 2326
2015-11-13 08:23 rhansenLine Number   => 73833   
2015-11-13 08:23 rhansenInterp Status => --- 
2015-11-13 10:34 joerg  Note Added: 0002906  
2015-11-13 13:51 kreNote Added: 0002907  
2015-11-13 15:44 random832  Note Added: 0002909  
2015-11-13 16:04 random832  Note Edited: 0002909 
2015-11-13 16:11 geoffclare Note Added: 0002911  
2015-11-13 16:33 shware_systems Note Added: 0002913  
2015-11-13 16:36 random832  Note Added: 0002914  
2015-11-13 16:40 random832  Note Edited: 0002914 
2015-11-13 16:47 random832  Note Edited: 0002914 
2015-11-13 16:49 random832  Note Edited: 0002914 
2015-11-13 16:49 random832  Note Edited: 0002914 
2015-11-13 18:21 kreNote Added: 0002918  
2015-11-13 18:29 kreNote Added: 0002919  
2015-11-13 18:31 random832  Note Added: 0002920  
2015-11-14 01:39 rhansenNote Added: 0002932  
2015-11-14 01:40 rhansenNote Added: 0002933  
2015-11-14 01:41 rhansenNote Edited: 0002933 
2015-11-14 01:44 rhansenNote Edited: 0002933 
2015-11-14 01:50 rhansenNote Added: 0002934  
2015-11-14 10:06 geoffclare Note Added: 0002939  
2015-11-14 13:43 kreNote Added: 0002940  
2015-11-14 13:49 kreNote Edited: 0002940 
2015-11-14 14:01 random832  Note Added: 0002941  
2015-11-14 17:26 shware_systems Note Added: 0002944  
2015-11-14 17:27 shware_systems Note Edited: 0002944 
2015-11-14 21:03 random832  Note Added: 0002945  
2015-11-14 21:04 random832  Note Edited: 0002945 
2015-11-15 03:26 rhansenNote Added: 0002946  
2015-11-15 03:43 rhansenNote Edited: 0002946 
2015-11-15 04:22 rhansenNote Added: 0002947  

[1003.1(2013)/Issue7+TC1 0001068]: Binding to a system-assigned port.

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1068 
== 
Reported By:dannyniu
Assigned To:
== 
Project:1003.1(2013)/Issue7+TC1
Issue ID:   1068
Category:   Base Definitions and Headers
Type:   Omission
Severity:   Objection
Priority:   normal
Status: New
Name:   DannyNiu/NJF 
Organization:
User Reference:  
Section:Base Definition, Headers  
Page Number:307 
Line Number:10260 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2016-08-22 03:14 UTC
Last Modified:  2017-02-19 05:28 UTC
== 
Summary:Binding to a system-assigned port.
== 

-- 
 (0003561) dannyniu (reporter) - 2017-02-19 05:28
 http://austingroupbugs.net/view.php?id=1068#c3561 
-- 
The biggest reason I propose to add it to the standard, is because it's
been taught as standard practice. 

Here quotes "UNIX Network Programming", by W. Richard Stevens et.al. 

Section 4.4 bind Function. 

..., but it is rare for a TCP server to let the kernel choose an ephemeral
port, since servers are known by their well-known port. 
Exception to this rule are Remote Procedure Call (RPC) servers. 
...
If we specify a port number of 0, the kernel chooses an ephemeral port when
bind is called. 
... 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-08-22 03:14 dannyniu   New Issue
2016-08-22 03:14 dannyniu   Name  => DannyNiu/NJF
2016-08-22 03:14 dannyniu   Section   => Base Definition,
Headers 
2016-08-22 03:14 dannyniu   Page Number   => 307 
2016-08-22 03:14 dannyniu   Line Number   => 10260   
2016-08-22 16:45 shware_systems Note Added: 0003354  
2017-02-19 05:28 dannyniu   Note Added: 0003561  
==

[1003.1(2008)/Issue 7 0001119]: When the file named by the operand does not exist, `file` should not exit with zero status

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1119 
== 
Reported By:mhjacobson
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   1119
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Objection
Priority:   normal
Status: Under Review
Name:   Matt Jacobson 
Organization:
User Reference:  
Section:file 
Page Number:0 
Line Number:0 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2017-02-15 01:48 UTC
Last Modified:  2017-02-21 01:55 UTC
== 
Summary:When the file named by the  operand does not
exist, `file` should not exit with zero status
== 

-- 
 (0003563) Vincent Lefevre (reporter) - 2017-02-21 01:55
 http://austingroupbugs.net/view.php?id=1119#c3563 
-- 
A change could break existing scripts. http://www.darwinsys.com/file/ uses
an option -E to regard filesystem errors (such as file not found) as usual
errors. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2017-02-15 01:48 mhjacobson New Issue
2017-02-15 01:48 mhjacobson Status   New => Under Review 
2017-02-15 01:48 mhjacobson Assigned To   => ajosey  
2017-02-15 01:48 mhjacobson Name  => Matt Jacobson   
2017-02-15 01:48 mhjacobson Section   => file
2017-02-15 01:48 mhjacobson Page Number   => 0   
2017-02-15 01:48 mhjacobson Line Number   => 0   
2017-02-21 01:55 Vincent LefevreNote Added: 0003563  
==

[1003.1(2004)/Issue 6 0001120]: Permit access to static storage objects from signal handlers if synchronization is guaranteed by use of the signal mask

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1120 
== 
Reported By:a3f
Assigned To:ajosey
== 
Project:1003.1(2004)/Issue 6
Issue ID:   1120
Category:   System Interfaces
Type:   Enhancement Request
Severity:   Editorial
Priority:   normal
Status: Under Review
Name:   Ahmad Fatoum 
Organization:
User Reference:  
Section:2.4.3 Signal Actions 
Page Number:493 
Line Number:16839-16842 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2017-02-23 02:38 UTC
Last Modified:  2017-02-25 20:20 UTC
== 
Summary:Permit access to static storage objects from signal
handlers if synchronization is guaranteed by use of the signal mask
== 

-- 
 (0003573) shware_systems (reporter) - 2017-02-25 20:20
 http://austingroupbugs.net/view.php?id=1120#c3573 
-- 
This is nominally on my to do list, but there are significant issues C11
leaves under-specified. I don't believe there is a current implementation
of the concept that can be considered portable either.

While C11 does add thread local or static lock-free variables >may< be
referred to in the signal() description, I see this as necessarily
platform-dependent; no types with an _Atomic qualifier are required to be
lock-free. Which ones are lock-free on a given platform is reported via the
ATOMIC_*_LOCK_FREE macros, and these can all be set to a 0 value,
indicating "never lock-free". With CPUs that do not support
read-modify-write operations, which I believe is most RISC architectures,
this will be the usual case. Compilers for these platforms are more likely
to #define __STDC_NO_ATOMICS__ instead, and block any attempt to #undef the
symbol. 

Some CISC CPUs, like the x86 series, use LOCK prefixes on r-m-w operations
to force atomicity. On those systems the atomic_is_lock_free() interface
can, and should imo, always return 1 for static variables. Thread local
storage blocked from any type of sharing might return 2, and is the class
of storage I'd limit an extension like this to. The  and
 headers need additional interfaces imo to make this robust,
however. Unspecified compiler options determine which code gets LOCK
prefixes, not an objects location in RAM, so a restriction like this I see
as needed to make prefixes unnecessary.

The only type required to behave as atomically accessible in handlers on
all platforms is still sig_atomic_t, and even when volatile qualified the
atomicity guarantee is for a single read or single write. An overwrite of
the location by a separate CPU sharing the memory or DMA peripheral can
occur during any modify operation in between made by a handler, whether the
signal is blocked or not. The C logical model, still, more assumes a single
CPU has access to RAM and I/O is handled synchronously via port accesses by
a single threaded process, so doesn't really address these common
possibilities.

The net effect I see is strictly conforming handler code will still be
limited to variables of sig_atomic_t type in Issue 8. To what extent the
 header will be characterized as an option, extended as
above, subset-ted, or can be provided via emulation using mutexes and
similar (despite the performance hit), is still to be determined. It
probably won't be until Issue 10 before whatever is approved can be made
part of the base, if c2x leaves it as an optional header. C11 makes
provision for emulation by allowing a mutex or other lock to be attached to
an _Atomic declaration, in 7.17.6p3. A plausible subset that should be
portable is requiring init, load, store, and fences be supported for just
int and unsigned int, but exclude the fetch, xchg, and flag operations, as
this is basically the level of support sig_atomic_t needs anyways.

Requiring all elements of any arrays or structs to be _Atomic qualified I
think will be necessary also for this extension, possibly volatile
qualified also. For arrays this is an extension to C11, and the standard is
ambiguous, to me, about the effects of _Atomic as a type qualifier of
structs and unions, or type specifier with a struct typedef type-name as
argument. Further requirements related to process shared memory and locking
also 

[1003.1(2013)/Issue7+TC1 0001068]: Binding to a system-assigned port.

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1068 
== 
Reported By:dannyniu
Assigned To:
== 
Project:1003.1(2013)/Issue7+TC1
Issue ID:   1068
Category:   Base Definitions and Headers
Type:   Omission
Severity:   Objection
Priority:   normal
Status: New
Name:   DannyNiu/NJF 
Organization:
User Reference:  
Section:Base Definition, Headers  
Page Number:307 
Line Number:10260 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2016-08-22 03:14 UTC
Last Modified:  2017-02-19 16:18 UTC
== 
Summary:Binding to a system-assigned port.
== 

-- 
 (0003562) shware_systems (reporter) - 2017-02-19 16:18
 http://austingroupbugs.net/view.php?id=1068#c3562 
-- 
That teaching practice is faulty; in that any platform where it applies has
overloaded the IETF reserved value, and subsequent protocol-specific
usages, by arbitrarily assigning this specific function to it. It is
therefore imho a platform-specific, not standard, practice. The place to
propose this is more in an IETF RFC as explicit currently unused port
values, with my suggested expansions. As some ports are already reserved
for similar use it shouldn't be considered too controversial, I imagine,
for STD/BCP status as an amendment of RFC 6335. 

This way POSIX and all other platforms can defer to that, going forward,
and stay compatible with each other. Existing systems and applications that
might break due to the change at least can reuse most of their code; for
some it may be as simple as a single line header patch and recompile.

Changing get/setsockopt() as suggested doesn't require an RFC, as it
doesn't lock down any value assignments, but would be more complex for an
application to make use of in a safe manner. It would also be limited to
use across a known LAN setup of POSIX conforming systems, as across a WAN
or the WWW it couldn't be guaranteed addressable platforms are compatible
with all aspects of how the new functionality may be implemented. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-08-22 03:14 dannyniu   New Issue
2016-08-22 03:14 dannyniu   Name  => DannyNiu/NJF
2016-08-22 03:14 dannyniu   Section   => Base Definition,
Headers 
2016-08-22 03:14 dannyniu   Page Number   => 307 
2016-08-22 03:14 dannyniu   Line Number   => 10260   
2016-08-22 16:45 shware_systems Note Added: 0003354  
2017-02-19 05:28 dannyniu   Note Added: 0003561  
2017-02-19 16:18 shware_systems Note Added: 0003562  
==

[1003.1(2004)/Issue 6 0001120]: Permit access to static storage objects from signal handlers if synchronization is guaranteed by use of the signal mask

[Austin Group Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://austingroupbugs.net/view.php?id=1120 
== 
Reported By:a3f
Assigned To:ajosey
== 
Project:1003.1(2004)/Issue 6
Issue ID:   1120
Category:   System Interfaces
Type:   Enhancement Request
Severity:   Editorial
Priority:   normal
Status: Under Review
Name:   Ahmad Fatoum 
Organization:
User Reference:  
Section:2.4.3 Signal Actions 
Page Number:493 
Line Number:16839-16842 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2017-02-23 02:38 UTC
Last Modified:  2017-02-23 02:38 UTC
== 
Summary:Permit access to static storage objects from signal
handlers if synchronization is guaranteed by use of the signal mask
Description: 
While the recent C standard (ISO 9899:2011) additionally allows for using
the newly introduced lock-free atomic types inside signal handlers, access
to static storage duration objects of types other then those provided as
lock-free atomics remains undefined.

Notably following access pattern, often employed in interrupt handlers,
remains undefined: Access to objects that are only referenced inside an
interrupt handler or while said interrupt is masked, are
"async-interrupt-safe".

I believe that with the concurrency model introduced in C11, these kind of
accesses could be defined. This would allow for use of the aforementioned
interrupt access pattern in conjunction with UNIX signals, which after all,
were modeled after interrupts.
Desired Action: 
Amending the section with something along the lines of:

"Inside signal handlers, access to objects with static storage duration and
of arbitrary type is permitted if and only if all accesses to the object,
inside or outside the signal handler, occur while said signal handler is
blocked from execution."

This would be coupled with making modification of the signal mask imply a
barrier.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2017-02-23 02:38 a3fNew Issue
2017-02-23 02:38 a3fStatus   New => Under Review 
2017-02-23 02:38 a3fAssigned To   => ajosey  
2017-02-23 02:38 a3fName  => Ahmad Fatoum
2017-02-23 02:38 a3fSection   => 2.4.3 Signal
Actions
2017-02-23 02:38 a3fPage Number   => 493 
2017-02-23 02:38 a3fLine Number   => 16839-16842 
==

[1003.1(2008)/Issue 7 0001119]: When the file named by the operand does not exist, `file` should not exit with zero status

[Austin Group Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://austingroupbugs.net/view.php?id=1119 
== 
Reported By:mhjacobson
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   1119
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Objection
Priority:   normal
Status: Under Review
Name:   Matt Jacobson 
Organization:
User Reference:  
Section:file 
Page Number:0 
Line Number:0 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2017-02-15 01:48 UTC
Last Modified:  2017-02-15 01:48 UTC
== 
Summary:When the file named by the  operand does not
exist, `file` should not exit with zero status
Description: 
$ file /this/does/not/exist
/this/does/not/exist: cannot open `/this/does/not/exist' (No such file or
directory)
$ echo $?
0

This is apparently conformant, but it is nonsensical and divergent from the
specification for `ls`, `cat`, etc.
Desired Action: 
`file` should exit with nonzero status when the file named by the 
parameter cannot be found.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2017-02-15 01:48 mhjacobson New Issue
2017-02-15 01:48 mhjacobson Status   New => Under Review 
2017-02-15 01:48 mhjacobson Assigned To   => ajosey  
2017-02-15 01:48 mhjacobson Name  => Matt Jacobson   
2017-02-15 01:48 mhjacobson Section   => file
2017-02-15 01:48 mhjacobson Page Number   => 0   
2017-02-15 01:48 mhjacobson Line Number   => 0   
==

[1003.1(2013)/Issue7+TC1 0001031]: Add -iname (case-insensitive name search) to the find utility.

[Austin Group Bug Tracker]

The following issue has been RESOLVED. 
== 
http://austingroupbugs.net/view.php?id=1031 
== 
Reported By:dannyniu
Assigned To:
== 
Project:1003.1(2013)/Issue7+TC1
Issue ID:   1031
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Editorial
Priority:   normal
Status: Resolved
Name:   DannyNiu/NJF 
Organization:
User Reference:  
Section:The 'find' utility.  
Page Number:2761-2770 
Line Number:90443-90860 
Interp Status:  --- 
Final Accepted Text:http://austingroupbugs.net/view.php?id=1031#c3559 
Resolution: Accepted As Marked
Fixed in Version:   
== 
Date Submitted: 2016-03-07 03:21 UTC
Last Modified:  2017-02-16 16:34 UTC
== 
Summary:Add -iname (case-insensitive name search) to the
find utility.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-03-07 03:21 dannyniu   New Issue
2016-03-07 03:21 dannyniu   Name  => DannyNiu/NJF
2016-03-07 03:21 dannyniu   Section   => The 'find' utility.

2016-03-07 03:21 dannyniu   Page Number   => 2761-2770   
2016-03-07 03:21 dannyniu   Line Number   => 90443-90860 
2016-03-07 12:09 stephane   Note Added: 0003090  
2016-03-07 12:53 schwarze   Note Added: 0003091  
2017-02-16 16:33 geoffclare Note Added: 0003559  
2017-02-16 16:34 geoffclare Interp Status => --- 
2017-02-16 16:34 geoffclare Final Accepted Text   =>
http://austingroupbugs.net/view.php?id=1031#c3559
2017-02-16 16:34 geoffclare Status   New => Resolved 
2017-02-16 16:34 geoffclare Resolution   Open => Accepted As
Marked
==

[1003.1(2013)/Issue7+TC1 0001015]: Handling of inside a (double-quoted) backquote command substitution

[Austin Group Bug Tracker]

The following issue has been UPDATED. 
== 
http://austingroupbugs.net/view.php?id=1015 
== 
Reported By:mirabilos
Assigned To:
== 
Project:1003.1(2013)/Issue7+TC1
Issue ID:   1015
Category:   Shell and Utilities
Type:   Clarification Requested
Severity:   Editorial
Priority:   normal
Status: Interpretation Required
Name:   mirabilos 
Organization:   The MirOS Project 
User Reference:
http://article.gmane.org/gmane.comp.standards.posix.austin.general/11817 
Section:2.6.3 
Page Number:   
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_03

Line Number:third paragraph 
Interp Status:  Approved 
Final Accepted Text:http://austingroupbugs.net/view.php?id=1015#c3445 
== 
Date Submitted: 2015-12-28 12:36 UTC
Last Modified:  2017-01-18 15:23 UTC
== 
Summary:Handling of  inside a
(double-quoted) backquote command substitution
== 

-- 
 (0003548) ajosey (manager) - 2017-01-18 15:23
 http://austingroupbugs.net/view.php?id=1015#c3548 
-- 
Interpretation Approved: 18 Jan 2017 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-12-28 12:36 mirabilos  New Issue
2015-12-28 12:36 mirabilos  Name  => mirabilos   
2015-12-28 12:36 mirabilos  Organization  => The MirOS Project
2015-12-28 12:36 mirabilos  User Reference=>
http://article.gmane.org/gmane.comp.standards.posix.austin.general/11817
2015-12-28 12:36 mirabilos  Section   => 2.6.3   
2015-12-28 12:36 mirabilos  Page Number   =>
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_03
2015-12-28 12:36 mirabilos  Line Number   => third paragraph 
2016-01-15 14:40 mirabilos  Note Added: 0003024  
2016-02-25 11:14 kreNote Added: 0003086  
2016-02-25 11:34 kreNote Edited: 0003086 
2016-03-01 18:59 mirabilos  Note Added: 0003088  
2016-03-22 04:38 kreNote Added: 0003096  
2016-10-14 12:00 joerg  Note Added: 0003415  
2016-10-14 12:00 joerg  Note Edited: 0003415 
2016-10-14 12:03 joerg  Note Edited: 0003415 
2016-10-15 19:39 chet_ramey Note Added: 0003418  
2016-10-20 15:47 geoffclare Note Added: 0003445  
2016-10-20 15:48 geoffclare Interp Status => Pending 
2016-10-20 15:48 geoffclare Final Accepted Text   =>
http://austingroupbugs.net/view.php?id=1015#c3445
2016-10-20 15:48 geoffclare Status   New => Interpretation
Required
2016-10-20 15:48 geoffclare Resolution   Open => Accepted As
Marked
2016-10-20 15:48 geoffclare Tag Attached: tc3-2008   
2016-10-20 16:30 geoffclare Note Edited: 0003445 
2016-12-15 18:10 ajosey Interp StatusPending => Proposed 
2016-12-15 18:10 ajosey Note Added: 0003519  
2017-01-18 15:23 ajosey Interp StatusProposed => Approved
2017-01-18 15:23 ajosey Note Added: 0003548  
==

[1003.1(2013)/Issue7+TC1 0000974]: several issues with awk's ARGC/ARGV

[Austin Group Bug Tracker]

The following issue has been UPDATED. 
== 
http://austingroupbugs.net/view.php?id=974 
== 
Reported By:stephane
Assigned To:
== 
Project:1003.1(2013)/Issue7+TC1
Issue ID:   974
Category:   Shell and Utilities
Type:   Error
Severity:   Editorial
Priority:   normal
Status: Interpretation Required
Name:   Stephane Chazelas 
Organization:
User Reference:  
Section:awk 
Page Number:2460 
Line Number:78773-78782 
Interp Status:  Approved 
Final Accepted Text:See http://austingroupbugs.net/view.php?id=974#c3231

== 
Date Submitted: 2015-08-10 11:09 UTC
Last Modified:  2017-01-18 15:24 UTC
== 
Summary:several issues with awk's ARGC/ARGV
== 

-- 
 (0003551) ajosey (manager) - 2017-01-18 15:24
 http://austingroupbugs.net/view.php?id=974#c3551 
-- 
Interpretation Approved: 18 Jan 2017 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-08-10 11:09 stephane   New Issue
2015-08-10 11:09 stephane   Name  => Stephane Chazelas
2015-08-10 11:09 stephane   Section   => awk 
2015-08-10 11:09 stephane   Page Number   => 2460
2015-08-10 11:09 stephane   Line Number   => 78773-78782 
2015-08-10 13:53 geoffclare Note Added: 0002787  
2015-08-10 16:02 stephane   Note Added: 0002788  
2016-05-19 16:31 rhansenNote Added: 0003231  
2016-05-19 16:35 rhansenNote Edited: 0003231 
2016-05-19 16:38 rhansenNote Edited: 0003231 
2016-05-19 16:39 rhansenNote Edited: 0003231 
2016-05-19 16:43 rhansenNote Edited: 0003231 
2016-05-19 16:44 rhansenInterp Status => Pending 
2016-05-19 16:44 rhansenFinal Accepted Text   => See
http://austingroupbugs.net/view.php?id=974#c3231
2016-05-19 16:44 rhansenStatus   New => Interpretation
Required
2016-05-19 16:44 rhansenResolution   Open => Accepted As
Marked
2016-05-19 16:44 rhansenTag Attached: tc3-2008   
2016-12-15 18:11 ajosey Interp StatusPending => Proposed 
2016-12-15 18:11 ajosey Note Added: 0003523  
2017-01-18 15:24 ajosey Interp StatusProposed => Approved
2017-01-18 15:24 ajosey Note Added: 0003551  
==

[1003.1(2013)/Issue7+TC1 0000956]: Documentation unification regarding PAGER

[Austin Group Bug Tracker]

The following issue has been UPDATED. 
== 
http://austingroupbugs.net/view.php?id=956 
== 
Reported By:steffen
Assigned To:
== 
Project:1003.1(2013)/Issue7+TC1
Issue ID:   956
Category:   Shell and Utilities
Type:   Omission
Severity:   Editorial
Priority:   normal
Status: Interpretation Required
Name:   Steffen Nurpmeso 
Organization:
User Reference:  
Section:XCU, mailx 
Page Number:2923 
Line Number:96322-96324, 96592-96594, 96598-96600 
Interp Status:  Approved 
Final Accepted Text:see http://austingroupbugs.net/view.php?id=956#c3094

== 
Date Submitted: 2015-06-10 15:46 UTC
Last Modified:  2017-01-18 15:25 UTC
== 
Summary:Documentation unification regarding PAGER
== 

-- 
 (0003552) ajosey (manager) - 2017-01-18 15:25
 http://austingroupbugs.net/view.php?id=956#c3552 
-- 
Interpretation Approved: 18 Jan 2017 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-06-10 15:46 steffenNew Issue
2015-06-10 15:46 steffenName  => Steffen Nurpmeso
2015-06-10 15:46 steffenSection   => XCU, mailx  
2015-06-10 15:46 steffenPage Number   => 2923
2015-06-10 15:46 steffenLine Number   => 96322-96324,
96592-96594, 96598-96600
2015-06-10 15:49 steffenNote Added: 0002703  
2016-03-10 17:27 rhansenNote Added: 0003094  
2016-03-10 17:29 rhansenInterp Status => Pending 
2016-03-10 17:29 rhansenFinal Accepted Text   => see
http://austingroupbugs.net/view.php?id=956#c3094
2016-03-10 17:29 rhansenStatus   New => Interpretation
Required
2016-03-10 17:29 rhansenResolution   Open => Accepted As
Marked
2016-03-10 17:30 rhansenTag Attached: tc3-2008   
2016-03-10 17:36 shware_systems Note Added: 0003095  
2016-03-10 17:50 Don Cragun Note Edited: 0003095 
2016-03-10 17:51 Don Cragun Note Edited: 0003095 
2016-03-10 17:52 Don Cragun Note Edited: 0003095 
2016-03-10 18:55 shware_systems Note Edited: 0003095 
2016-12-15 18:12 ajosey Interp StatusPending => Proposed 
2016-12-15 18:12 ajosey Note Added: 0003524  
2017-01-18 15:25 ajosey Interp StatusProposed => Approved
2017-01-18 15:25 ajosey Note Added: 0003552  
==

[1003.1(2013)/Issue7+TC1 0001024]: chmod() should be allowed to ignore S_ISVTX

[Austin Group Bug Tracker]

The following issue has been UPDATED. 
== 
http://austingroupbugs.net/view.php?id=1024 
== 
Reported By:Clausecker
Assigned To:
== 
Project:1003.1(2013)/Issue7+TC1
Issue ID:   1024
Category:   System Interfaces
Type:   Omission
Severity:   Objection
Priority:   normal
Status: Interpretation Required
Name:   Robert Clausecker 
Organization:   Fraunhofer FOKUS 
User Reference:  
Section:chmod() 
Page Number:660 
Line Number:22352–22353 
Interp Status:  Approved 
Final Accepted Text:http://austingroupbugs.net/view.php?id=1024#c3506 
== 
Date Submitted: 2016-01-26 20:31 UTC
Last Modified:  2017-01-18 15:22 UTC
== 
Summary:chmod() should be allowed to ignore S_ISVTX
== 

-- 
 (0003545) ajosey (manager) - 2017-01-18 15:22
 http://austingroupbugs.net/view.php?id=1024#c3545 
-- 
Interpretation Approved: 18 Jan 2017 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-01-26 20:31 Clausecker New Issue
2016-01-26 20:31 Clausecker Name  => Robert Clausecker
2016-01-26 20:31 Clausecker Organization  => Fraunhofer FOKUS
2016-01-26 20:31 Clausecker Section   => chmod() 
2016-01-26 20:31 Clausecker Page Number   => 660 
2016-01-26 20:31 Clausecker Line Number   => 22352–22353   
2016-01-27 15:51 shware_systems Note Added: 0003032  
2016-01-27 16:10 joerg  Note Added: 0003033  
2016-01-27 16:20 shware_systems Note Added: 0003034  
2016-01-27 16:35 joerg  Note Added: 0003035  
2016-01-27 16:36 joerg  Note Edited: 0003035 
2016-01-27 16:39 geoffclare Note Added: 0003036  
2016-01-27 16:40 geoffclare Note Edited: 0003036 
2016-01-27 17:14 shware_systems Note Added: 0003037  
2016-01-27 17:26 joerg  Note Added: 0003038  
2016-01-27 17:40 Clausecker Note Added: 0003039  
2016-01-27 18:05 schwarze   Note Added: 0003040  
2016-01-27 18:10 joerg  Note Added: 0003041  
2016-01-27 18:15 Clausecker Note Added: 0003042  
2016-01-27 21:11 shware_systems Note Added: 0003043  
2016-01-27 21:17 schwarze   Note Added: 0003044  
2016-01-27 23:25 philip-guentherNote Added: 0003045  
2016-01-27 23:56 dickey Note Added: 0003046  
2016-01-27 23:58 dickey Note Added: 0003047  
2016-01-28 11:22 joerg  Note Added: 0003048  
2016-01-28 11:23 joerg  Note Edited: 0003048 
2016-01-28 11:24 joerg  Note Edited: 0003048 
2016-01-28 11:26 joerg  Note Edited: 0003048 
2016-01-28 11:26 joerg  Note Edited: 0003048 
2016-01-28 19:00 shware_systems Note Added: 0003055  
2016-01-28 19:05 Clausecker Note Added: 0003056  
2016-11-17 17:37 Don Cragun Note Added: 0003495  
2016-11-17 21:24 GarrettWollman Note Added: 0003497  
2016-11-17 22:20 Don Cragun Note Added: 0003498  
2016-11-17 23:06 GarrettWollman Note Added: 0003499  
2016-12-01 16:19 geoffclare Note Added: 0003506  
2016-12-01 16:21 geoffclare Interp Status => Pending 
2016-12-01 16:21 geoffclare Final Accepted Text   =>
http://austingroupbugs.net/view.php?id=1024#c3506
2016-12-01 16:21 geoffclare Note Added: 0003507  
2016-12-01 16:21 geoffclare Status   New => 

[1003.1(2013)/Issue7+TC1 0000985]: quote removal missing from case statement patterns and alternative expansions

[Austin Group Bug Tracker]

The following issue has been UPDATED. 
== 
http://austingroupbugs.net/view.php?id=985 
== 
Reported By:rhansen
Assigned To:
== 
Project:1003.1(2013)/Issue7+TC1
Issue ID:   985
Category:   Shell and Utilities
Type:   Omission
Severity:   Objection
Priority:   normal
Status: Interpretation Required
Name:   Richard hansen 
Organization:   BBN 
User Reference:  
Section:2.6.2, 2.9.4.3 
Page Number:2328, 2345 
Line Number:73944-73945, 74602-74603 
Interp Status:  Approved 
Final Accepted Text:http://austingroupbugs.net/view.php?id=985#c2885 
== 
Date Submitted: 2015-09-17 19:22 UTC
Last Modified:  2017-01-18 15:24 UTC
== 
Summary:quote removal missing from case statement patterns
and alternative expansions
==
Relationships   ID  Summary
--
related to  221 poor wording about even quotes in doubl...
related to  249 Add standard support for $'...' in shell
== 

-- 
 (0003550) ajosey (manager) - 2017-01-18 15:24
 http://austingroupbugs.net/view.php?id=985#c3550 
-- 
Interpretation Approved: 18 Jan 2017 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-09-17 19:22 rhansenNew Issue
2015-09-17 19:22 rhansenName  => Richard hansen  
2015-09-17 19:22 rhansenOrganization  => BBN 
2015-09-17 19:22 rhansenSection   => 2.6.2, 2.9.4.3  
2015-09-17 19:22 rhansenPage Number   => 2328, 2345  
2015-09-17 19:22 rhansenLine Number   => 73944-73945,
74602-74603
2015-09-17 19:22 rhansenInterp Status => --- 
2015-09-17 19:23 rhansenDesired Action Updated   
2015-09-17 19:24 rhansenDesired Action Updated   
2015-09-18 08:34 geoffclare Relationship added   related to 221  
2015-09-18 08:39 geoffclare Note Added: 0002835  
2015-09-18 20:08 shware_systems Note Added: 0002839  
2015-09-18 20:18 shware_systems Note Edited: 0002839 
2015-10-01 18:29 rhansenNote Added: 0002852  
2015-10-02 08:45 geoffclare Note Added: 0002853  
2015-10-02 17:13 rhansenNote Added: 0002855  
2015-10-03 00:57 shware_systems Note Added: 0002856  
2015-10-04 07:52 geoffclare Note Added: 0002858  
2015-10-08 16:14 rhansenNote Added: 0002863  
2015-10-08 16:31 rhansenNote Added: 0002864  
2015-10-08 16:40 geoffclare Note Added: 0002865  
2015-10-08 16:41 rhansenRelationship added   related to 249  
2015-10-08 20:39 shware_systems Note Added: 0002866  
2015-10-15 15:55 geoffclare Note Edited: 0002863 
2015-10-15 15:56 geoffclare Note Edited: 0002865 
2015-10-15 15:59 geoffclare Note Added: 0002876  
2015-10-15 16:00 geoffclare Interp Status--- => Pending  
2015-10-15 16:00 geoffclare Final Accepted Text   => bugnote:2876
2015-10-15 16:00 geoffclare Status   New => Interpretation
Required
2015-10-15 16:00 geoffclare Resolution   Open => Accepted As
Marked
2015-10-15 16:01 geoffclare Tag Attached: tc3-2008   
2015-11-05 17:09 rhansenFinal Accepted Text  bugnote:2876 => 
2015-11-05 17:09 rhansenNote Added: 0002884  
2015-11-05 17:09 rhansenStatus   Interpretation Required
=> New
2015-11-05 17:09 rhansenResolution   Accepted As Marked =>
Open
2015-11-05 17:17 

[1003.1(2013)/Issue7+TC1 0001023]: Behaviour of ls -R without -a under presence of directories beginning with a dot

[Austin Group Bug Tracker]

The following issue has been UPDATED. 
== 
http://austingroupbugs.net/view.php?id=1023 
== 
Reported By:Clausecker
Assigned To:
== 
Project:1003.1(2013)/Issue7+TC1
Issue ID:   1023
Category:   Shell and Utilities
Type:   Clarification Requested
Severity:   Editorial
Priority:   normal
Status: Interpretation Required
Name:   Robert Clausecker 
Organization:
User Reference:  
Section:ls 
Page Number:2888–2897 
Line Number:95140–95557 
Interp Status:  Approved 
Final Accepted Text:See
http://austingroupbugs.net/view.php?id=1023#c3494. 
== 
Date Submitted: 2016-01-11 18:55 UTC
Last Modified:  2017-01-18 15:22 UTC
== 
Summary:Behaviour of ls -R without -a under presence of
directories beginning with a dot
== 

-- 
 (0003546) ajosey (manager) - 2017-01-18 15:22
 http://austingroupbugs.net/view.php?id=1023#c3546 
-- 
Interpretation Approved: 18 Jan 2017 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-01-11 18:55 Clausecker New Issue
2016-01-11 18:55 Clausecker Name  => Robert Clausecker
2016-01-11 18:55 Clausecker Section   => ls  
2016-01-11 18:55 Clausecker Page Number   => 2888–2897 
2016-01-11 18:55 Clausecker Line Number   => 95140–95557   
2016-11-17 16:55 Don Cragun Note Added: 0003494  
2016-11-17 16:56 Don Cragun Interp Status => Pending 
2016-11-17 16:56 Don Cragun Final Accepted Text   => See
http://austingroupbugs.net/view.php?id=1023#c3494.
2016-11-17 16:56 Don Cragun Status   New => Interpretation
Required
2016-11-17 16:56 Don Cragun Resolution   Open => Accepted As
Marked
2016-11-17 16:56 Don Cragun Tag Attached: issue8 
2016-12-15 18:08 ajosey Interp StatusPending => Proposed 
2016-12-15 18:08 ajosey Note Added: 0003516  
2017-01-18 15:22 ajosey Interp StatusProposed => Approved
2017-01-18 15:22 ajosey Note Added: 0003546  
==

[1003.1(2013)/Issue7+TC1 0000953]: Alias expansion is under-specified

[Austin Group Bug Tracker]

The following issue has been UPDATED. 
== 
http://austingroupbugs.net/view.php?id=953 
== 
Reported By:wpollock
Assigned To:ajosey
== 
Project:1003.1(2013)/Issue7+TC1
Issue ID:   953
Category:   Shell and Utilities
Type:   Clarification Requested
Severity:   Objection
Priority:   normal
Status: Interpretation Required
Name:   Wayne Pollock 
Organization:
User Reference:  
Section:2.3.1 Alias Substitution 
Page Number:2322 
Line Number:73690-73705 
Interp Status:  Approved 
Final Accepted Text:See http://austingroupbugs.net/view.php?id=953#c3113

== 
Date Submitted: 2015-06-04 00:22 UTC
Last Modified:  2017-01-18 15:25 UTC
== 
Summary:Alias expansion is under-specified
==
Relationships   ID  Summary
--
related to  736 grammatically accept zero or more Shell...
related to  0001048 deprecate alias and unalias
related to  0001055 unspecified how much is parsed before e...
== 

-- 
 (0003553) ajosey (manager) - 2017-01-18 15:25
 http://austingroupbugs.net/view.php?id=953#c3553 
-- 
Interpretation Approved: 18 Jan 2017 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-06-04 00:22 wpollock   New Issue
2015-06-04 00:22 wpollock   Status   New => Under Review 
2015-06-04 00:22 wpollock   Assigned To   => ajosey  
2015-06-04 00:22 wpollock   Name  => Wayne Pollock   
2015-06-04 00:22 wpollock   Section   => 2.3.1 Alias
Substitution
2015-06-04 09:26 joerg  Note Added: 0002694  
2016-02-04 17:01 Don Cragun Page Number   => 2322
2016-02-04 17:01 Don Cragun Line Number   => 73690-73705 
2016-02-04 17:01 Don Cragun Interp Status => --- 
2016-02-04 17:04 Don Cragun Project  1003.1(2008)/Issue 7 =>
1003.1(2013)/Issue7+TC1
2016-03-04 09:49 joerg  Note Added: 0003089  
2016-03-04 09:50 joerg  Note Edited: 0003089 
2016-03-04 11:39 joerg  Note Edited: 0003089 
2016-03-04 11:40 joerg  Note Edited: 0003089 
2016-03-04 15:11 joerg  Note Edited: 0003089 
2016-03-31 16:29 rhansenNote Added: 0003113  
2016-03-31 16:30 rhansenNote Edited: 0003113 
2016-03-31 16:32 nick   Note Edited: 0003113 
2016-03-31 16:33 nick   Interp Status--- => Pending  
2016-03-31 16:33 nick   Final Accepted Text   => See bugnote: 3113
2016-03-31 16:33 nick   Status   Under Review =>
Interpretation Required
2016-03-31 16:33 nick   Resolution   Open => Accepted As
Marked
2016-03-31 16:33 nick   Final Accepted Text  See bugnote: 3113 =>
See http://austingroupbugs.net/view.php?id=953#c3113
2016-03-31 16:33 nick   Note Edited: 0003113 
2016-03-31 16:34 nick   Tag Attached: tc3-2008   
2016-03-31 16:34 rhansenNote Edited: 0003113 
2016-03-31 16:40 rhansenNote Edited: 0003113 
2016-04-01 12:29 ajosey Interp StatusPending => Proposed 
2016-04-01 12:29 ajosey Note Added: 0003116  
2016-04-10 22:09 jilles Note Added: 0003148  
2016-04-11 14:31 chet_ramey Note Added: 0003149  
2016-04-11 20:59 shware_systems Note Added: 0003150  
2016-04-12 08:58 joerg  Note Added: 0003151  
2016-04-12 12:58 chet_ramey Note Added: 0003152  

[1003.1(2013)/Issue7+TC1 0001016]: race condition with set -C

[Austin Group Bug Tracker]

The following issue has been UPDATED. 
== 
http://austingroupbugs.net/view.php?id=1016 
== 
Reported By:izabera
Assigned To:
== 
Project:1003.1(2013)/Issue7+TC1
Issue ID:   1016
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Editorial
Priority:   normal
Status: Interpretation Required
Name:   Isabella 
Organization:   --- 
User Reference: --- 
Section:2.7.2 
Page Number:   
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_07_02

Line Number:last paragraph 
Interp Status:  Approved 
Final Accepted Text:http://austingroupbugs.net/view.php?id=1016#c3493 
== 
Date Submitted: 2015-12-28 13:52 UTC
Last Modified:  2017-01-18 15:25 UTC
== 
Summary:race condition with set -C
== 

-- 
 (0003554) ajosey (manager) - 2017-01-18 15:25
 http://austingroupbugs.net/view.php?id=1016#c3554 
-- 
Interpretation Approved: 18 Jan 2017 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-12-28 13:52 izaberaNew Issue
2015-12-28 13:52 izaberaName  => Isabella
2015-12-28 13:52 izaberaOrganization  => --- 
2015-12-28 13:52 izaberaUser Reference=> --- 
2015-12-28 13:52 izaberaSection   => 2.7.2   
2015-12-28 13:52 izaberaPage Number   =>
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_07_02
2015-12-28 13:52 izaberaLine Number   => last paragraph  
2015-12-31 05:58 shware_systems Note Added: 0002990  
2015-12-31 12:52 jilles Note Added: 0002991  
2015-12-31 14:21 shware_systems Note Added: 0002992  
2015-12-31 17:05 nick   Interp Status => --- 
2015-12-31 17:05 nick   Note Added: 0002993  
2015-12-31 17:05 nick   Description Updated  
2016-10-20 16:40 geoffclare Note Added: 0003446  
2016-10-31 16:23 geoffclare Note Added: 0003481  
2016-10-31 16:28 geoffclare Note Edited: 0003481 
2016-10-31 16:33 geoffclare Note Edited: 0003481 
2016-11-10 17:33 rhansenNote Added: 0003485  
2016-11-10 17:36 rhansenNote Edited: 0003485 
2016-11-10 17:37 rhansenNote Edited: 0003485 
2016-11-11 15:24 rhansenNote Edited: 0003485 
2016-11-11 15:25 rhansenNote Edited: 0003485 
2016-11-11 15:27 rhansenNote Edited: 0003485 
2016-11-11 15:29 rhansenNote Edited: 0003485 
2016-11-11 15:29 rhansenNote Edited: 0003485 
2016-11-11 15:30 rhansenNote Edited: 0003485 
2016-11-11 21:26 stephane   Note Added: 0003486  
2016-11-12 13:43 stephane   Note Edited: 0003486 
2016-11-14 07:01 shware_systems Note Added: 0003487  
2016-11-14 09:30 geoffclare Note Added: 0003488  
2016-11-14 10:10 stephane   Note Added: 0003489  
2016-11-14 10:28 stephane   Note Added: 0003490  
2016-11-14 10:47 geoffclare Note Added: 0003491  
2016-11-14 15:55 shware_systems Note Added: 0003492  
2016-11-14 16:17 shware_systems Note Edited: 0003492 
2016-11-17 16:18 geoffclare Note Added: 0003493  
2016-11-17 16:20 geoffclare Interp Status--- => Pending  
2016-11-17 16:20 geoffclare Final Accepted Text   => bugnote:4393
2016-11-17 16:20 geoffclare Status   New 

[1003.1(2013)/Issue7+TC1 0001006]: PS1 should be subject to command substitution and arithmetic expansion

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1006 
== 
Reported By:rhansen
Assigned To:
== 
Project:1003.1(2013)/Issue7+TC1
Issue ID:   1006
Category:   Shell and Utilities
Type:   Omission
Severity:   Editorial
Priority:   normal
Status: Interpretation Required
Name:   Richard Hansen 
Organization:   BBN 
User Reference:  
Section:2.5.3 PS1 
Page Number:2326 
Line Number:73833 
Interp Status:  Proposed 
Final Accepted Text:http://austingroupbugs.net/view.php?id=1006#c3310 
== 
Date Submitted: 2015-11-13 08:23 UTC
Last Modified:  2017-01-19 16:28 UTC
== 
Summary:PS1 should be subject to command substitution and
arithmetic expansion
==
Relationships   ID  Summary
--
related to  0001038 Specification relies upon unspecified b...
== 

-- 
 (0003556) geoffclare (manager) - 2017-01-19 16:28
 http://austingroupbugs.net/view.php?id=1006#c3556 
-- 
http://austingroupbugs.net/view.php?id=1006#c3310 has been edited to implement
the change suggested in
http://austingroupbugs.net/view.php?id=1006#c3339 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-11-13 08:23 rhansenNew Issue
2015-11-13 08:23 rhansenName  => Richard Hansen  
2015-11-13 08:23 rhansenOrganization  => BBN 
2015-11-13 08:23 rhansenSection   => 2.5.3 PS1   
2015-11-13 08:23 rhansenPage Number   => 2326
2015-11-13 08:23 rhansenLine Number   => 73833   
2015-11-13 08:23 rhansenInterp Status => --- 
2015-11-13 10:34 joerg  Note Added: 0002906  
2015-11-13 13:51 kreNote Added: 0002907  
2015-11-13 15:44 random832  Note Added: 0002909  
2015-11-13 16:04 random832  Note Edited: 0002909 
2015-11-13 16:11 geoffclare Note Added: 0002911  
2015-11-13 16:33 shware_systems Note Added: 0002913  
2015-11-13 16:36 random832  Note Added: 0002914  
2015-11-13 16:40 random832  Note Edited: 0002914 
2015-11-13 16:47 random832  Note Edited: 0002914 
2015-11-13 16:49 random832  Note Edited: 0002914 
2015-11-13 16:49 random832  Note Edited: 0002914 
2015-11-13 18:21 kreNote Added: 0002918  
2015-11-13 18:29 kreNote Added: 0002919  
2015-11-13 18:31 random832  Note Added: 0002920  
2015-11-14 01:39 rhansenNote Added: 0002932  
2015-11-14 01:40 rhansenNote Added: 0002933  
2015-11-14 01:41 rhansenNote Edited: 0002933 
2015-11-14 01:44 rhansenNote Edited: 0002933 
2015-11-14 01:50 rhansenNote Added: 0002934  
2015-11-14 10:06 geoffclare Note Added: 0002939  
2015-11-14 13:43 kreNote Added: 0002940  
2015-11-14 13:49 kreNote Edited: 0002940 
2015-11-14 14:01 random832  Note Added: 0002941  
2015-11-14 17:26 shware_systems Note Added: 0002944  
2015-11-14 17:27 shware_systems Note Edited: 0002944 
2015-11-14 21:03 random832  Note Added: 0002945  
2015-11-14 21:04 random832  Note Edited: 0002945 
2015-11-15 03:26 rhansenNote Added: 0002946  
2015-11-15 03:43 rhansenNote Edited: 

[1003.1(2016)/Issue7+TC2 0001117]: Use of "implementation-defined" in command -v / -V

[Austin Group Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://austingroupbugs.net/view.php?id=1117 
== 
Reported By:geoffclare
Assigned To:
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1117
Category:   Shell and Utilities
Type:   Clarification Requested
Severity:   Comment
Priority:   normal
Status: New
Name:   Geoff Clare 
Organization:   The Open Group 
User Reference:  
Section:command 
Page Number:2596 
Line Number:84278, 84294 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2017-01-20 10:03 UTC
Last Modified:  2017-01-20 10:03 UTC
== 
Summary:Use of "implementation-defined" in command -v / -V
Description: 
The -v and -V options for "command" include the text "and any
implementation-defined functions that are found using the PATH
variable (as described in Section 2.9.1.1, on page 2367)".

I suspect this is intended just to mean "functions defined by the
implementation", but by using the defined term "implementation-defined"
the text introduces a documentation requirement.  This is not the
appropriate place to make such a requirement - if we want the functions
found by PATH to be documented, 2.9.1.1 is the place to require it,
not here.

Desired Action: 
For both -v and -V, change:

and any implementation-defined functions that are found using the PATH
variable

to:

and any implementation-provided functions that are found using the PATH
variable

== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2017-01-20 10:03 geoffclare New Issue
2017-01-20 10:03 geoffclare Name  => Geoff Clare 
2017-01-20 10:03 geoffclare Organization  => The Open Group  
2017-01-20 10:03 geoffclare Section   => command 
2017-01-20 10:03 geoffclare Page Number   => 2596
2017-01-20 10:03 geoffclare Line Number   => 84278, 84294
2017-01-20 10:03 geoffclare Interp Status => --- 
==

[1003.1(2016)/Issue7+TC2 0001122]: POSIX should include gettext() and friends

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1122 
== 
Reported By:joerg
Assigned To:
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1122
Category:   System Interfaces
Type:   Enhancement Request
Severity:   Editorial
Priority:   normal
Status: New
Name:   Jörg Schilling 
Organization:
User Reference:  
Section:3 + 4 
Page Number:1102...and others 
Line Number:somewhere in section 3 and 4 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2017-02-28 16:51 UTC
Last Modified:  2017-03-01 22:37 UTC
== 
Summary:POSIX should include gettext() and friends
== 

-- 
 (0003581) steffen (reporter) - 2017-03-01 22:37
 http://austingroupbugs.net/view.php?id=1122#c3581 
-- 
Hm, with charset agnostic i referred to the fact that the "char const
*MSGID", the message itself, is used as the key of the message, so this is
just a NUL terminated byte stream; which is then either mapped to a
different byte stream that has been loaded from a LC_MESSAGES dependent
database file, or can simply be returned "as-is".

Too much time has passed, i cannot say anything to the actual plain text
input format of .po files, without rereading all the available information
that is.

 |TW: the main problem with catgets() is that it needs a globally
maintained message number.

I agree.  It is in practice unmaintainable unless you have software which
generates the MESSAGE-NUMBER = STRING mappings in an automated way.  POSIX
does not include such software, and it is, also in practice, not as easy as
it seems to write such a software, let alone portably, since strings can
come from preprocessor expansions, spread across several lines, ..
whatever.

 |This problem may however be circumvented by avoiding english texts
 | that may have more than one meaning, by either using better wording
 | or by adding more text to differentiate and by translating the long
 | english text into the short and ambiguous english text.

The usual way is normally to put a specially crafted comment on the line
before the string is defined, something like

  colour.c: /* I18N: ..of colour mapping */
  colour.c- n_err(_("`colour': %s: invalid precondition: %s\n"),

or

  send.c:  /* I18N: Filename input prompt with file type indication */
  send.c-  str_concat_csvl(, _("Enter filename for part "),

Most others use "L10N:" instead, however, for "localization".

And iconv(3) on the fly so that a german LATIN1 message catalog can be used
in a german UTF-8 locale thus seems to be common.  I think conversion
errors should be ignored in, hopefully uncommon, translator-error cases. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2017-02-28 16:51 joerg  New Issue
2017-02-28 16:51 joerg  Name  => Jörg Schilling 
2017-02-28 16:51 joerg  Section   => 3 + 4   
2017-02-28 16:51 joerg  Page Number   => 1102...and others
2017-02-28 16:51 joerg  Line Number   => somewhere in
section 3 and 4
2017-03-01 16:05 steffenNote Added: 0003575  
2017-03-01 16:54 shware_systems Note Added: 0003576  
2017-03-01 17:10 joerg  Note Added: 0003577  
2017-03-01 17:10 joerg  Note Edited: 0003577 
2017-03-01 17:11 steffenNote Added: 0003578  
2017-03-01 17:13 steffenNote Added: 0003579  
2017-03-01 17:23 joerg  Note Added: 0003580  
2017-03-01 17:27 joerg  Note Edited: 0003580 
2017-03-01 18:09 joerg  Note Edited: 0003580 
2017-03-01 22:37 steffenNote Added: 0003581  
==

[1003.1(2016)/Issue7+TC2 0001122]: POSIX should include gettext() and friends

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1122 
== 
Reported By:joerg
Assigned To:
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1122
Category:   System Interfaces
Type:   Enhancement Request
Severity:   Editorial
Priority:   normal
Status: New
Name:   Jörg Schilling 
Organization:
User Reference:  
Section:3 + 4 
Page Number:1102...and others 
Line Number:somewhere in section 3 and 4 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2017-02-28 16:51 UTC
Last Modified:  2017-03-01 16:05 UTC
== 
Summary:POSIX should include gettext() and friends
== 

-- 
 (0003575) steffen (reporter) - 2017-03-01 16:05
 http://austingroupbugs.net/view.php?id=1122#c3575 
-- 
I posted on the ML (which does no longer include a sequence number, the
resent-message-id was "dhdJXC.A.-oG.z8rtYB"@Phoebe.vpn.opengroup.org), a
superset of what follows:

  [..]it definitely must be possible to implement this as a macro,
  that is to say.  And possibly GETTEXT() should at least be
  reserved, just in case ISO C does not go that route, so that
  GETTEXT(target-store, msgid) can be a #define with do{}while(0).[..]

This is because implementations of gettext() (-alike interfaces) have been
seen, or may still exist, which avoid successive, and therefore practically
always unnecessary database lookups by injecting code into compilation
units (e.g., a modification-counter reference and a character pointer, both
"static", to be initialized first, and only comparing the reference against
the database-specific counter). 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2017-02-28 16:51 joerg  New Issue
2017-02-28 16:51 joerg  Name  => Jörg Schilling 
2017-02-28 16:51 joerg  Section   => 3 + 4   
2017-02-28 16:51 joerg  Page Number   => 1102...and others
2017-02-28 16:51 joerg  Line Number   => somewhere in
section 3 and 4
2017-03-01 16:05 steffenNote Added: 0003575  
==

[1003.1(2016)/Issue7+TC2 0001122]: POSIX should include gettext() and friends

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1122 
== 
Reported By:joerg
Assigned To:
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1122
Category:   System Interfaces
Type:   Enhancement Request
Severity:   Editorial
Priority:   normal
Status: New
Name:   Jörg Schilling 
Organization:
User Reference:  
Section:3 + 4 
Page Number:1102...and others 
Line Number:somewhere in section 3 and 4 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2017-02-28 16:51 UTC
Last Modified:  2017-03-02 09:40 UTC
== 
Summary:POSIX should include gettext() and friends
== 

-- 
 (0003584) keld (reporter) - 2017-03-02 09:40
 http://austingroupbugs.net/view.php?id=1122#c3584 
-- 
I agree that gettext and friends should be added. It is a much more used
set of APIs than catgets(), indeed most of the GUIs in Linux, like KDE and
Gnome are built with gettext(), and also POSIX shell utilities.


I would then like to see the APIs specified in a thread-safe version. 

Is there text which we can use as a base for normative wording in POSIX? 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2017-02-28 16:51 joerg  New Issue
2017-02-28 16:51 joerg  Name  => Jörg Schilling 
2017-02-28 16:51 joerg  Section   => 3 + 4   
2017-02-28 16:51 joerg  Page Number   => 1102...and others
2017-02-28 16:51 joerg  Line Number   => somewhere in
section 3 and 4
2017-03-01 16:05 steffenNote Added: 0003575  
2017-03-01 16:54 shware_systems Note Added: 0003576  
2017-03-01 17:10 joerg  Note Added: 0003577  
2017-03-01 17:10 joerg  Note Edited: 0003577 
2017-03-01 17:11 steffenNote Added: 0003578  
2017-03-01 17:13 steffenNote Added: 0003579  
2017-03-01 17:23 joerg  Note Added: 0003580  
2017-03-01 17:27 joerg  Note Edited: 0003580 
2017-03-01 18:09 joerg  Note Edited: 0003580 
2017-03-01 22:37 steffenNote Added: 0003581  
2017-03-02 06:39 shware_systems Note Added: 0003582  
2017-03-02 09:09 joerg  Note Added: 0003583  
2017-03-02 09:40 keld   Note Added: 0003584  
==

[1003.1(2016)/Issue7+TC2 0001122]: POSIX should include gettext() and friends

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1122 
== 
Reported By:joerg
Assigned To:
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1122
Category:   System Interfaces
Type:   Enhancement Request
Severity:   Editorial
Priority:   normal
Status: New
Name:   Jörg Schilling 
Organization:
User Reference:  
Section:3 + 4 
Page Number:1102...and others 
Line Number:somewhere in section 3 and 4 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2017-02-28 16:51 UTC
Last Modified:  2017-03-02 09:09 UTC
== 
Summary:POSIX should include gettext() and friends
== 

-- 
 (0003583) joerg (reporter) - 2017-03-02 09:09
 http://austingroupbugs.net/view.php?id=1122#c3583 
-- 
Re http://austingroupbugs.net/view.php?id=1122#c3581
SCO used catgets() in their Svr4 product and managed the numbers for
catgets()
manually in include files. I know this because I wrote the ISO-9660:1999
and 
Joliet drivers for SCO and needed to enhance the mount program.

I am not sure whether a user of catgets wrote an automated mapping
program.

The problem with the ambiguous english language cannot be circumvented
by comments in the source code as long as there are two or more identical
strings intended to mean something different. 

Once you manages to have different strings for different meaning, you
could add such special commands and GNU xgettext has an option to tell
it to transfer such a comment into thr .po file.

If you provide a English -> English .po file for your program, you may
handle the problem with non-7-Bit-ASCII texts in case you use the 
encoding tags in the  .po file.

Here is a sample .po file with the typical mime based hints that
are encoded into the .mo file:

# SOME DESCRIPTIVE TITLE.
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the PACKAGE package.
# FIRST AUTHOR , YEAR.
#
#, afuzzy
msgid ""
msgstr "Project-Id-Version: BLA 9.99\n"
"Report-Msgid-Bugs-To: me@\n"
"POT-Creation-Date: 2010-12-19 22:23+0100\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME \n"
"Language-Team: LANGUAGE \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=iso-8859-1\n"
"Content-Transfer-Encoding: 8bit\n"

#: cdrecord.c:319
#, c-format
msgid "This is an evaluation version of cdrecord,\n"
msgstr "Dies ist eine Beurteilungsversion von cdrecord\n"
...

The fact that mime is used here allows to add more enhancements
in the future. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2017-02-28 16:51 joerg  New Issue
2017-02-28 16:51 joerg  Name  => Jörg Schilling 
2017-02-28 16:51 joerg  Section   => 3 + 4   
2017-02-28 16:51 joerg  Page Number   => 1102...and others
2017-02-28 16:51 joerg  Line Number   => somewhere in
section 3 and 4
2017-03-01 16:05 steffenNote Added: 0003575  
2017-03-01 16:54 shware_systems Note Added: 0003576  
2017-03-01 17:10 joerg  Note Added: 0003577  
2017-03-01 17:10 joerg  Note Edited: 0003577 
2017-03-01 17:11 steffenNote Added: 0003578  
2017-03-01 17:13 steffenNote Added: 0003579  
2017-03-01 17:23 joerg  Note Added: 0003580  
2017-03-01 17:27 joerg  Note Edited: 0003580 
2017-03-01 18:09 joerg  Note Edited: 0003580 
2017-03-01 22:37 steffenNote Added: 0003581  
2017-03-02 06:39 shware_systems Note Added: 0003582  
2017-03-02 09:09 joerg  Note Added: 0003583  
==

[1003.1(2016)/Issue7+TC2 0001122]: POSIX should include gettext() and friends

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1122 
== 
Reported By:joerg
Assigned To:
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1122
Category:   System Interfaces
Type:   Enhancement Request
Severity:   Editorial
Priority:   normal
Status: New
Name:   Jörg Schilling 
Organization:
User Reference:  
Section:3 + 4 
Page Number:1102...and others 
Line Number:somewhere in section 3 and 4 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2017-02-28 16:51 UTC
Last Modified:  2017-03-01 17:10 UTC
== 
Summary:POSIX should include gettext() and friends
== 

-- 
 (0003577) joerg (reporter) - 2017-03-01 17:10
 http://austingroupbugs.net/view.php?id=1122#c3577 
-- 
Why do you believe that gettext() is obsolete?

Why do you believe that gettext() relies in non-conforming GNU
extensions()

gettext() was designed by Sun Microsystems in the 1980s and I see no
problems with it. 

There are a few GNU enhancements that are worth ti be included but these
extensions still are not non-conforming. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2017-02-28 16:51 joerg  New Issue
2017-02-28 16:51 joerg  Name  => Jörg Schilling 
2017-02-28 16:51 joerg  Section   => 3 + 4   
2017-02-28 16:51 joerg  Page Number   => 1102...and others
2017-02-28 16:51 joerg  Line Number   => somewhere in
section 3 and 4
2017-03-01 16:05 steffenNote Added: 0003575  
2017-03-01 16:54 shware_systems Note Added: 0003576  
2017-03-01 17:10 joerg  Note Added: 0003577  
==

[1003.1(2016)/Issue7+TC2 0001122]: POSIX should include gettext() and friends

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1122 
== 
Reported By:joerg
Assigned To:
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1122
Category:   System Interfaces
Type:   Enhancement Request
Severity:   Editorial
Priority:   normal
Status: New
Name:   Jörg Schilling 
Organization:
User Reference:  
Section:3 + 4 
Page Number:1102...and others 
Line Number:somewhere in section 3 and 4 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2017-02-28 16:51 UTC
Last Modified:  2017-03-01 17:11 UTC
== 
Summary:POSIX should include gettext() and friends
== 

-- 
 (0003578) steffen (reporter) - 2017-03-01 17:11
 http://austingroupbugs.net/view.php?id=1122#c3578 
-- 
No, you may feel the desire to turn gettext() into a Waldorf Astoria, but i
am afraid you will neither be able to close its doors for renovation, nor
turn it into a set of nice Unicode luxury apartments: because gettext() is
the actual workhorse of internationalisation in Unix C programs, and
charset agnostic.  Compare this with catgets(), which is simply not used in
any software that i know, except old and practically unmaintained codebases
that still use it, but are asleep development-wise, except maybe for
adjusting slightly to avoid the bitrot that modern compilers, well, not
reveal, but rather generate.  Ah, and the ISO C standard committee is not
to be forrotten. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2017-02-28 16:51 joerg  New Issue
2017-02-28 16:51 joerg  Name  => Jörg Schilling 
2017-02-28 16:51 joerg  Section   => 3 + 4   
2017-02-28 16:51 joerg  Page Number   => 1102...and others
2017-02-28 16:51 joerg  Line Number   => somewhere in
section 3 and 4
2017-03-01 16:05 steffenNote Added: 0003575  
2017-03-01 16:54 shware_systems Note Added: 0003576  
2017-03-01 17:10 joerg  Note Added: 0003577  
2017-03-01 17:10 joerg  Note Edited: 0003577 
2017-03-01 17:11 steffenNote Added: 0003578  
==

[1003.1(2016)/Issue7+TC2 0001122]: POSIX should include gettext() and friends

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1122 
== 
Reported By:joerg
Assigned To:
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1122
Category:   System Interfaces
Type:   Enhancement Request
Severity:   Editorial
Priority:   normal
Status: New
Name:   Jörg Schilling 
Organization:
User Reference:  
Section:3 + 4 
Page Number:1102...and others 
Line Number:somewhere in section 3 and 4 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2017-02-28 16:51 UTC
Last Modified:  2017-03-01 16:54 UTC
== 
Summary:POSIX should include gettext() and friends
== 

-- 
 (0003576) shware_systems (reporter) - 2017-03-01 16:54
 http://austingroupbugs.net/view.php?id=1122#c3576 
-- 
While this looks obvious, certainly, catgets() and gettext() both are
already obsolete, in terms of thoroughness, since before C99 came out. The
gettext package's utilities rely on GNU extensions that make them
non-conforming anyways, so isn't suitable to replace cat*() to begin with.
Gettext is usable for a variety of languages, but it's still a subset of
the languages currently in use. Both models, as compiler and implementation
extensions, leave as application-defined aspects of language translation
Unicode addresses in a more systematic fashion. Unicode also has known
omissions, noted on their to do lists, but not as many. I believe this was
touched upon in rejecting Bug 861, which also mentions gettext. 

Imo, Issue 8 should include something, and I have a tentative design in
mind (that includes Bug 861), but addressing this completely is part of
Phase 3 or later, to account for how POSIX adds the Unicode requirements,
so this can be part of a POSIX Option Group. I consider forward usability,
as the final design implemented will be invention, as more important than
backwards compatibility. Only a bulk conversion utility for msg and po
files, and Win mc sources as a cross platform consideration, is planned for
upgrading current applications. Source code and cat/mo file conversions I
consider compiler and platform dependent, as does the standard, and overly
impractical to automate. An application using gettext or catgets now won't
have to upgrade, but those that choose to refactor their source files will
stand a much better chance of being certified as Conforming with
Extensions. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2017-02-28 16:51 joerg  New Issue
2017-02-28 16:51 joerg  Name  => Jörg Schilling 
2017-02-28 16:51 joerg  Section   => 3 + 4   
2017-02-28 16:51 joerg  Page Number   => 1102...and others
2017-02-28 16:51 joerg  Line Number   => somewhere in
section 3 and 4
2017-03-01 16:05 steffenNote Added: 0003575  
2017-03-01 16:54 shware_systems Note Added: 0003576  
==

[1003.1(2016)/Issue7+TC2 0001122]: POSIX should include gettext() and friends

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1122 
== 
Reported By:joerg
Assigned To:
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1122
Category:   System Interfaces
Type:   Enhancement Request
Severity:   Editorial
Priority:   normal
Status: New
Name:   Jörg Schilling 
Organization:
User Reference:  
Section:3 + 4 
Page Number:1102...and others 
Line Number:somewhere in section 3 and 4 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2017-02-28 16:51 UTC
Last Modified:  2017-03-02 09:56 UTC
== 
Summary:POSIX should include gettext() and friends
== 

-- 
 (0003585) keld (reporter) - 2017-03-02 09:56
 http://austingroupbugs.net/view.php?id=1122#c3585 
-- 
In gettext, there are easy ways to differentiate between different meanings
of the same text string, and there are practices established for that. An
easy way is to mark the msgid with a tag and explain this tag in an
accompanying comment, and then translate the string into the target
language (which may be English, even if the msgid is in English too).

There is Unicode support in gettext, indeed most corpora is in Unicode. It
is mostly UTF-8. I believe you can also use UTF-16 and others, you just
decalre this in the header of the .po-file.

I am puzzled to hear that gettext should not support r2l languages
sufficiently. Myriads of programs are translated in adequate ways for
Arabic and Hebrew languages. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2017-02-28 16:51 joerg  New Issue
2017-02-28 16:51 joerg  Name  => Jörg Schilling 
2017-02-28 16:51 joerg  Section   => 3 + 4   
2017-02-28 16:51 joerg  Page Number   => 1102...and others
2017-02-28 16:51 joerg  Line Number   => somewhere in
section 3 and 4
2017-03-01 16:05 steffenNote Added: 0003575  
2017-03-01 16:54 shware_systems Note Added: 0003576  
2017-03-01 17:10 joerg  Note Added: 0003577  
2017-03-01 17:10 joerg  Note Edited: 0003577 
2017-03-01 17:11 steffenNote Added: 0003578  
2017-03-01 17:13 steffenNote Added: 0003579  
2017-03-01 17:23 joerg  Note Added: 0003580  
2017-03-01 17:27 joerg  Note Edited: 0003580 
2017-03-01 18:09 joerg  Note Edited: 0003580 
2017-03-01 22:37 steffenNote Added: 0003581  
2017-03-02 06:39 shware_systems Note Added: 0003582  
2017-03-02 09:09 joerg  Note Added: 0003583  
2017-03-02 09:40 keld   Note Added: 0003584  
2017-03-02 09:56 keld   Note Added: 0003585  
==

[1003.1(2013)/Issue7+TC1 0001070]: Collation issues in XCU (changes for Issue 8)

[Austin Group Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://austingroupbugs.net/view.php?id=1070 
== 
Reported By:geoffclare
Assigned To:
== 
Project:1003.1(2013)/Issue7+TC1
Issue ID:   1070
Category:   Shell and Utilities
Type:   Error
Severity:   Objection
Priority:   normal
Status: New
Name:   Geoff Clare 
Organization:   The Open Group 
User Reference:  
Section:2.13.3, awk, comm, localedef, ls, sort, uniq 
Page Number:2356, 2459, 2559, 2874, 2888, 3210, 3309, and more 
Line Number:75082, 78745, 82755, 94650, 95164, 107544, 111067,
and more 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2016-08-25 11:11 UTC
Last Modified:  2016-08-25 11:11 UTC
== 
Summary:Collation issues in XCU (changes for Issue 8)
Description: 
A discussion on the mailing list identified some issues related to
collation for locales that do not define a collation sequence with
a total ordering of all characters.  It is proposed that these issues
are addressed in Issue 8 by requiring implementation-provided locales
that do not have an '@' modifier in their name to define a collation
sequence that has a total ordering of all characters (thus reducing
the problem to "special" locales and user-defined locales), and by
modifying the requirements for regular expressions and affected
utilities so that they cope better with such locales.  As an
intermediate step, it is proposed that the new requirements slated
for Issue 8 are recommended (or at least allowed) in TC2.

The necessary changes will be split across four Mantis bugs, targeting
XBD TC2, XCU TC2, XBD Issue 8, and XCU Issue 8.  This bug contains the
changes proposed for XCU in Issue 8.

Desired Action: 
After applying the bug http://austingroupbugs.net/view.php?id=963 changes at
each of the following
locations, make further changes to the new text as noted below.
(There is also a change to localedef inserted among the changes
derived from bug 963.)

On Page: 2356 Line: 75082 Section: 2.13.3 Patterns Used for Filename
Expansion

In the updated list item 3, change from:

any filenames or pathnames that collate equally should be further compared
byte-by-byte using the collating sequence for the POSIX locale.

to:

any filenames or pathnames that collate equally shall be further compared
byte-by-byte using the collating sequence for the POSIX locale.

and delete the small-font note:

Note: a future version of this standard may require the byte-by-byte
further comparison described above.

On Page: 2459 Line: 78745 Section: awk

In the updated text, change from:

For the "!=" and "==" operators, the strings should be compared to check if
they are identical but may be compared using the locale-specific collation
sequence to check if they collate equally.

to:

For the "!=" and "==" operators, the strings shall be compared to check if
they are identical (not to check if they collate equally).

On Page: 2478 Line: 79587 Section: awk

Change the two new APPLICATION USAGE paragraphs from:

On implementations where the "==" operator checks if strings collate
equally, applications needing to check whether strings are identical can
use:length(a) == length(b) && index(a,b) ==
1On implementations where the "==" operator checks if
strings are identical, applications needing to check whether strings
collate equally can use:a <= b && a >=
bto:

Since the "==" operator checks whether strings are identical, not whether
they collate equally, applications needing to check whether strings
collate equally can use:a <= b && a >=
b
On Page: 2486 Line: 79914 Section: awk

Change the updated FUTURE DIRECTIONS section from:

A future version of this standard may require the "!=" and "==" operators
to perform string comparisons by checking if the strings are identical (and
not by checking if they collate equally).

to:

None.

On Page: 2559 Line: 82755 Section: comm

Change the new DESCRIPTION paragraph from:

If the collating sequence of the current locale does not have a total
ordering of all characters (see [xref to XBD 7.3.2]) and any lines from the
input files collate equally but are not identical, comm should treat
them as different lines but may treat them as being the same.  If it treats
them as different, comm should expect them to be ordered according
to a further byte-by-byte comparison using the collating sequence for the
POSIX locale and if they 

[1003.1(2013)/Issue7+TC1 0001070]: Collation issues in XCU (changes for Issue 8)

[Austin Group Bug Tracker]

The following issue has been set as RELATED TO issue 963. 
== 
http://austingroupbugs.net/view.php?id=1070 
== 
Reported By:geoffclare
Assigned To:
== 
Project:1003.1(2013)/Issue7+TC1
Issue ID:   1070
Category:   Shell and Utilities
Type:   Error
Severity:   Objection
Priority:   normal
Status: New
Name:   Geoff Clare 
Organization:   The Open Group 
User Reference:  
Section:2.13.3, awk, comm, localedef, ls, sort, uniq 
Page Number:2356, 2459, 2559, 2874, 2888, 3210, 3309, and more 
Line Number:75082, 78745, 82755, 94650, 95164, 107544, 111067,
and more 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2016-08-25 11:11 UTC
Last Modified:  2016-08-25 11:11 UTC
== 
Summary:Collation issues in XCU (changes for Issue 8)
==
Relationships   ID  Summary
--
related to  963 Collation issues in XCU (changes for TC2)
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-08-25 11:11 geoffclare New Issue
2016-08-25 11:11 geoffclare Name  => Geoff Clare 
2016-08-25 11:11 geoffclare Organization  => The Open Group  
2016-08-25 11:11 geoffclare Section   => 2.13.3, awk, comm,
localedef, ls, sort, uniq
2016-08-25 11:11 geoffclare Page Number   => 2356, 2459, 2559,
2874, 2888, 3210, 3309, and more
2016-08-25 11:11 geoffclare Line Number   => 75082, 78745,
82755, 94650, 95164, 107544, 111067, and more
2016-08-25 11:11 geoffclare Interp Status => --- 
2016-08-25 11:11 geoffclare Relationship added   related to 963  
==

[1003.1(2013)/Issue7+TC1 0000963]: Collation issues in XCU (changes for TC2)

[Austin Group Bug Tracker]

The following issue has been set as RELATED TO issue 0001070. 
== 
http://austingroupbugs.net/view.php?id=963 
== 
Reported By:geoffclare
Assigned To:
== 
Project:1003.1(2013)/Issue7+TC1
Issue ID:   963
Category:   Shell and Utilities
Type:   Error
Severity:   Objection
Priority:   normal
Status: Resolved
Name:   Geoff Clare 
Organization:   The Open Group 
User Reference:  
Section:2.13.3, awk, comm, expr, join, ls, sort, uniq 
Page Number:2356, 2459, 2559, 2740, 2839, 2888, 3210, 3309, and
more 
Line Number:75082, 78745, 82755, 89708, 93278, 95164, 107544,
111067, and more 
Interp Status:  --- 
Final Accepted Text: 
Resolution: Accepted
Fixed in Version:   
== 
Date Submitted: 2015-06-24 11:07 UTC
Last Modified:  2015-07-30 15:20 UTC
== 
Summary:Collation issues in XCU (changes for TC2)
==
Relationships   ID  Summary
--
related to  938 Collation issues in XBD (changes for TC2)
related to  948 Collation issues in XBD (changes for Is...
related to  0001070 Collation issues in XCU (changes for Is...
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-06-24 11:07 geoffclare New Issue
2015-06-24 11:07 geoffclare Name  => Geoff Clare 
2015-06-24 11:07 geoffclare Organization  => The Open Group  
2015-06-24 11:07 geoffclare Section   => 2.13.3, awk, comm,
expr, join, ls, sort, uniq
2015-06-24 11:07 geoffclare Page Number   => 2356, 2459, 2559,
2740, 2839, 2888, 3210, 3309, and more
2015-06-24 11:07 geoffclare Line Number   => 75082, 78745,
82755, 89708, 93278, 95164, 107544, 111067, and more
2015-06-24 11:07 geoffclare Interp Status => --- 
2015-06-24 15:24 geoffclare Relationship added   related to 938  
2015-07-30 15:20 Don Cragun Status   New => Resolved 
2015-07-30 15:20 Don Cragun Resolution   Open => Accepted
2015-07-30 15:20 Don Cragun Desired Action Updated   
2015-07-30 15:20 Don Cragun Tag Attached: tc2-2008   
2015-07-30 17:05 rhansenTag Attached: UTF-8_Locale
2016-02-04 16:18 nick   Relationship added   related to 948  
2016-08-25 11:11 geoffclare Relationship added   related to 0001070  
==

[1003.1(2013)/Issue7+TC1 0001074]: _SC_POSIX_THREAD

[Austin Group Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://austingroupbugs.net/view.php?id=1074 
== 
Reported By:dsabogal
Assigned To:
== 
Project:1003.1(2013)/Issue7+TC1
Issue ID:   1074
Category:   Base Definitions and Headers
Type:   Error
Severity:   Editorial
Priority:   normal
Status: New
Name:   Daniel Sabogal 
Organization:
User Reference:  
Section: 
Page Number:442 
Line Number:14937,14943 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2016-09-04 17:51 UTC
Last Modified:  2016-09-04 17:51 UTC
== 
Summary:_SC_POSIX_THREAD
Description: 
The descriptions for _CS_POSIX_V7_THREADS_CFLAGS and
_CS_POSIX_V7_THREADS_LDFLAGS begin with:
"If sysconf(_SC_POSIX_THREADS) returns -1, ..."

The identifier _SC_POSIX_THREADS is not mentioned elsewhere in the
standard.

I believe the intended constant here was _SC_THREADS.
See page 445 line 15096, page 2078 line 66346, and page 2517 line 81166-7.

However, sysconf(_SC_THREADS) always evaluates to 200809L since:
- Page 17 line 559 requires _POSIX_THREADS to have this value, and
- The RETURN VALUE section of sysconf() on page 2079 requires the value of
this variable to be returned.

It seem that the statements in question should be removed.
Desired Action: 
Remove lines 14937 and 14943.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-09-04 17:51 dsabogal   New Issue
2016-09-04 17:51 dsabogal   Name  => Daniel Sabogal  
2016-09-04 17:51 dsabogal   Section   =>   
2016-09-04 17:51 dsabogal   Page Number   => 442 
2016-09-04 17:51 dsabogal   Line Number   => 14937,14943 
==

[1003.1(2013)/Issue7+TC1 0001074]: _SC_POSIX_THREAD

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1074 
== 
Reported By:dsabogal
Assigned To:
== 
Project:1003.1(2013)/Issue7+TC1
Issue ID:   1074
Category:   Base Definitions and Headers
Type:   Error
Severity:   Editorial
Priority:   normal
Status: New
Name:   Daniel Sabogal 
Organization:
User Reference:  
Section: 
Page Number:442 
Line Number:14937,14943 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2016-09-04 17:51 UTC
Last Modified:  2016-09-04 20:10 UTC
== 
Summary:_SC_POSIX_THREAD
== 

-- 
 (0003374) shware_systems (reporter) - 2016-09-04 20:10
 http://austingroupbugs.net/view.php?id=1074#c3374 
-- 
Yes, the intended constant is _SC_THREADS, per the table of equivalencies
in sysconf(). While Issue 7 requires sysconf() to return 200809L, prior
editions and subprofiles (see XRAT E.0) might return -1, or a constant
related to that particular version. So the phrasing is ok, but "POSIX_"
should be deleted in those lines. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-09-04 17:51 dsabogal   New Issue
2016-09-04 17:51 dsabogal   Name  => Daniel Sabogal  
2016-09-04 17:51 dsabogal   Section   =>   
2016-09-04 17:51 dsabogal   Page Number   => 442 
2016-09-04 17:51 dsabogal   Line Number   => 14937,14943 
2016-09-04 20:10 shware_systems Note Added: 0003374  
==

[1003.1(2013)/Issue7+TC1 0001076]: Cancellation Points

[Austin Group Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://austingroupbugs.net/view.php?id=1076 
== 
Reported By:torvald
Assigned To:
== 
Project:1003.1(2013)/Issue7+TC1
Issue ID:   1076
Category:   Base Definitions and Headers
Type:   Enhancement Request
Severity:   Comment
Priority:   normal
Status: New
Name:   Torvald Riegel 
Organization:   Red Hat 
User Reference:  
Section:Cancellation Points 
Page Number:1 
Line Number:1 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2016-09-09 16:12 UTC
Last Modified:  2016-09-09 16:12 UTC
== 
Summary:Cancellation Points
Description: 
sem_wait is currently part of the "shall occur" list.  This is suboptimal:

(1) It adds overhead to the fast paths of any semaphore implementation (ie,
checking for cancellation, which will likely at least require touching an
additional cache line).

(2) It creates an inconsistency with sem_trywait semantics in that
sem_trywait isn't really a "subset" of sem_wait anymore.  Something like
"if (sem_trywait(...) != 0) sem_wait(...);" kills cancellation.  To be
consistent wrt cancellation, sem_trywait would have to be a cancellation
point too.

(3) Because the implementation is allowed to decide between cancellation
and success when a cancellation request races with unblocking *during* the
execution of sem_wait, the POSIX requirement that sem_wait should be a
cancellation point regardless of whether it blocks is only exploitable by
programs that enforce that the cancellation request is issued before
sem_wait is called.  This requires active synchronization, and thus the
program would already have been able to check whether it should continue to
compute or stop. Thus, using this reliably doesn't add functionality that
the program wouldn't be able to implement otherwise.
Desired Action: 
I think that the description of when cancellation requests have to be acted
upon could be improved.  Without reading the rationale ("Thread
Cancellation Overview", esp. first paragraph of "Cancellation Points"
bullet), it's hard to see that the "may" vs. "shall" lists also allow for
different treatment of the sem_wait issue I described (eg,
pthread_rwlock_rdlock implementations don't need to check).

It seems the cleanest specification of cancellation would be to say that a
function that is considered to have a cancellation point will eventually
act upon a cancellation request, provided that it is blocked.

This adds the forward progress requirement for acting upon a cancellation
request (ie, the "eventually"), and avoids the weasel-wording in the last
sentences of the section (ie, timeouts and when event and cancellation
request happen without enforced ordering).  It also avoids having to check
for cancellation in functions that don't block (which will always affect
fast-paths), yet prevents a thread from being blocked indefinitely.  It
would not make "shall occur" functions points that can be interrupted
regardless of whether the thread actually makes progress or not.

Whether a particular function is in the "shall" or "may" camp seems pretty
arbitrary (at least, arguably, different programs would benefit from
different functions being in "shall" vs. "may").  Therefore, cancellation
seems more useful as a mechanism for preventing indefinite blocking (ie,
only cancel if blocked) instead of having even deferred cancellation be
something like unconditional interruption at functions arbitrarily
considered safe points (ie, functions in which cancellation points "shall
occur").
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-09-09 16:12 torvaldNew Issue
2016-09-09 16:12 torvaldName  => Torvald Riegel  
2016-09-09 16:12 torvaldOrganization  => Red Hat 
2016-09-09 16:12 torvaldSection   => Cancellation Points
2016-09-09 16:12 torvaldPage Number   => 1   
2016-09-09 16:12 torvaldLine Number   => 1   
==

[1003.1(2013)/Issue7+TC1 0001077]: Recommend support for wide-character regcomp and regexec and/or specify multi-byte behavior

[Austin Group Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://austingroupbugs.net/view.php?id=1077 
== 
Reported By:deadpixi
Assigned To:
== 
Project:1003.1(2013)/Issue7+TC1
Issue ID:   1077
Category:   System Interfaces
Type:   Enhancement Request
Severity:   Editorial
Priority:   normal
Status: New
Name:   Rob King 
Organization:
User Reference:  
Section:regcomp 
Page Number:- 
Line Number:- 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2016-09-11 17:47 UTC
Last Modified:  2016-09-11 17:47 UTC
== 
Summary:Recommend support for wide-character regcomp and
regexec and/or specify multi-byte behavior
Description: 
The existing mandated regular expression interfaces are specified to work
solely on regular expressions and inputs that are specified using
single-byte character strings. The standard is silent on what the regular
expression functions should do if either the regular expression or the
input contains multi-byte encoded characters in the current (or any)
multi-byte encoding.

This makes it impossible to rely on the regular expression interfaces in a
portable manner, as their behavior is unspecified with multi-byte
characters.

For example, in UTF-8 encoding, a regular expression containing a single
logical code point might encode that code point as four individual bytes.
If this encoding were used in, e.g., a regular expression character class a
naive implementation that expected each character to take up a single byte
would treat each individual byte as a character to be matched in the
character class, and not as a single character.
Desired Action: 
The Standard should specify behavior of the regular expression interfaces
when the expression to be compiled or the input to be matched contains
multi-byte characters in the current character encoding.

Alternatively (and perhaps preferably), the Standard should specify
additional wide-character regular expression interfaces (perhaps named
regwcomp and regwexec) to perform regular expression compilation and
matching on expressions and inputs specified using wide characters; this
would avoid any issue with multi-byte encoding.

The specification of the additional wide-character interfaces would likely
not be too burdensome: the GNU C library (when compiled with RE_ENABLE_I18N
defined) already represents regular expressions and the input as wide
characters internally. The Mac OS X standard library supports the
"regwcomp" and "regwexec" interfaces. A free, portable, well-licensed, and
popular implementation (libtre) exists and has been incorporated into
several popular C libraries (musl, Darwin's libc, etc).
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-09-11 17:47 deadpixi   New Issue
2016-09-11 17:47 deadpixi   Name  => Rob King
2016-09-11 17:47 deadpixi   Section   => regcomp 
2016-09-11 17:47 deadpixi   Page Number   => -   
2016-09-11 17:47 deadpixi   Line Number   => -   
==

[1003.1(2013)/Issue7+TC1 0001075]: The unset utility's NAME section mentions values and attributes, but the DESCRIPTION doesn't mention attributes.

[Austin Group Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://austingroupbugs.net/view.php?id=1075 
== 
Reported By:Don Cragun
Assigned To:
== 
Project:1003.1(2013)/Issue7+TC1
Issue ID:   1075
Category:   Shell and Utilities
Type:   Omission
Severity:   Objection
Priority:   normal
Status: New
Name:   Donald Cragun 
Organization:   Self 
User Reference:  
Section:2.14 Special Built-in Utilities -- unset 
Page Number:2395 
Line Number:76338-76355 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2016-09-08 20:08 UTC
Last Modified:  2016-09-08 20:08 UTC
== 
Summary:The unset utility's NAME section mentions values and
attributes, but the DESCRIPTION doesn't mention attributes.
Description: 
The unset special built-in utility's NAME section is:
unset — unset values and attributes of variables and
functions
and traditional implementations of unset do indeed unset variables
and remove the export attribute from variables that are unset.  But the
DESCRIPTION, OPTIONS, OPERANDS, EXTENDED DESCRIPTION, APPLICATION USAGE,
EXAMPLE, and RATIONALE sections do not mention attributes.

The standard does not provide any mechanism to export a function definition
nor to make a function definition read-only, but the function definition
command rationale mentions that some shells allow functions to be exported
as an extension.
Desired Action: 
On P 2395, L76342 (1st paragraph of unset DESCRIPTION section) change:
Each variable or function specified by name shall be
unset.
to:
The unset utility shall unset each variable or function
definition specified by name and unset any attributes that have been
given to name (see section 2.14 export and readonly).
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-09-08 20:08 Don Cragun New Issue
2016-09-08 20:08 Don Cragun Name  => Donald Cragun   
2016-09-08 20:08 Don Cragun Organization  => Self
2016-09-08 20:08 Don Cragun Section   => 2.14 Special
Built-in Utilities -- unset
2016-09-08 20:08 Don Cragun Page Number   => 2395
2016-09-08 20:08 Don Cragun Line Number   => 76338-76355 
2016-09-08 20:08 Don Cragun Interp Status => --- 
==

[1003.1(2008)/Issue 7 0001079]: focus on bc being an arithmetic language

[Austin Group Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://austingroupbugs.net/view.php?id=1079 
== 
Reported By:tobiasm
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   1079
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Editorial
Priority:   normal
Status: Under Review
Name:   Tobias Martens 
Organization:
User Reference:  
Section:bc 
Page Number:- 
Line Number:- 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2016-10-05 23:40 UTC
Last Modified:  2016-10-05 23:40 UTC
== 
Summary:focus on bc being an arithmetic language
Description: 
Due to the specified precedence of operators in bc, where unary - is higher
than ^ (exponentiation operator), the result of

-(1+1)^2

will be 4, unlike any other calculator or arithmetic language I have
encountered. I see the advantage this may have, for example (since bc often
takes external input) when piping variable to bc in shell:

var=-2
echo "${var}^2" | bc

will result in 4, which may seem intuitive and mathematical to someone who
is not aware of how shell processes the string. Personally, while I
encourage allowing a intuitive approach, this shall not influence common
arithmetic as given by the example above. 
Moreover, the apparent advantage is destroyed by a simple subtraction:

echo "3-${var}" | bc

produces a syntax error (in GNU bc 1.06.95), likely due to the
specification of ++ and -- (unary increment and decrement). Note how the
same command works for the corresponding addition.
Again, other arithmetic languages will compute the expression 3--2
correctly to 5, only bc, sticking with programming languages' syntax and
behaviour, will not be able to do so.

Let me conclude with how bc is called in the specification:
"bc - arbitrary-precision arithmetic language"
Desired Action: 
First I want to invite you to discuss a shift of bc to a more arithmetic
language (in the common sense) with me, occurring problems and
possibilities.

In my opinion, the following actions would move bc to a arithmetic language
as known from calculators and other arithmetic languages all over the
world:

-switch precedence of unary - and ^. 

-remove unary increment and decrement. 
This may sound drastic, but those operators are shortcut programming
syntax, not arithemtic. There is no need for these shortcuts in bc because
they aren't used nearly as often as in programming languages. They are
redundant and only add unnecessary complexity and confusion when simple
subtractions fail.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-10-05 23:40 tobiasmNew Issue
2016-10-05 23:40 tobiasmStatus   New => Under Review 
2016-10-05 23:40 tobiasmAssigned To   => ajosey  
2016-10-05 23:40 tobiasmName  => Tobias Martens  
2016-10-05 23:40 tobiasmSection   => bc  
2016-10-05 23:40 tobiasmPage Number   => -   
2016-10-05 23:40 tobiasmLine Number   => -   
==

[1003.1(2008)/Issue 7 0001079]: focus on bc being an arithmetic language

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1079 
== 
Reported By:tobiasm
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   1079
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Editorial
Priority:   normal
Status: Under Review
Name:   Tobias Martens 
Organization:
User Reference:  
Section:bc 
Page Number:- 
Line Number:- 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2016-10-05 23:40 UTC
Last Modified:  2016-10-06 10:19 UTC
== 
Summary:focus on bc being an arithmetic language
== 

-- 
 (0003397) stephane (reporter) - 2016-10-06 10:19
 http://austingroupbugs.net/view.php?id=1079#c3397 
-- 
bc's behaviour is consistent with that of zsh/bash/ksh arithmetic operators
or TCL's expr:


$ bash -c 'echo $((-(1+1)**2))'
4
$ ksh -c 'echo $((-(1+1)**2))'
4
$ zsh -c 'echo $((-(1+1)**2))'
4
$ expect -c 'puts [expr -(1+1) ** 2]'
4


I beleive among shells, ** was first added in zsh (circa 1994). Initially
it had the same precedence as */% (though was right-associative) and that
was changed shortly after to have a higher precedence.

Note that bc was initially a wrapper around dc (and still is on some
systems), that uses reverse polish notation, where there's no negation
unary operator, but negative constants are entered as _4. That
pseudo-negation-operator possibly contributed to the unary negation
operator being seen as having the highest precendence among Unix users.


$ echo '_2 2 ^ p' | dc
4


(The unary negation would be 0r- in dc.)


$ echo '2 0r- 2 ^ p' | dc
4


"expr" is another utility that doesn't have a "-" unary operator (but you
can enter negative constants as "-2"). It doesn't have an exponentiation
operator but that's another Unix utility that reenforces the fact that
unary - has highest precedence.

I personally find awk/perl/python's behaviour of -2 ^ 2 returning -4
unintuitive. Even worse for ** (perl/python) that is shaped similarly to *
(which has a much lower precedence than unary -), that is where it's really
a binary operator, not an affix. In zsh it used to have the same

Shell arithmetics have the same issue with "-" and "+" conflicting with
"--" and "++" (whose support the spec explicitely allows but not mandate).
That was discussed recently on the mailing list about $((-x)) not being the
same as $((-$x)) (and the former being prefered as a result).

In anycase, IMO, a standard can't break backward compatibility in such a
dramatic way. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-10-05 23:40 tobiasmNew Issue
2016-10-05 23:40 tobiasmStatus   New => Under Review 
2016-10-05 23:40 tobiasmAssigned To   => ajosey  
2016-10-05 23:40 tobiasmName  => Tobias Martens  
2016-10-05 23:40 tobiasmSection   => bc  
2016-10-05 23:40 tobiasmPage Number   => -   
2016-10-05 23:40 tobiasmLine Number   => -   
2016-10-06 07:41 Vincent LefevreNote Added: 0003395  
2016-10-06 07:41 Vincent LefevreNote Edited: 0003395 
2016-10-06 07:42 Vincent LefevreNote Edited: 0003395 
2016-10-06 08:02 Vincent LefevreNote Edited: 0003395 
2016-10-06 08:09 Vincent LefevreNote Added: 0003396  
2016-10-06 10:19 stephane   Note Added: 0003397  
==

[1003.1(2008)/Issue 7 0001079]: focus on bc being an arithmetic language

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1079 
== 
Reported By:tobiasm
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   1079
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Editorial
Priority:   normal
Status: Under Review
Name:   Tobias Martens 
Organization:
User Reference:  
Section:bc 
Page Number:- 
Line Number:- 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2016-10-05 23:40 UTC
Last Modified:  2016-10-07 22:44 UTC
== 
Summary:focus on bc being an arithmetic language
== 

-- 
 (0003403) tobiasm (reporter) - 2016-10-07 22:44
 http://austingroupbugs.net/view.php?id=1079#c3403 
-- 
Exactly, echo "$var^2" will return -4. My suggestion does not take care of
this, because there is no way of implementing common arithmetic and getting
rid of this issue. The user still needs to know that shell substitutes the
variable before passing the whole string (no special knowledge about bc's
behaviour required however, which is the great plus). One needs to know the
same thing about shell right now (see the other example), so you're right
in this point there would be no improvement.
"3-$var" was mainly used to show that -- will occur when obviously meant as
subtraction.



Don't get me wrong, this is no bug report or something similar. bc is ok
right now even without change, but I would not oppose improvements for the
sake of persistence.
35 years ago computers weren't widespread enough for a common understanding
(of how arithmetic user input should be calculated) to become explicit. As
I hopefully pointed out, this has changed. So I propose bc to be changed. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-10-05 23:40 tobiasmNew Issue
2016-10-05 23:40 tobiasmStatus   New => Under Review 
2016-10-05 23:40 tobiasmAssigned To   => ajosey  
2016-10-05 23:40 tobiasmName  => Tobias Martens  
2016-10-05 23:40 tobiasmSection   => bc  
2016-10-05 23:40 tobiasmPage Number   => -   
2016-10-05 23:40 tobiasmLine Number   => -   
2016-10-06 07:41 Vincent LefevreNote Added: 0003395  
2016-10-06 07:41 Vincent LefevreNote Edited: 0003395 
2016-10-06 07:42 Vincent LefevreNote Edited: 0003395 
2016-10-06 08:02 Vincent LefevreNote Edited: 0003395 
2016-10-06 08:09 Vincent LefevreNote Added: 0003396  
2016-10-06 10:19 stephane   Note Added: 0003397  
2016-10-06 10:21 stephane   Note Edited: 0003397 
2016-10-06 10:39 stephane   Note Edited: 0003397 
2016-10-06 23:05 tobiasmNote Added: 0003398  
2016-10-07 00:06 Vincent LefevreNote Added: 0003399  
2016-10-07 00:15 Vincent LefevreNote Added: 0003400  
2016-10-07 02:14 Don Cragun Note Added: 0003401  
2016-10-07 22:44 tobiasmNote Added: 0003403  
==

[1003.1(2008)/Issue 7 0001079]: focus on bc being an arithmetic language

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1079 
== 
Reported By:tobiasm
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   1079
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Editorial
Priority:   normal
Status: Under Review
Name:   Tobias Martens 
Organization:
User Reference:  
Section:bc 
Page Number:- 
Line Number:- 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2016-10-05 23:40 UTC
Last Modified:  2016-10-07 00:15 UTC
== 
Summary:focus on bc being an arithmetic language
== 

-- 
 (0003400) Vincent Lefevre (reporter) - 2016-10-07 00:15
 http://austingroupbugs.net/view.php?id=1079#c3400 
-- 
Concerning the other issue, you want

echo "3-$var" | bc

to behave like

echo "3-($var)" | bc

when $var is a number. But what about the following?

echo "$var^2" | bc

Currently it behaves like

echo "($var)^2" | bc

if $var is a number, but if you want to change the precedence of the unary
minus operator to be less than the power operator, then

echo "$var^2" | bc

will no longer work as you expect: if $var is -2, it would give -4 instead
of 4. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-10-05 23:40 tobiasmNew Issue
2016-10-05 23:40 tobiasmStatus   New => Under Review 
2016-10-05 23:40 tobiasmAssigned To   => ajosey  
2016-10-05 23:40 tobiasmName  => Tobias Martens  
2016-10-05 23:40 tobiasmSection   => bc  
2016-10-05 23:40 tobiasmPage Number   => -   
2016-10-05 23:40 tobiasmLine Number   => -   
2016-10-06 07:41 Vincent LefevreNote Added: 0003395  
2016-10-06 07:41 Vincent LefevreNote Edited: 0003395 
2016-10-06 07:42 Vincent LefevreNote Edited: 0003395 
2016-10-06 08:02 Vincent LefevreNote Edited: 0003395 
2016-10-06 08:09 Vincent LefevreNote Added: 0003396  
2016-10-06 10:19 stephane   Note Added: 0003397  
2016-10-06 10:21 stephane   Note Edited: 0003397 
2016-10-06 10:39 stephane   Note Edited: 0003397 
2016-10-06 23:05 tobiasmNote Added: 0003398  
2016-10-07 00:06 Vincent LefevreNote Added: 0003399  
2016-10-07 00:15 Vincent LefevreNote Added: 0003400  
==

[1003.1(2008)/Issue 7 0001079]: focus on bc being an arithmetic language

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1079 
== 
Reported By:tobiasm
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   1079
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Editorial
Priority:   normal
Status: Under Review
Name:   Tobias Martens 
Organization:
User Reference:  
Section:bc 
Page Number:- 
Line Number:- 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2016-10-05 23:40 UTC
Last Modified:  2016-10-06 23:05 UTC
== 
Summary:focus on bc being an arithmetic language
== 

-- 
 (0003398) tobiasm (reporter) - 2016-10-06 23:05
 http://austingroupbugs.net/view.php?id=1079#c3398 
-- 
I don't see how switching only the precedence of unary - and ^  (no other
precedence is affected) would break consistency with C, since C requires
you to unambiguously set precedence yourself with pow().
I'm  very grateful for your examples, regarding -(1+1)**2 one can also take
a look at gnuplot, which will return -4. However, it isn't my intention to
throw examples back and forth, pretty sure there are enough for both
variants. The question to ask is whether we want bc to stick to a feature
useful in and coming from reverse Polish notation, despite using Polish
notation itself. I'll pursue this later, but want to address the other
point first.


Regarding the distinction between unary decrement and subtraction of
negative: 
I totally agree that it's the best to put parentheses generally, but we
also need to look what should happen if someone does not. The important
difference between C (and languages using C-like syntax, e.g. the quoted pg
and calc) on the one hand and bc on the other: The former mostly work with
code, calculations are self contained. Something like 3--2 will never
happen, because -2 is never separated in the first way. bc however often
works with user input strings, where -- will occur! (See the example above:
echo "3-$var" | bc). For single-line (and sometimes sloppy) user input imo,
unlike code, a strict or very careful syntax with parentheses and spaces
around each expression shouldn't be demanded.
Besides, we don't need to discuss if this general syntax should be allowed
in bc because it already is - the specs mandate it. Just try 

3+-2

bc resolve it correctly to  '3 + (-2)'. The only problem now is the --
possible twofold interpretation, where bc will return error.
Note how bash at least has no problems calculating (so consistency is
broken there):

bash -c 'echo $((3--2))'
5

The question here (kinda also applies to the previous point): Focus on some
other programming languages' C-like syntax or common arithmetic?


Its pretty obvious that there won't be a statement what is right or wrong,
this is about the orientation of bc. Looking at the purpose, I feel that
unlike C or Mathematica bc is much more often confronted with user input in
form of a single string.
Independent of the particular problems, I think that a standard either sets
common understanding of how things should work, or should adhere to it if
already settled. The latter applies, at least for user input specialized
languages. Some examples, also to show what type of calculator I mean:
My old Casio (TI likely the same).
Google Search.
WolframAlpha (based on Mathematica and from the same company, but focused
on single string user input).
Desktop Calculators.
Each will say -(1+1)^2=-4 and 3--2=5. Note that I simply can't name a
single user input specialized calculator or language that behaves
otherwise. I hope this gives an overview on how the common understanding of
arithmetic is (outside programming languages, where none exists).

Right now bc is somewhat consistent with some programming languages. I
would prefer it to be a arithmetic language in terms of common
understanding. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-10-05 23:40 tobiasmNew Issue
2016-10-05 23:40 tobiasmStatus   New => Under 

[1003.1(2008)/Issue 7 0001079]: focus on bc being an arithmetic language

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1079 
== 
Reported By:tobiasm
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   1079
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Editorial
Priority:   normal
Status: Under Review
Name:   Tobias Martens 
Organization:
User Reference:  
Section:bc 
Page Number:- 
Line Number:- 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2016-10-05 23:40 UTC
Last Modified:  2016-10-07 02:14 UTC
== 
Summary:focus on bc being an arithmetic language
== 

-- 
 (0003401) Don Cragun (manager) - 2016-10-07 02:14
 http://austingroupbugs.net/view.php?id=1079#c3401 
-- 
I find this entire discussion disappointing.  If you would like to have a
calculator in the standard that performs unambiguous evaluation of adjacent
operators with a different precedence than that specified by the standard
for the bc utility; please design a new utility that behaves the way you
want it to behave, implement that utility, show us that applications and/or
users are using your new utility in preference to bc, and submit that new
utility for standardization.

Please DO NOT suggest that all of the code that is using bc today should be
modified to meet a new, incompatible definition of how bc should behave. 
The language bc recognizes for arithmetic evaluations was created over 35
years ago.  Now is NOT the time to change that language.  Yes it is
possible to send input to bc expressions that might not be evaluated in an
obvious way if you don't pay attention to the current specification of the
bc utility; it is also possible to use space between operators and
parentheses around expressions to properly evaluate any calculation you
want to perform. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-10-05 23:40 tobiasmNew Issue
2016-10-05 23:40 tobiasmStatus   New => Under Review 
2016-10-05 23:40 tobiasmAssigned To   => ajosey  
2016-10-05 23:40 tobiasmName  => Tobias Martens  
2016-10-05 23:40 tobiasmSection   => bc  
2016-10-05 23:40 tobiasmPage Number   => -   
2016-10-05 23:40 tobiasmLine Number   => -   
2016-10-06 07:41 Vincent LefevreNote Added: 0003395  
2016-10-06 07:41 Vincent LefevreNote Edited: 0003395 
2016-10-06 07:42 Vincent LefevreNote Edited: 0003395 
2016-10-06 08:02 Vincent LefevreNote Edited: 0003395 
2016-10-06 08:09 Vincent LefevreNote Added: 0003396  
2016-10-06 10:19 stephane   Note Added: 0003397  
2016-10-06 10:21 stephane   Note Edited: 0003397 
2016-10-06 10:39 stephane   Note Edited: 0003397 
2016-10-06 23:05 tobiasmNote Added: 0003398  
2016-10-07 00:06 Vincent LefevreNote Added: 0003399  
2016-10-07 00:15 Vincent LefevreNote Added: 0003400  
2016-10-07 02:14 Don Cragun Note Added: 0003401  
==

[Online Pubs 0001080]: Misplaced "Chapter 7, Locale"

[Austin Group Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://austingroupbugs.net/view.php?id=1080 
== 
Reported By:dannyniu
Assigned To:
== 
Project:Online Pubs
Issue ID:   1080
Category:   Rationale
Type:   Error
Severity:   Editorial
Priority:   normal
Status: New
Name:   DannyNiu/NJF 
Organization:
User Reference:  
URL:   
http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xcu_chap04.html 
Section:C.4.3 Exclusion of Utilities 
== 
Date Submitted: 2016-10-07 09:06 UTC
Last Modified:  2016-10-07 09:06 UTC
== 
Summary:Misplaced "Chapter 7, Locale"
Description: 
As of 2016-10-07, the HTML version of the latest 2016 edition seem to be
generated with some wrong macros (I presume we're using troff to make
publications), as there are many instances of confusing references to the
Locale chapter, where as in the PDF version, they seem to refer to the old
IEEE POSIX 1992. 
Desired Action: 
A republish. 
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-10-07 09:06 dannyniu   New Issue
2016-10-07 09:06 dannyniu   Name  => DannyNiu/NJF
2016-10-07 09:06 dannyniu   URL   =>
http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xcu_chap04.html
2016-10-07 09:06 dannyniu   Section   => C.4.3 Exclusion of
Utilities
==

[2008-TC2 0001081]: sysconf shading error on obsolete system variables

[Austin Group Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://austingroupbugs.net/view.php?id=1081 
== 
Reported By:markh
Assigned To:
== 
Project:2008-TC2
Issue ID:   1081
Category:   System Interfaces
Type:   Error
Severity:   Editorial
Priority:   normal
Status: New
Name:   Mark Harris 
Organization:
User Reference:  
Section:sysconf() 
Page Number:2101 
Line Number:67354-67358 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2016-10-08 06:45 UTC
Last Modified:  2016-10-08 06:45 UTC
== 
Summary:sysconf shading error on obsolete system variables
Description: 
In the IEEE Std 1003.1-2016 PDF document, the sysconf() system interface
lists four system variables (_POSIX_V6_ILP32_OFF32 through
_POSIX_V6_LPBIG_OFFBIG) in a shaded region but with no margin code.  The
margin code should be OB.  Additionally, unlike other shading within a
table, the shading extends outside the bounds of the table.
Desired Action: 
Confine shading to table and add OB margin mode.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-10-08 06:45 markh  New Issue
2016-10-08 06:45 markh  Name  => Mark Harris 
2016-10-08 06:45 markh  Section   => sysconf()   
2016-10-08 06:45 markh  Page Number   => 2101
2016-10-08 06:45 markh  Line Number   => 67354-67358 
==

[1003.1(2008)/Issue 7 0000375]: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=375 
== 
Reported By:dwheeler
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   375
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Objection
Priority:   normal
Status: Under Review
Name:   David A. Wheeler 
Organization:
User Reference:  
Section:test 
Page Number:3224-3225 
Line Number:107503-107513 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2011-02-07 18:34 UTC
Last Modified:  2016-09-21 10:20 UTC
== 
Summary:Extend test/[...] conditionals: ==, <, >, -nt, -ot,
-ef
==
Relationships   ID  Summary
--
has duplicate   762 Add == as synonym for 
related to  813 Utility numeric argument syntax require...
== 

-- 
 (0003387) stephane (reporter) - 2016-09-21 10:20
 http://austingroupbugs.net/view.php?id=375#c3387 
-- 
Let me rephrase. [[ =~ ]] in ksh93 and bash32+ is a bit broken by design,
but to use it properly in both (which seems to be the intent of this
proposal: to specify an operator compatible with both), it seems we need
(for the argument after =~) to:

- quote &, <, >, blanks (locale-dependant (*)) and unmatched ) and some
unmatched ] at least or we'd get errors in bash or ksh93
- *not* quote the ERE operators (.*?+[]{}()|$^) if we want them to retain
their special ERE significance. You'll notice that several of those (()|)
can't be in WORD
- quote `, ~, $ and quotes to remove their special meaning as shell tokens
(but not inside [...] for some)
- to remove the special meaning of those ERE operators, we can use double
quotes, single quotes, backslash or $'...' but not when they're inside
[...].
- other characters can be quoted as well but not with backslash as that
could introduce ERE extensions like \<, \>, \b, \w in ksh93.
- for parts of the arguments that are the result of an unquoted expansion
other than ~ expansion, \ (in the content of the expansion) removes the
special meaning of ERE operators and may introduce new ones.


Examples:

  a=''  bash -c '[[ $a =~ <.*> ]]' gives an error
  a='foo' ksh93 -c '[[ $a =~ \<.*\> ]]' returns true (\<, \> taken as word
boundaries)

You need to use:

  a='' shell -c '[[ $a =~ "<".*">" ]]' so it works in both shells or
  a='' shell -c 're="<.*>"; [[ $a =~ $re ]]' which also works in zsh
and bash31

Other example:

  a='blah' shell -c '[[ $a =~ [xy)] ]]' gives an error in both ksh and
bash
  a='\' shell -c '[[ $a =~ [xy\)] ]]' doesn't give an error but matches in
ksh (not in bash). and [[ $a =~ [xy")"] ]] also matches on backslash in
ksh93, bash used to have a similar bug.

  a='blah' shell -c 're="[xy)]"; [[ $a =~ $re ]]' works in all shells (zsh,
bash31 included)

(*) as already discussed, since blank recognition is locale dependant, you
get behaviours like:

$ LC_CTYPE=fr_FR.ISO8859-15@euro bash -c '[[ $a =~ tête-à-tête ]]'
bash: -c: line 0: syntax error in conditional expression
bash: -c: line 0: syntax error near `tête-à-tête'
bash: -c: line 0: `[[ $a =~ tête-à-tête ]]'

as that à UTF-8 character is 0xc3 0xa0 and 0xa0 happens to be a blank in
ISO8859-15 locales on Solaris.

So in effect you may need to quote every character that is not in the
portable character set in case they may be a blank in the user's locale. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2011-02-07 18:34 dwheeler   New Issue
2011-02-07 18:34 dwheeler   Status   New => Under Review 
2011-02-07 18:34 dwheeler   Assigned To   => ajosey  
2011-02-07 18:34 dwheeler   Name  => David A. Wheeler
2011-02-07 18:34 dwheeler   Section   => test
2011-02-07 18:34 dwheeler   Page Number   => 3224-3225   
2011-02-07 18:34 dwheeler   Line Number   => 

[1003.1(2008)/Issue 7 0000375]: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=375 
== 
Reported By:dwheeler
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   375
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Objection
Priority:   normal
Status: Under Review
Name:   David A. Wheeler 
Organization:
User Reference:  
Section:test 
Page Number:3224-3225 
Line Number:107503-107513 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2011-02-07 18:34 UTC
Last Modified:  2016-09-20 17:16 UTC
== 
Summary:Extend test/[...] conditionals: ==, <, >, -nt, -ot,
-ef
==
Relationships   ID  Summary
--
has duplicate   762 Add == as synonym for 
related to  813 Utility numeric argument syntax require...
== 

-- 
 (0003383) shware_systems (reporter) - 2016-09-20 17:16
 http://austingroupbugs.net/view.php?id=375#c3383 
-- 
The intent in the proposal is the right hand side respect the
extended_reg_exp production of the grammar in XBD 9.5, so it is already
defined. I agree adding a production clause to db_factor, or modifying Note
10, is desirable to make this cross reference clearer in the grammar. Also,
the cross reference to 9.4 in the description of =~ is missing "XBD" as
volume referent.

As the ~ is a non-special ERE character, I don't believe it should be
expanded to / for the compare, so think the ksh93 result more the intent.
For [[ / = ~ ]] as the expression, that I'd expect to return true. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2011-02-07 18:34 dwheeler   New Issue
2011-02-07 18:34 dwheeler   Status   New => Under Review 
2011-02-07 18:34 dwheeler   Assigned To   => ajosey  
2011-02-07 18:34 dwheeler   Name  => David A. Wheeler
2011-02-07 18:34 dwheeler   Section   => test
2011-02-07 18:34 dwheeler   Page Number   => 3224-3225   
2011-02-07 18:34 dwheeler   Line Number   => 107503-107513   
2011-02-07 18:49 dwheeler   Note Added: 666  
2011-02-07 20:23 Don Cragun Interp Status => --- 
2011-02-07 20:23 Don Cragun Note Added: 667  
2011-02-07 20:23 Don Cragun Severity Editorial => Objection
2011-02-07 20:23 Don Cragun Type Clarification Requested
=> Enhancement Request
2011-02-07 21:56 dwheeler   Note Added: 668  
2011-02-07 22:20 Don Cragun Description Updated  
2011-02-07 22:20 Don Cragun Desired Action Updated   
2011-02-07 22:22 Don Cragun Note Edited: 667 
2011-02-07 22:50 dwheeler   Note Added: 669  
2011-02-07 23:13 eblake Note Added: 670  
2011-03-08 03:15 dwheeler   Note Added: 688  
2011-04-24 13:16 jsonn  Note Added: 754  
2011-04-24 19:01 dwheeler   Note Added: 755  
2011-04-24 21:48 jsonn  Note Added: 756  
2011-04-25 20:45 dwheeler   Note Added: 758  
2011-04-26 09:25 markh  Note Added: 759  
2011-04-26 09:57 wpollock   Note Added: 760  
2011-04-26 10:36 jsonn  Note Added: 761  
2011-09-22 08:59 ajosey Note Added: 967  
2011-09-25 00:36 dwheeler   Note Added: 974  
2011-09-25 18:51 gber   Note Added: 975  
2011-09-28 07:09 olof   Issue Monitored: olof

[1003.1(2008)/Issue 7 0000375]: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=375 
== 
Reported By:dwheeler
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   375
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Objection
Priority:   normal
Status: Under Review
Name:   David A. Wheeler 
Organization:
User Reference:  
Section:test 
Page Number:3224-3225 
Line Number:107503-107513 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2011-02-07 18:34 UTC
Last Modified:  2016-09-19 21:46 UTC
== 
Summary:Extend test/[...] conditionals: ==, <, >, -nt, -ot,
-ef
==
Relationships   ID  Summary
--
has duplicate   762 Add == as synonym for 
related to  813 Utility numeric argument syntax require...
== 

-- 
 (0003382) stephane (reporter) - 2016-09-19 21:46
 http://austingroupbugs.net/view.php?id=375#c3382 
-- 
For the =~ part, we'd need to define a new type of token for what's on the
right of =~.

For instance in [[ aacc =~ (aa|bb)c ]], currently (aa|bb)c can't be a WORD
as (, | and ) are token delimiters (note that [[ "a(a)" = *(a) ]] doesn't
return true in bash or ksh93).

See also [[ a1 =~ (a)\1 ]] that returns true in bash and false in ksh93 (\
is not like the other quoting operators). See also [[ a =~ \b ]] (or
\>...).

There's also the questions of the effect of quoting in things like [[ a =~
["$chars"] ]], should [[ : =~ ["^:#"] ]] return true like in bash or false
like in ksh93?

There's also the question of ~ expansion. Should

   HOME=/
   [[ / =~ ~ ]]

return true like in bash or false like in ksh93? 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2011-02-07 18:34 dwheeler   New Issue
2011-02-07 18:34 dwheeler   Status   New => Under Review 
2011-02-07 18:34 dwheeler   Assigned To   => ajosey  
2011-02-07 18:34 dwheeler   Name  => David A. Wheeler
2011-02-07 18:34 dwheeler   Section   => test
2011-02-07 18:34 dwheeler   Page Number   => 3224-3225   
2011-02-07 18:34 dwheeler   Line Number   => 107503-107513   
2011-02-07 18:49 dwheeler   Note Added: 666  
2011-02-07 20:23 Don Cragun Interp Status => --- 
2011-02-07 20:23 Don Cragun Note Added: 667  
2011-02-07 20:23 Don Cragun Severity Editorial => Objection
2011-02-07 20:23 Don Cragun Type Clarification Requested
=> Enhancement Request
2011-02-07 21:56 dwheeler   Note Added: 668  
2011-02-07 22:20 Don Cragun Description Updated  
2011-02-07 22:20 Don Cragun Desired Action Updated   
2011-02-07 22:22 Don Cragun Note Edited: 667 
2011-02-07 22:50 dwheeler   Note Added: 669  
2011-02-07 23:13 eblake Note Added: 670  
2011-03-08 03:15 dwheeler   Note Added: 688  
2011-04-24 13:16 jsonn  Note Added: 754  
2011-04-24 19:01 dwheeler   Note Added: 755  
2011-04-24 21:48 jsonn  Note Added: 756  
2011-04-25 20:45 dwheeler   Note Added: 758  
2011-04-26 09:25 markh  Note Added: 759  
2011-04-26 09:57 wpollock   Note Added: 760  
2011-04-26 10:36 jsonn  Note Added: 761  
2011-09-22 08:59 ajosey Note Added: 967  
2011-09-25 00:36 dwheeler   Note Added: 974  
2011-09-25 

[1003.1(2008)/Issue 7 0000375]: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=375 
== 
Reported By:dwheeler
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   375
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Objection
Priority:   normal
Status: Under Review
Name:   David A. Wheeler 
Organization:
User Reference:  
Section:test 
Page Number:3224-3225 
Line Number:107503-107513 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2011-02-07 18:34 UTC
Last Modified:  2016-09-23 06:59 UTC
== 
Summary:Extend test/[...] conditionals: ==, <, >, -nt, -ot,
-ef
==
Relationships   ID  Summary
--
has duplicate   762 Add == as synonym for 
related to  813 Utility numeric argument syntax require...
== 

-- 
 (0003392) stephane (reporter) - 2016-09-23 06:59
 http://austingroupbugs.net/view.php?id=375#c3392 
-- 
Re: http://austingroupbugs.net/view.php?id=375#c3391

Mark, you're missing the point I'm trying to make since the
beginning. What you're describing (about quoting of RE
operators) is the zsh/bash31 behaviour, not the one of
bash32+/ksh93 or what this proposal specifies. Quoting the
proposal:

> string =~ regex
> true if string matches the extended regular expression (ERE)
> regex as defined in section 9.4; otherwise false.  Characters
> that are quoted in regex (using , single-quote, or
> double-quote) shall not be treated as an ERE special character,
> but shall instead be treated as an ERE ordinary character and
> thus only match themselves.

See also appendix B

So [[ $a =~ "foo|bar" ]] and s='foo|bar'; [[ $a =~ "$s" ]] is
testing whether $a contains "foo|bar" (as if by calling
regcomp("foo\\|bar")), [[ $a =~ foo|bar ]] is not allowed and
re='foo|bar'; [[ $a =~ $re ]] is matching $a against the foo|bar
ERE (regcomp("foo|bar")).

With  bash-4.3:


$ ltrace -e regcomp bash -c '[[ a =~ "a|b" ]]'
bash->regcomp(0x7013f3b0, "a\\|b", 1)  
  = 0
+++ exited (status 1) +++
$ ltrace -e regcomp bash -c '[[ a =~ a|b ]]'
bash->regcomp(0x7fff33a64d50, "a|b", 1)
  = 0
+++ exited (status 0) +++
$ ltrace -e regcomp bash -c 're="a|b"; [[ a =~ "$re" ]]'
bash->regcomp(0x7fffba6ec710, "a\\|b", 1)  
  = 0
+++ exited (status 1) +++
$ ltrace -e regcomp bash -c 're="a|b"; [[ a =~ $re ]]'
bash->regcomp(0x7ffe497b2700, "a|b", 1)
  = 0
+++ exited (status 0) +++
$ ltrace -e regcomp bash -c '[[ a =~ ["a|b"] ]]'
bash->regcomp(0x7ffe32decc20, "[a|b]", 1)  
  = 0
+++ exited (status 0) +++
$ ltrace -e regcomp bash -c '[[ a =~ "[a|b]" ]]'
bash->regcomp(0x7ffea326a1e0, "\\[a\\|b]", 1)  
  = 0
+++ exited (status 1) +++


With zsh-5.1.1


$ ltrace -e regcomp zsh -c '[[ a =~ "a|b" ]]'
regex.so->regcomp(0x7ffc3aaa2ac0, "a|b", 1)
  = 0
+++ exited (status 0) +++
$ ltrace -e regcomp zsh -c '[[ a =~ a|b ]]'
zsh:1: parse error near `|'
+++ exited (status 1) +++
 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2011-02-07 18:34 dwheeler   New Issue
2011-02-07 18:34 dwheeler   Status   New => Under Review 
2011-02-07 18:34 dwheeler   Assigned To   => ajosey  
2011-02-07 18:34 dwheeler   Name  => David A. Wheeler
2011-02-07 18:34 dwheeler   Section   => test
2011-02-07 18:34 dwheeler   Page Number   => 3224-3225   

[1003.1(2008)/Issue 7 0000375]: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=375 
== 
Reported By:dwheeler
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   375
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Objection
Priority:   normal
Status: Under Review
Name:   David A. Wheeler 
Organization:
User Reference:  
Section:test 
Page Number:3224-3225 
Line Number:107503-107513 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2011-02-07 18:34 UTC
Last Modified:  2016-09-23 04:17 UTC
== 
Summary:Extend test/[...] conditionals: ==, <, >, -nt, -ot,
-ef
==
Relationships   ID  Summary
--
has duplicate   762 Add == as synonym for 
related to  813 Utility numeric argument syntax require...
== 

-- 
 (0003391) shware_systems (reporter) - 2016-09-23 04:17
 http://austingroupbugs.net/view.php?id=375#c3391 
-- 
"foo|bar" after quote removal effectively gets passed to regcomp() as the C
string foo|bar\0. A shell can use an internal workalike function that
includes the effect of regexec()/free() too. That is what is expected to
handle the extended_reg_exp production, not the code that handles shell
operators. The result is then the same for
re="foo|bar"
[[ $str =~ $re ]] 
or even =~ `printf %s%s%s foo '|' bar`.

The concerns you have apply if the ERE was an argument to [[ as a utility,
as then the simple_command production governs interpretation, but as a
keyword pair with its own productions those constraints don't hold.

The locale's charmap determines the bit patterns of each code point. So the
shell is dependant on them for determining whether a byte is a defined char
and which class it is. Hardcoding a reliance on the C locale's charmap may
fail, as a result, if the charmap of a locale says the TAB code point is
represented by 0xFF instead. 

This is a separate issue from what code points are required to be in each
charclass for all locales. For a script to be portable unquoted input with
grammatical significance in terms of being token delimiters is limited to
these code points. Relying on code points a locale may add to a class means
the script can not function properly on a platform that doesn't provide
localedef or a locale with the same additions, so to me is undefined
behavior.

This does not limit scripts to using only the POSIX locale, but it is a
subset of the locales scripts that don't care about portability might use. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2011-02-07 18:34 dwheeler   New Issue
2011-02-07 18:34 dwheeler   Status   New => Under Review 
2011-02-07 18:34 dwheeler   Assigned To   => ajosey  
2011-02-07 18:34 dwheeler   Name  => David A. Wheeler
2011-02-07 18:34 dwheeler   Section   => test
2011-02-07 18:34 dwheeler   Page Number   => 3224-3225   
2011-02-07 18:34 dwheeler   Line Number   => 107503-107513   
2011-02-07 18:49 dwheeler   Note Added: 666  
2011-02-07 20:23 Don Cragun Interp Status => --- 
2011-02-07 20:23 Don Cragun Note Added: 667  
2011-02-07 20:23 Don Cragun Severity Editorial => Objection
2011-02-07 20:23 Don Cragun Type Clarification Requested
=> Enhancement Request
2011-02-07 21:56 dwheeler   Note Added: 668  
2011-02-07 22:20 Don Cragun Description Updated  
2011-02-07 22:20 Don Cragun Desired Action Updated   
2011-02-07 22:22 Don Cragun Note Edited: 667 
2011-02-07 22:50 dwheeler   Note Added: 669  
2011-02-07 23:13 eblake  

[1003.1(2008)/Issue 7 0000375]: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=375 
== 
Reported By:dwheeler
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   375
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Objection
Priority:   normal
Status: Under Review
Name:   David A. Wheeler 
Organization:
User Reference:  
Section:test 
Page Number:3224-3225 
Line Number:107503-107513 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2011-02-07 18:34 UTC
Last Modified:  2016-09-21 22:44 UTC
== 
Summary:Extend test/[...] conditionals: ==, <, >, -nt, -ot,
-ef
==
Relationships   ID  Summary
--
has duplicate   762 Add == as synonym for 
related to  813 Utility numeric argument syntax require...
== 

-- 
 (0003388) shware_systems (reporter) - 2016-09-21 22:44
 http://austingroupbugs.net/view.php?id=375#c3388 
-- 
This proposal, as a white paper, is a case where the behaviors are being
merged to be future compatible more than backwards. This is also why test
is being deprecated and marked LEGACY. Both it and the [[ extensions are
broken one way or the other, so this proposal is taking what isn't broken
and giving it a firmer logical model by adding it to the grammar with
extensibility provisions. The caveat about what the standard says being
reliable only in the C locale and locales using nationalized ASCII applies
here too, for now; future Enhancement Reqs. against the V8 drafts that
define additional required locales will address remaining localization
concerns. 

It is known this may break any current script using [[ as an extension. The
changes to fix those scripts are expected to be minimal; as proposed, for
EREs, enclosing the entire WORD in double quotes will suffice in most
cases, only needing \", \` and \$ internally to disable substitutions
processing. If tilde expansion is enabled and desired something like
"head"~"tail" is required. The onus is already on script authors, if they
don't enclose a WORD in quotes, to escape any character that implicitly
delimits the token. New scripts are expected to do version checking that
they're running on V8 or later to avoid conflicts of interpretation with
older shells. It should not break any conforming scripts that were only
using test with operators other than -a or -o.

Last, for portable scripts blank detection is currently not
locale-dependant. For tokenization only the SPC and TAB code points count,
as the default members of the blank charclass. Recognizing additional
members of a locale's blank charclass is undefined behavior. Adding default
members from ISO-646 is possible, but not likely. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2011-02-07 18:34 dwheeler   New Issue
2011-02-07 18:34 dwheeler   Status   New => Under Review 
2011-02-07 18:34 dwheeler   Assigned To   => ajosey  
2011-02-07 18:34 dwheeler   Name  => David A. Wheeler
2011-02-07 18:34 dwheeler   Section   => test
2011-02-07 18:34 dwheeler   Page Number   => 3224-3225   
2011-02-07 18:34 dwheeler   Line Number   => 107503-107513   
2011-02-07 18:49 dwheeler   Note Added: 666  
2011-02-07 20:23 Don Cragun Interp Status => --- 
2011-02-07 20:23 Don Cragun Note Added: 667  
2011-02-07 20:23 Don Cragun Severity Editorial => Objection
2011-02-07 20:23 Don Cragun Type Clarification Requested
=> Enhancement Request
2011-02-07 21:56 dwheeler   Note Added: 668  
2011-02-07 22:20 Don Cragun Description Updated  
2011-02-07 22:20 Don Cragun Desired Action 

[1003.1(2008)/Issue 7 0000375]: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=375 
== 
Reported By:dwheeler
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   375
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Objection
Priority:   normal
Status: Under Review
Name:   David A. Wheeler 
Organization:
User Reference:  
Section:test 
Page Number:3224-3225 
Line Number:107503-107513 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2011-02-07 18:34 UTC
Last Modified:  2016-09-21 07:35 UTC
== 
Summary:Extend test/[...] conditionals: ==, <, >, -nt, -ot,
-ef
==
Relationships   ID  Summary
--
has duplicate   762 Add == as synonym for 
related to  813 Utility numeric argument syntax require...
== 

-- 
 (0003386) shware_systems (reporter) - 2016-09-21 07:35
 http://austingroupbugs.net/view.php?id=375#c3386 
-- 
Re: 3384
Ok, I oversimplified a bit on 1. It is the result of the WORD, after
substitutions and quote removal, but minus field splitting, globbing, and I
was thinking tilde expansions, that is meant to be reparsed as an
extended_reg_exp. It is left to the script author to figure out how much
the input needs to be quoted so the result has blanks and other
meta-characters EREs don't consider special appearing where required after
the quote removal. I still think an additional token type isn't required
for expressing this in the grammar. Possibly a Note 11 if this is cleaner
than adding to Note 10, but the overall context is more similar to the
pattern production than the context of ASSIGNMENT_WORD, that I see. 

If tilde expansion is included then 2. should return true, otherwise no. I
can see limiting tilde expansion to those operators that expect a filepath
string as the WORD result, and non-special otherwise. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2011-02-07 18:34 dwheeler   New Issue
2011-02-07 18:34 dwheeler   Status   New => Under Review 
2011-02-07 18:34 dwheeler   Assigned To   => ajosey  
2011-02-07 18:34 dwheeler   Name  => David A. Wheeler
2011-02-07 18:34 dwheeler   Section   => test
2011-02-07 18:34 dwheeler   Page Number   => 3224-3225   
2011-02-07 18:34 dwheeler   Line Number   => 107503-107513   
2011-02-07 18:49 dwheeler   Note Added: 666  
2011-02-07 20:23 Don Cragun Interp Status => --- 
2011-02-07 20:23 Don Cragun Note Added: 667  
2011-02-07 20:23 Don Cragun Severity Editorial => Objection
2011-02-07 20:23 Don Cragun Type Clarification Requested
=> Enhancement Request
2011-02-07 21:56 dwheeler   Note Added: 668  
2011-02-07 22:20 Don Cragun Description Updated  
2011-02-07 22:20 Don Cragun Desired Action Updated   
2011-02-07 22:22 Don Cragun Note Edited: 667 
2011-02-07 22:50 dwheeler   Note Added: 669  
2011-02-07 23:13 eblake Note Added: 670  
2011-03-08 03:15 dwheeler   Note Added: 688  
2011-04-24 13:16 jsonn  Note Added: 754  
2011-04-24 19:01 dwheeler   Note Added: 755  
2011-04-24 21:48 jsonn  Note Added: 756  
2011-04-25 20:45 dwheeler   Note Added: 758  
2011-04-26 09:25 markh  Note Added: 759  
2011-04-26 09:57 wpollock   Note Added: 760  
2011-04-26 10:36 jsonn  

[1003.1(2008)/Issue 7 0000375]: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=375 
== 
Reported By:dwheeler
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   375
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Objection
Priority:   normal
Status: Under Review
Name:   David A. Wheeler 
Organization:
User Reference:  
Section:test 
Page Number:3224-3225 
Line Number:107503-107513 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2011-02-07 18:34 UTC
Last Modified:  2016-09-22 08:59 UTC
== 
Summary:Extend test/[...] conditionals: ==, <, >, -nt, -ot,
-ef
==
Relationships   ID  Summary
--
has duplicate   762 Add == as synonym for 
related to  813 Utility numeric argument syntax require...
== 

-- 
 (0003390) stephane (reporter) - 2016-09-22 08:59
 http://austingroupbugs.net/view.php?id=375#c3390 
-- 
Re: http://austingroupbugs.net/view.php?id=375#c3388
> This proposal, as a white paper, is a case where the behaviors are being
> merged to be future compatible more than backwards. This is also why test
is
> being deprecated and marked LEGACY. Both it and the [[ extensions are
broken
> one way or the other, so this proposal is taking what isn't broken and
giving
> it a firmer logical model by adding it to the grammar with extensibility
> provisions. The caveat about what the standard says being reliable only
in
> the C locale and locales using nationalized ASCII applies here too, for
now;
> future Enhancement Reqs. against the V8 drafts that define additional
> required locales will address remaining localization concerns.

With -a, -o, (, ) and an argument-less -t removed, "test"/"[" is no longer
broken.

What I'm saying is that the two requirements that the =~ argument must be a
WORD and that quoting ERE operators remove their special meaning are
incompatible (or at least make for a not useful operator).

If you need to make it a WORD, then for instance, you can't do

[[ $string =~ foo|bar ]]

and if you do

[[ $string =~ "foo|bar" ]]

Then you're disabling that "|" ERE operator. You'd need:

re="foo|bar"
[[ $string =~ $re ]]

to make it work.

Then, you might as well specify the bash31/zsh behaviour where

[[ $string =~ "foo|bar" ]]

does test whether $string contain foo or bar as opposed to containing
"foo|bar"

> It is known this may break any current script using [[ as an extension.
The
> changes to fix those scripts are expected to be minimal; as proposed,
for
> EREs, enclosing the entire WORD in double quotes will suffice in most
cases,
> only needing \", \` and \$ internally to disable substitutions
processing. If
> tilde expansion is enabled and desired something like "head"~"tail" is
> required. The onus is already on script authors, if they don't enclose a
WORD
> in quotes, to escape any character that implicitly delimits the token.
New
> scripts are expected to do version checking that they're running on V8
or
> later to avoid conflicts of interpretation with older shells. It should
not
> break any conforming scripts that were only using test with operators
other
> than -a or -o.

tildes are not expanded in "head"~"tail", only at the beginning of a word
and when not quoted (though rules are different in assignments).

> Last, for portable scripts blank detection is currently not
locale-dependant.
> For tokenization only the SPC and TAB code points count, as the default
> members of the blank charclass. Recognizing additional members of a
locale's
> blank charclass is undefined behavior. Adding default members from
ISO-646 is
> possible, but not likely. 

What makes you say that? IIRC both bash and yash explicitely made their
tokenisation locale dependant for POSIX compliance. (I do agree it's not
desirable though) 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2011-02-07 18:34 dwheeler   New Issue   

[1003.1(2008)/Issue 7 0000375]: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=375 
== 
Reported By:dwheeler
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   375
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Objection
Priority:   normal
Status: Under Review
Name:   David A. Wheeler 
Organization:
User Reference:  
Section:test 
Page Number:3224-3225 
Line Number:107503-107513 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2011-02-07 18:34 UTC
Last Modified:  2016-09-22 08:42 UTC
== 
Summary:Extend test/[...] conditionals: ==, <, >, -nt, -ot,
-ef
==
Relationships   ID  Summary
--
has duplicate   762 Add == as synonym for 
related to  813 Utility numeric argument syntax require...
== 

-- 
 (0003389) stephane (reporter) - 2016-09-22 08:42
 http://austingroupbugs.net/view.php?id=375#c3389 
-- 
Re: http://austingroupbugs.net/view.php?id=375#c3387
> - *not* quote the ERE operators (.*?+[]{}()|$^) if we want them
> to retain their special ERE significance. You'll notice that
> several of those (()|) can't be in WORD
[...]
> - to remove the special meaning of those ERE operators, we can
> use double quotes, single quotes, backslash or $'...' but not
> when they're inside [...].

Actually, I hadn't realised ksh93's was so broken so the above
is incorrect. In ksh93, quotes other than backslash only escape
the ERE operators that also are wildcard operators (?*[]()|&),
not ^$.+, as in [[ a =~ "." ]] returns true (so does r=.; [[ a =
"$r" ]]).

And [[ "\\" =~ ["?"] ]] (or any of the other glob operators in
place of ?) returns true like in old versions of bash for RE
operators.

It looks like internally ksh93 replaces [[ x =~ y ]] with [[ x =
~(E)y ]]. [[ a = ~(E)"." ]] also returns true, while [[ a = "?"
]] returns false. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2011-02-07 18:34 dwheeler   New Issue
2011-02-07 18:34 dwheeler   Status   New => Under Review 
2011-02-07 18:34 dwheeler   Assigned To   => ajosey  
2011-02-07 18:34 dwheeler   Name  => David A. Wheeler
2011-02-07 18:34 dwheeler   Section   => test
2011-02-07 18:34 dwheeler   Page Number   => 3224-3225   
2011-02-07 18:34 dwheeler   Line Number   => 107503-107513   
2011-02-07 18:49 dwheeler   Note Added: 666  
2011-02-07 20:23 Don Cragun Interp Status => --- 
2011-02-07 20:23 Don Cragun Note Added: 667  
2011-02-07 20:23 Don Cragun Severity Editorial => Objection
2011-02-07 20:23 Don Cragun Type Clarification Requested
=> Enhancement Request
2011-02-07 21:56 dwheeler   Note Added: 668  
2011-02-07 22:20 Don Cragun Description Updated  
2011-02-07 22:20 Don Cragun Desired Action Updated   
2011-02-07 22:22 Don Cragun Note Edited: 667 
2011-02-07 22:50 dwheeler   Note Added: 669  
2011-02-07 23:13 eblake Note Added: 670  
2011-03-08 03:15 dwheeler   Note Added: 688  
2011-04-24 13:16 jsonn  Note Added: 754  
2011-04-24 19:01 dwheeler   Note Added: 755  
2011-04-24 21:48 jsonn  Note Added: 756  
2011-04-25 20:45 dwheeler   Note Added: 758  
2011-04-26 09:25 markh  Note Added: 759  
2011-04-26 09:57 wpollock   Note Added: 760  
2011-04-26 10:36 jsonn  

[1003.1(2008)/Issue 7 0000375]: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=375 
== 
Reported By:dwheeler
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   375
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Objection
Priority:   normal
Status: Under Review
Name:   David A. Wheeler 
Organization:
User Reference:  
Section:test 
Page Number:3224-3225 
Line Number:107503-107513 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2011-02-07 18:34 UTC
Last Modified:  2016-09-20 20:34 UTC
== 
Summary:Extend test/[...] conditionals: ==, <, >, -nt, -ot,
-ef
==
Relationships   ID  Summary
--
has duplicate   762 Add == as synonym for 
related to  813 Utility numeric argument syntax require...
== 

-- 
 (0003384) stephane (reporter) - 2016-09-20 20:34
 http://austingroupbugs.net/view.php?id=375#c3384 
-- 
Re: http://austingroupbugs.net/view.php?id=375#c3383

1- about grammar

That doesn't work. For instance the space character is not special in EREs,
yet

[[ $a =~ a b ]]

doesn't work obviously.

The behaviour for the a\ b ERE is unspecified. We may need to acknowledged
somehow that backslash is overloaded as a quoting operator in the shell and
as an escaping operator for EREs.

For instance, is re='a\b'; [[ a =~ $re ]] meant to be treated the same as
[[ a =~ a\b ]] (it's not in bash). And re='a"."b'; [[ a =~ $re ]] vs [[ a
=~ a"."b ]]

See also:

$ bash -c '[[ a =~ & ]]'
bash: -c: line 0: syntax error in conditional expression: unexpected token
`&'
bash: -c: line 0: syntax error near `&'
bash: -c: line 0: `[[ a =~ & ]]'

(same for #, < , >)

IMO, the original [[ =~ ]] implementation (in bash31) which is also the one
of zsh, where shell quoting doesn't make any difference in terms of RE
matching is a lot cleaner and easier to specify (applications just do [[
$var =~ '(..|X)&' ]], make sure the argument to =~ is a normal *shell*
WORD.

Or we could just give up on specifying [[...]] altogether (my preference as
it's broken by design except in zsh IMO as its =/== operator is not an
equality operator and it has hardly any benefit over the "[" command) and
add the =~ operator to "[" like in yash or zsh which would also be
straightforward to specify and unambiguous.

2- about ~

Whether ~ is a ERE operator or not is irrelevant here. The fact that it's
*not* a ERE operator (it is in ksh93 REs though as in [[ a =~ (?K:~(E)a)
]]) makes it even a justification that ~ can be safely expanded. ` is not a
ERE operator either, yet [[ Linux =~ `uname` ]] returns true on Linux with
both ksh93 and bash.

It's just that we need to clarify what expansions are or may be performed
in the argument to =~. Expanding ~ is not very useful because it's only
expanded at the start of the RE, but I can't see why it wouldn't be when
`...`, $param, $((arith)), $(cmd) are.

Also note that in bash the expansion of ~ ends up being quoted from an ERE
point of view, which makes sense as ~ is meant to expand to a path, not a
RE. As in HOME=.; [[ a/a =~ ~/a ]] returns false.

In bash, the same applies to process substitution.

[[ "<:" =~ <(:) ]] returns false (true in ksh93)

Both bash and ksh93 have taken some liberties with the standard inside
[[...]] as that construct was not specified by the standard. It's going to
be hard to come up with a specification that doesn't break either or both.
And if you want to throw zsh in the picture as well, it's going to be more
difficult... or simpler if we only specify [[ a =~ $var ]], that is leave
it unspecified unless the word after =~ is an unquoted variable and the
content of the variable contains a valid ERE. At the moment, that's the
only thing that is portable across bash31, bash32-or-above, zsh and ksh93. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2011-02-07 18:34 dwheeler   New Issue  

[1003.1(2008)/Issue 7 0000375]: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=375 
== 
Reported By:dwheeler
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   375
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Objection
Priority:   normal
Status: Under Review
Name:   David A. Wheeler 
Organization:
User Reference:  
Section:test 
Page Number:3224-3225 
Line Number:107503-107513 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2011-02-07 18:34 UTC
Last Modified:  2016-09-20 21:03 UTC
== 
Summary:Extend test/[...] conditionals: ==, <, >, -nt, -ot,
-ef
==
Relationships   ID  Summary
--
has duplicate   762 Add == as synonym for 
related to  813 Utility numeric argument syntax require...
== 

-- 
 (0003385) stephane (reporter) - 2016-09-20 21:03
 http://austingroupbugs.net/view.php?id=375#c3385 
-- 
Re http://austingroupbugs.net/view.php?id=375#c3384
> Both bash and ksh93 have taken some liberties with the standard inside
[[...]] as that construct was not specified by the standard

Amongst those liberties:

a='+(a)'; [[ a = $a ]]

currently returns true in both bash and ksh even though the current
proposal would mandate it to return false. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2011-02-07 18:34 dwheeler   New Issue
2011-02-07 18:34 dwheeler   Status   New => Under Review 
2011-02-07 18:34 dwheeler   Assigned To   => ajosey  
2011-02-07 18:34 dwheeler   Name  => David A. Wheeler
2011-02-07 18:34 dwheeler   Section   => test
2011-02-07 18:34 dwheeler   Page Number   => 3224-3225   
2011-02-07 18:34 dwheeler   Line Number   => 107503-107513   
2011-02-07 18:49 dwheeler   Note Added: 666  
2011-02-07 20:23 Don Cragun Interp Status => --- 
2011-02-07 20:23 Don Cragun Note Added: 667  
2011-02-07 20:23 Don Cragun Severity Editorial => Objection
2011-02-07 20:23 Don Cragun Type Clarification Requested
=> Enhancement Request
2011-02-07 21:56 dwheeler   Note Added: 668  
2011-02-07 22:20 Don Cragun Description Updated  
2011-02-07 22:20 Don Cragun Desired Action Updated   
2011-02-07 22:22 Don Cragun Note Edited: 667 
2011-02-07 22:50 dwheeler   Note Added: 669  
2011-02-07 23:13 eblake Note Added: 670  
2011-03-08 03:15 dwheeler   Note Added: 688  
2011-04-24 13:16 jsonn  Note Added: 754  
2011-04-24 19:01 dwheeler   Note Added: 755  
2011-04-24 21:48 jsonn  Note Added: 756  
2011-04-25 20:45 dwheeler   Note Added: 758  
2011-04-26 09:25 markh  Note Added: 759  
2011-04-26 09:57 wpollock   Note Added: 760  
2011-04-26 10:36 jsonn  Note Added: 761  
2011-09-22 08:59 ajosey Note Added: 967  
2011-09-25 00:36 dwheeler   Note Added: 974  
2011-09-25 18:51 gber   Note Added: 975  
2011-09-28 07:09 olof   Issue Monitored: olof
2011-11-15 17:26 dwheeler   Note Added: 0001011  
2011-11-15 19:25 ajosey File Added: Extendingshellconditionals.pdf  
 
2011-11-15 19:27 ajosey File Added: 

[1003.1(2013)/Issue7+TC1 0000983]: awk's rand()/srand() spec not useful

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=983 
== 
Reported By:stephane
Assigned To:
== 
Project:1003.1(2013)/Issue7+TC1
Issue ID:   983
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Editorial
Priority:   normal
Status: Interpretation Required
Name:   Stephane Chazelas 
Organization:
User Reference:  
Section:(section number or name, can be interface name) 
Page Number:2467 
Line Number:79046-79048 
Interp Status:  Proposed 
Final Accepted Text:See
http://austingroupbugs.net/view.php?id=983#c3271. 
== 
Date Submitted: 2015-08-31 21:41 UTC
Last Modified:  2016-08-25 17:33 UTC
== 
Summary:awk's rand()/srand() spec not useful
== 

-- 
 (0003362) rhansen (manager) - 2016-08-25 17:33
 http://austingroupbugs.net/view.php?id=983#c3362 
-- 
This was discussed during the 2016-08-25 teleconference.  We ran out of
time before finishing the conversation, so we'll pick it up again next
week.  For our notes, see http://po...@posix.rhansen.org:9001/p/2016-08-25
(password: 2115756#).

Regarding the default value srand() uses if one isn't provided:  We cannot
change the default value for Issue 7 because that would be a requirements
change that would break existing applications.  Changing it for Issue 8
might be appropriate, but that would have to be addressed in a separate bug
report because this bug report is tagged tc3-2008.  (We are considering
adding a "future directions" note for this bug report to let implementation
and application authors know that we might be changing the requirements in
this area.)

Regarding the range issue:  For this bug report we can say that a value
between 0 and 2^31-1 (inclusive) shall be supported and any other value has
unspecified behavior.  For Issue 8 we could expand the range or say
something more specific, but that would have to be addressed in a separate
bug report. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-08-31 21:41 stephane   New Issue
2015-08-31 21:41 stephane   Name  => Stephane Chazelas
2015-08-31 21:41 stephane   Section   => (section number or
name, can be interface name)
2015-08-31 21:41 stephane   Page Number   => 2467
2015-08-31 21:41 stephane   Line Number   => 79046-79048 
2016-06-16 16:07 joerg  Note Added: 0003265  
2016-06-23 16:27 Don Cragun Note Added: 0003271  
2016-06-23 16:29 Don Cragun Note Edited: 0003271 
2016-06-23 16:32 Don Cragun Note Edited: 0003271 
2016-06-23 16:33 Don Cragun Interp Status => Pending 
2016-06-23 16:33 Don Cragun Final Accepted Text   => See
http://austingroupbugs.net/view.php?id=983#c3271.
2016-06-23 16:33 Don Cragun Status   New => Interpretation
Required
2016-06-23 16:33 Don Cragun Resolution   Open => Accepted As
Marked
2016-06-23 16:40 Don Cragun Tag Attached: tc3-2008   
2016-06-23 19:59 stephane   Note Added: 0003272  
2016-06-23 22:15 shware_systems Note Added: 0003273  
2016-06-27 09:37 ajosey Interp StatusPending => Proposed 
2016-06-27 09:37 ajosey Note Added: 0003274  
2016-06-27 11:27 stephane   Note Added: 0003275  
2016-07-01 00:53 Don Cragun Note Added: 0003279  
2016-07-01 00:55 Don Cragun Note Edited: 0003279 
2016-07-01 00:56 Don Cragun Note Edited: 0003279 
2016-07-01 15:29 stephane   Note Added: 0003281  
2016-07-01 15:33 stephane   Note Edited: 0003281 
2016-07-01 15:34 stephane   Note Edited: 0003281 
2016-07-01 15:37 stephane   Note Edited: 

[1003.1(2013)/Issue7+TC1 0001009]: "remain in affect after" and "during the execution" are problematic when built-in/function modifies the variable

[Austin Group Bug Tracker]

The following issue has been REOPENED. 
== 
http://austingroupbugs.net/view.php?id=1009 
== 
Reported By:rhansen
Assigned To:
== 
Project:1003.1(2013)/Issue7+TC1
Issue ID:   1009
Category:   Shell and Utilities
Type:   Error
Severity:   Objection
Priority:   normal
Status: Under Review
Name:   Richard Hansen 
Organization:   BBN 
User Reference:  
Section:2.9.1, 2.14 item #2, 2.14 set -a 
Page Number:2339, 2356 
Line Number:74354-74361, 75105-75106 
Interp Status:  --- 
Final Accepted Text:http://austingroupbugs.net/view.php?id=1009#c3353 
== 
Date Submitted: 2015-11-20 00:59 UTC
Last Modified:  2016-08-26 08:30 UTC
== 
Summary:"remain in affect after" and "during the execution"
are problematic when built-in/function modifies the variable
==
Relationships   ID  Summary
--
related to  654 unclear behavior of in-line variable as...
== 

-- 
 (0003363) geoffclare (manager) - 2016-08-26 08:30
 http://austingroupbugs.net/view.php?id=1009#c3363 
-- 
Oops - seems we overlooked set -a in the teleconference.

Suggested replacement text (V7TC2D4 P2409 L77097):Set the
export attribute for all variable assignments that affect the
current execution environment.  When this option is on, the export
attribute shall be set for each variable to which an assignment is
performed (see [xref to XBD Section 4.23]) that affects the current
execution environment (see [xref to 2.9.1]), or which is set as a
result of the operation of the getopts or read
utilities.  This option shall have no effect on assignments that
do not affect the current execution environment. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-11-20 00:59 rhansenNew Issue
2015-11-20 00:59 rhansenName  => Richard Hansen  
2015-11-20 00:59 rhansenOrganization  => BBN 
2015-11-20 00:59 rhansenSection   => 2.9.1, 2.14 item
#2, 2.14 set -a
2015-11-20 00:59 rhansenPage Number   => 2339, 2356  
2015-11-20 00:59 rhansenLine Number   => 74354-74361,
75105-75106
2015-11-20 00:59 rhansenInterp Status => --- 
2015-11-20 01:01 rhansenRelationship added   related to 654  
2015-11-20 01:04 rhansenTag Attached: tc3-2008   
2015-11-22 19:55 shware_systems Note Added: 0002970  
2015-11-27 14:55 shware_systems Note Edited: 0002970 
2016-08-18 15:42 geoffclare Note Added: 0003353  
2016-08-18 15:43 geoffclare Final Accepted Text   =>
http://austingroupbugs.net/view.php?id=1009#c3353
2016-08-18 15:43 geoffclare Status   New => Resolved 
2016-08-18 15:43 geoffclare Resolution   Open => Accepted As
Marked
2016-08-18 15:44 geoffclare Note Edited: 0003353 
2016-08-18 16:06 geoffclare Note Edited: 0003353 
2016-08-18 16:15 geoffclare Note Edited: 0003353 
2016-08-25 15:15 rhansenNote Added: 0003360  
2016-08-26 08:30 geoffclare Note Added: 0003363  
2016-08-26 08:30 geoffclare Status   Resolved => Under
Review
2016-08-26 08:30 geoffclare Resolution   Accepted As Marked =>
Reopened
==

[1003.1(2013)/Issue7+TC1 0001069]: with a process group ID equal to (/*are you sure?*/pid_t)id

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1069 
== 
Reported By:dannyniu
Assigned To:
== 
Project:1003.1(2013)/Issue7+TC1
Issue ID:   1069
Category:   System Interfaces
Type:   Error
Severity:   Objection
Priority:   normal
Status: New
Name:   DannyNiu/NJF 
Organization:
User Reference:  
Section:System Interfaces, waitid 
Page Number:2212 
Line Number:70253 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2016-08-23 08:22 UTC
Last Modified:  2016-08-23 19:48 UTC
== 
Summary:with a process group ID equal to (/*are you
sure?*/pid_t)id
== 

-- 
 (0003357) Don Cragun (manager) - 2016-08-23 19:48
 http://austingroupbugs.net/view.php?id=1069#c3357 
-- 
If you just look at  on P401, L13461 where pid_t's uses are
listed, it says:
"Used for process IDs and process group IDs."

A group and a process group are two different things.
A group ID and a process group ID are two different things.
A gid_t and a pid_t are two different things.
A group and a group ID and a gid_t are related.
A process group and a process group ID and a pid_t are related. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-08-23 08:22 dannyniu   New Issue
2016-08-23 08:22 dannyniu   Name  => DannyNiu/NJF
2016-08-23 08:22 dannyniu   Section   => System Interfaces,
waitid
2016-08-23 08:22 dannyniu   Page Number   => 2212
2016-08-23 08:22 dannyniu   Line Number   => 70253   
2016-08-23 08:50 stephane   Note Added: 0003355  
2016-08-23 11:05 dannyniu   Note Added: 0003356  
2016-08-23 19:48 Don Cragun Note Added: 0003357  
==

[1003.1(2013)/Issue7+TC1 0001069]: with a process group ID equal to (/*are you sure?*/pid_t)id

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1069 
== 
Reported By:dannyniu
Assigned To:
== 
Project:1003.1(2013)/Issue7+TC1
Issue ID:   1069
Category:   System Interfaces
Type:   Error
Severity:   Objection
Priority:   normal
Status: New
Name:   DannyNiu/NJF 
Organization:
User Reference:  
Section:System Interfaces, waitid 
Page Number:2212 
Line Number:70253 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2016-08-23 08:22 UTC
Last Modified:  2016-08-24 07:16 UTC
== 
Summary:with a process group ID equal to (/*are you
sure?*/pid_t)id
== 

-- 
 (0003359) Don Cragun (manager) - 2016-08-24 07:16
 http://austingroupbugs.net/view.php?id=1069#c3359 
-- 
Re: http://austingroupbugs.net/view.php?id=1069#c3358: I am totally against
quoting this reference to "process
group ID" unless we also quote all of the other uses of the other 447
defined terms in XBD section 3 of the standard.  In just plain English
text, it should be clear to anyone reading the text:

"If idtype is P_PGID, waited() shall wait for any child
with a process group ID equal to (pid_t)id."

that "process group ID" is referring to the defined term "process group ID"
and  is not the referring to the defined term "group ID".  It is referring
to the ID of a group of processes ("process group ID").  There is no
possessive that would indicate that there is a reference to a "group ID" of
a "process" which would be referenced as a "process"'s "real group ID" or a
"process"'s "effective group ID". 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-08-23 08:22 dannyniu   New Issue
2016-08-23 08:22 dannyniu   Name  => DannyNiu/NJF
2016-08-23 08:22 dannyniu   Section   => System Interfaces,
waitid
2016-08-23 08:22 dannyniu   Page Number   => 2212
2016-08-23 08:22 dannyniu   Line Number   => 70253   
2016-08-23 08:50 stephane   Note Added: 0003355  
2016-08-23 11:05 dannyniu   Note Added: 0003356  
2016-08-23 19:48 Don Cragun Note Added: 0003357  
2016-08-24 02:01 dannyniu   Note Added: 0003358  
2016-08-24 02:05 dannyniu   Note Edited: 0003358 
2016-08-24 07:16 Don Cragun Note Added: 0003359  
==

[1003.1(2013)/Issue7+TC1 0001072]: m4 ifelse argument expansion clarification

[Austin Group Bug Tracker]

The following issue has been UPDATED. 
== 
http://austingroupbugs.net/view.php?id=1072 
== 
Reported By:quinngrier
Assigned To:
== 
Project:1003.1(2013)/Issue7+TC1
Issue ID:   1072
Category:   Shell and Utilities
Type:   Clarification Requested
Severity:   Comment
Priority:   normal
Status: New
Name:   Quinn Grier 
Organization:
User Reference:  
Section:m4 (utility) 
Page Number:2899, 2901 
Line Number:95625, 95733 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2016-08-27 01:18 UTC
Last Modified:  2016-08-29 03:29 UTC
== 
Summary:m4 ifelse argument expansion clarification
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-08-27 01:18 quinngrier New Issue
2016-08-27 01:18 quinngrier Name  => Quinn Grier 
2016-08-27 01:18 quinngrier Section   => m4 (utility)
2016-08-27 01:18 quinngrier Page Number   => 2899, 2901  
2016-08-27 01:18 quinngrier Line Number   => 95625, 95733
2016-08-29 03:01 quinngrier Note Added: 0003366  
2016-08-29 03:28 Don Cragun Interp Status => --- 
2016-08-29 03:28 Don Cragun Note Added: 0003367  
2016-08-29 03:28 Don Cragun Description Updated  
2016-08-29 03:29 Don Cragun Description Updated  
==

[1003.1(2016)/Issue7+TC2 0001098]: do_group symbol cannot be accepted as written, because rule 6 cannot yield Done token

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1098 
== 
Reported By:Mark_Galeck
Assigned To:
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1098
Category:   Shell and Utilities
Type:   Error
Severity:   Editorial
Priority:   normal
Status: New
Name:   Mark Galeck 
Organization:
User Reference:  
Section:2.10.2 Shell Grammar Rules 
Page Number:2379 
Line Number:76091 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2016-10-20 16:56 UTC
Last Modified:  2016-10-26 16:32 UTC
== 
Summary:do_group symbol cannot be accepted as written,
because rule 6 cannot yield Done token
== 

-- 
 (0003458) Mark_Galeck (reporter) - 2016-10-26 16:32
 http://austingroupbugs.net/view.php?id=1098#c3458 
-- 
>Rule 6 is necessary to force 'for' as unquoted text being treated as a
keyword and not a simple command with arguments, in the absence of a
sequential_sep as 'best/longest matching production' to satisfy the command
production. 


It could be that I already know what you are talking about, but can't tell
because I don't understand this sentence.

Since you write "necessary", can you give me an example involving "for",
that if we dropped rule 6 and just applied default rule 1, would behave
differently compared to the current standard?  


>A similar ambiguity exists for 'in' 

Likewise, please, an example involving "in".  


I am not trying to argue with you, I just want to see if there is anything
in what you wrote, that I don't already know.


> for varname do ( ) done
parses as a for loop, with '( )' representing a valid subshell
compound-list that does nothing, and fully matches for_clause choice 1


No it doesn't. '( )', with or without the space inside is invalid
subshell.
Both dash and bash do not accept it.


> for varname do \() done
parses as a simple command, 'for'; with 'varname', 'do', '()', and 'done'
as textual arguments,
as '\()' is an invalid compound-list that forces backtracking to
simple_command as best match


No it doesn't, for multiple reasons:

* 'for' as the first token will be treated as reserved word, regardless of
whether the remaining tokens do or not form valid 'for' loop sequence. 
That is because, in order for it to parse as a simple command, 'for' would
have to be WORD in the cmd_name production, and rule 7a applies, which
says, 'for' is For, not WORD.  

* Even if 'for' were a command name (which is not), \() is not one WORD
token, but two tokens, one \( and then second ), and the second token is
the ')' operator, so the whole thing would still not be one simple command
, but it would be invalid use of ')'.  

As before, check either dash or bash, they show what I wrote above.  


>  \for varname do ( ) done
also parses as a simple command, but with '(' and ')' as separate
arguments, due to the escaping '\' disabling keyword recognition.


No it doesn't.  Here '\for' is command OK, but both ( and ) are operators,
regardless of space between them, and they are unexpected.  

Again, bash and dash do not accept this. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-10-20 16:56 Mark_GaleckNew Issue
2016-10-20 16:56 Mark_GaleckName  => Mark Galeck 
2016-10-20 16:56 Mark_GaleckSection   => 2.10.2 Shell
Grammar Rules
2016-10-20 16:56 Mark_GaleckPage Number   => 2379
2016-10-20 16:56 Mark_GaleckLine Number   => 76091   
2016-10-21 09:23 geoffclare Note Added: 0003448  
2016-10-21 09:24 geoffclare Note Edited: 0003448 
2016-10-21 09:41 geoffclare Note Edited: 0003448 
2016-10-21 21:56 Mark_GaleckNote Added: 0003449  
2016-10-22 08:00 geoffclare Note Added: 0003450  
2016-10-22 08:22 Mark_GaleckNote Added: 0003451  
2016-10-22 10:44 geoffclare Note Added: 0003452

[1003.1(2016)/Issue7+TC2 0001096]: Why bother differentiating between several failure outcomes when it does not matter which one it is?

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1096 
== 
Reported By:Mark_Galeck
Assigned To:
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1096
Category:   Shell and Utilities
Type:   Clarification Requested
Severity:   Editorial
Priority:   normal
Status: New
Name:   Mark Galeck 
Organization:
User Reference:  
Section:2.10.2 Shell Grammar Rules 
Page Number:2376 
Line Number:75929-75930 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2016-10-20 12:31 UTC
Last Modified:  2016-10-27 12:43 UTC
== 
Summary:Why bother differentiating between several failure
outcomes when it does not matter which one it is?
== 

-- 
 (0003463) Mark_Galeck (reporter) - 2016-10-27 12:43
 http://austingroupbugs.net/view.php?id=1096#c3463 
-- 
This report is included in the summary report 1100 and can be cancelled. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-10-20 12:31 Mark_GaleckNew Issue
2016-10-20 12:31 Mark_GaleckName  => Mark Galeck 
2016-10-20 12:31 Mark_GaleckSection   => 2.10.2 Shell
Grammar Rules
2016-10-20 12:31 Mark_GaleckPage Number   => 2376
2016-10-20 12:31 Mark_GaleckLine Number   => 75929-75930 
2016-10-27 12:42 Mark_GaleckNote Added: 0003459  
2016-10-27 12:43 Mark_GaleckNote Added: 0003463  
==

[1003.1(2016)/Issue7+TC2 0001099]: the wordlist production should accept reserved words but as currently written it does not

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1099 
== 
Reported By:Mark_Galeck
Assigned To:
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1099
Category:   Shell and Utilities
Type:   Error
Severity:   Editorial
Priority:   normal
Status: New
Name:   Mark Galeck 
Organization:
User Reference:  
Section:2.10.2 Shell Grammar Rules 
Page Number:2379 
Line Number:76045-76046 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2016-10-20 17:25 UTC
Last Modified:  2016-10-27 12:43 UTC
== 
Summary:the wordlist production should accept reserved words
but as currently written it does not
== 

-- 
 (0003462) Mark_Galeck (reporter) - 2016-10-27 12:43
 http://austingroupbugs.net/view.php?id=1099#c3462 
-- 
This report is included in the summary report 1100 and can be cancelled. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-10-20 17:25 Mark_GaleckNew Issue
2016-10-20 17:25 Mark_GaleckName  => Mark Galeck 
2016-10-20 17:25 Mark_GaleckSection   => 2.10.2 Shell
Grammar Rules
2016-10-20 17:25 Mark_GaleckPage Number   => 2379
2016-10-20 17:25 Mark_GaleckLine Number   => 76045-76046 
2016-10-27 12:43 Mark_GaleckNote Added: 0003462  
==

[1003.1(2016)/Issue7+TC2 0001100]: Rewrite of Section 2.10 Shell Grammar, of the Shell Standard, to fix previous reports, fix new issues, and improve presentation.

[Austin Group Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://austingroupbugs.net/view.php?id=1100 
== 
Reported By:Mark_Galeck
Assigned To:
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1100
Category:   Shell and Utilities
Type:   Clarification Requested
Severity:   Editorial
Priority:   normal
Status: New
Name:   Mark Galeck 
Organization:
User Reference:  
Section:2.10 Shell Grammar 
Page Number:2375-2381 
Line Number:75873-76150 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2016-10-27 12:40 UTC
Last Modified:  2016-10-27 12:40 UTC
== 
Summary:Rewrite of Section 2.10 Shell Grammar, of the Shell
Standard, to fix previous reports, fix new issues, and improve presentation.
Description: 
I recently made several reports concerning sections 2.10.1/2, and then I
saw at least one more problem of the similar kind.  If I continue making
incremental reports, even if the changes were approved, they will result in
a bigger and bigger mess. 

Therefore I decided to cancel some previous reports, add new issues and
make one summary report, which is a comprehensive rewrite of the whole
Shell Grammar section, to fix the issues I find, as well as make the whole
presentation more straightforward and less convoluted.  


Here is the list of all the specific bugs this report addresses, including
some previous reports.  I am not listing changes here that morely improve
the presentation; to see all the changes, you should probably use some
"diff" program. 



1. Previous reports 1096, 1094, 1097, 1099, 1095, 1092 are included here
and can be cancelled.  

2.  Previous reports 1098, 1093, 1091, 1088 can be cancelled.  Let's say we
classify them as bogus, and those changes are not included here. 


3. (new issue) In the current standard, cmd_word cannot be a reserved word.
It is very convoluted, but if you carefully trace the application of
various rules to each other, you will end up that in fact, cmd_name and
cmd_word follow exactly the same semantics right now, both do not allow
reserved words.  Only cmd_name should not allow reserved words.  


4. (new issue) 

In multiple places in the current standard, rule 1 applies to WORD, and
thus reserved words are not allowed, where all words should be allowed. 
Some of the reports above cover this.  Additionally, we have:

WORD in the case_clause production - currently it cannot be a reserved
word, but it should be allowed to be a reserved word.  

Same for WORD in cmd_suffix production. 



This rewrite is intended only to include the changes mentioned above, and
should otherwise be equivalent to the current standard.

I will be happy to answer any questions, provide clarifications, or fix if
you find any bugs.  

I do not have the time to discuss the merits of the changes.  The
maintainer of this standard is free to reject any part or all of this
report, or to continue to rewrite my Section 2.10 in any way that suits
them.  I completely do not mind.  

Yes the text I provide for the new Section 2.10 is just raw text format, it
does not have hyperlinks and different fonts.  Somebody else would have to
do that.  

Thank you!


Desired Action: 
2.10. Shell Grammar

The following grammar defines the Shell Command Language. This formal
syntax shall take precedence over the preceding text syntax description.

The rules in Token Recognition delimit operator and word tokens.

In order to appear in the grammar as token identifiers, the tokens shall be
classified according to the following rules, applied in the following order
of precedence:


1. The token identifier for any operator, occurs when the token is that
operator.


2. IO_NUMBER is if the string consists solely of digits and the delimiter
character is one of '<' or '>'.


3. This rule only applies in function_body production; see below in the
grammar.

Word expansion and assignment shall never occur, even when required by the
rules below, when this production is being parsed. WORD is each token that
might either be expanded or have assignment applied to it, consisting only
of characters that are exactly described in Token Recognition.
 

4. The token identifier for any reserved word, occurs when the token is
exactly that reserved word.

Note:
Because at this point  characters are retained in the
token, quoted strings cannot be recognized as 

[1003.1(2016)/Issue7+TC2 0001095]: Shell Grammar rule 2 cannot be the only one to apply because it does not assign WORD

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1095 
== 
Reported By:Mark_Galeck
Assigned To:
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1095
Category:   Shell and Utilities
Type:   Error
Severity:   Editorial
Priority:   normal
Status: New
Name:   Mark Galeck 
Organization:
User Reference:  
Section:2.10.2 Shell Grammar Rules 
Page Number:2376, 2380 
Line Number:75911-75914, 76129 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2016-10-20 02:01 UTC
Last Modified:  2016-10-27 12:44 UTC
== 
Summary:Shell Grammar rule 2 cannot be the only one to apply
because it does not assign WORD
== 

-- 
 (0003464) Mark_Galeck (reporter) - 2016-10-27 12:44
 http://austingroupbugs.net/view.php?id=1095#c3464 
-- 
This report is included in the summary report 1100 and can be cancelled. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-10-20 02:01 Mark_GaleckNew Issue
2016-10-20 02:01 Mark_GaleckName  => Mark Galeck 
2016-10-20 02:01 Mark_GaleckSection   => 2.10.2 Shell
Grammar Rules
2016-10-20 02:01 Mark_GaleckPage Number   => 2376, 2380  
2016-10-20 02:01 Mark_GaleckLine Number   => 75911-75914, 76129
2016-10-27 12:44 Mark_GaleckNote Added: 0003464  
==

[1003.1(2016)/Issue7+TC2 0001091]: Some "WORD tokens" do not have "the associated command"

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1091 
== 
Reported By:Mark_Galeck
Assigned To:
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1091
Category:   Shell and Utilities
Type:   Error
Severity:   Editorial
Priority:   normal
Status: New
Name:   Mark Galeck 
Organization:
User Reference:  
Section:2.10.1 Shell Grammar Lexical Conventions 
Page Number:2375 
Line Number:75895-75896 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2016-10-18 11:55 UTC
Last Modified:  2016-10-27 12:46 UTC
== 
Summary:Some "WORD tokens" do not have "the associated
command"
== 

-- 
 (0003468) Mark_Galeck (reporter) - 2016-10-27 12:46
 http://austingroupbugs.net/view.php?id=1091#c3468 
-- 
This report can be cancelled. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-10-18 11:55 Mark_GaleckNew Issue
2016-10-18 11:55 Mark_GaleckName  => Mark Galeck 
2016-10-18 11:55 Mark_GaleckSection   => 2.10.1 Shell
Grammar Lexical Conventions
2016-10-18 11:55 Mark_GaleckPage Number   => 2375
2016-10-18 11:55 Mark_GaleckLine Number   => 75895-75896 
2016-10-18 14:48 geoffclare Note Added: 0003419  
2016-10-18 15:04 Mark_GaleckNote Added: 0003421  
2016-10-18 15:28 Mark_GaleckNote Added: 0003425  
2016-10-18 15:55 geoffclare Note Added: 0003428  
2016-10-19 04:44 Mark_GaleckNote Added: 0003429  
2016-10-19 05:51 kreNote Added: 0003430  
2016-10-27 12:46 Mark_GaleckNote Added: 0003468  
==

[1003.1(2016)/Issue7+TC2 0001093]: "or applies globally" is pointless

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1093 
== 
Reported By:Mark_Galeck
Assigned To:
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1093
Category:   Shell and Utilities
Type:   Clarification Requested
Severity:   Editorial
Priority:   normal
Status: New
Name:   Mark Galeck 
Organization:
User Reference:  
Section:2.10.2 Shell Grammar Rules 
Page Number:2375 
Line Number:75909-75910 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2016-10-18 12:07 UTC
Last Modified:  2016-10-27 12:46 UTC
== 
Summary:"or applies globally" is pointless
==
Relationships   ID  Summary
--
related to  0001088 When more than one rule applies, ...
== 

-- 
 (0003467) Mark_Galeck (reporter) - 2016-10-27 12:46
 http://austingroupbugs.net/view.php?id=1093#c3467 
-- 
This report can be cancelled. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-10-18 12:07 Mark_GaleckNew Issue
2016-10-18 12:07 Mark_GaleckName  => Mark Galeck 
2016-10-18 12:07 Mark_GaleckSection   => 2.10.2 Shell
Grammar Rules
2016-10-18 12:07 Mark_GaleckPage Number   => 2375
2016-10-18 12:07 Mark_GaleckLine Number   => 75909-75910 
2016-10-19 09:17 kreNote Added: 0003432  
2016-10-19 10:52 Mark_GaleckNote Added: 0003436  
2016-10-19 13:45 Don Cragun Note Edited: 0003432 
2016-10-19 13:46 Don Cragun Note Edited: 0003432 
2016-10-19 13:46 Don Cragun Note Edited: 0003432 
2016-10-19 13:47 Don Cragun Note Edited: 0003436 
2016-10-19 15:48 nick   Relationship added   related to 0001088  
2016-10-27 12:46 Mark_GaleckNote Added: 0003467  
==

[1003.1(2016)/Issue7+TC2 0001088]: "When more than one rule applies, the highest numbered rule shall apply " is pointless

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1088 
== 
Reported By:Mark_Galeck
Assigned To:
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1088
Category:   Shell and Utilities
Type:   Clarification Requested
Severity:   Editorial
Priority:   normal
Status: New
Name:   Mark Galeck 
Organization:
User Reference:  
Section:2.10.1 Shell Grammar Lexical Conventions 
Page Number:2375 
Line Number:75892-75893 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2016-10-18 10:58 UTC
Last Modified:  2016-10-27 12:46 UTC
== 
Summary:"When more than one rule applies, the highest
numbered rule shall apply " is pointless
==
Relationships   ID  Summary
--
related to  0001093 or applies globally is poin...
== 

-- 
 (0003469) Mark_Galeck (reporter) - 2016-10-27 12:46
 http://austingroupbugs.net/view.php?id=1088#c3469 
-- 
This report can be cancelled. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-10-18 10:58 Mark_GaleckNew Issue
2016-10-18 10:58 Mark_GaleckName  => Mark Galeck 
2016-10-18 10:58 Mark_GaleckSection   => 2.10.1 Shell
Grammar Lexical Conventions
2016-10-18 10:58 Mark_GaleckPage Number   => 2375
2016-10-18 10:58 Mark_GaleckLine Number   => 75892-75893 
2016-10-19 09:17 kreNote Added: 0003431  
2016-10-19 10:49 Mark_GaleckNote Added: 0003435  
2016-10-19 15:48 nick   Relationship added   related to 0001093  
2016-10-27 12:46 Mark_GaleckNote Added: 0003469  
==

[1003.1(2016)/Issue7+TC2 0001092]: "The reduction shall then proceed" is incorrect

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1092 
== 
Reported By:Mark_Galeck
Assigned To:
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1092
Category:   Shell and Utilities
Type:   Error
Severity:   Editorial
Priority:   normal
Status: New
Name:   Mark Galeck 
Organization:
User Reference:  
Section:2.10.1 Shell Grammar Lexical Conventions 
Page Number:2375 
Line Number:75891-75892 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2016-10-18 12:01 UTC
Last Modified:  2016-10-27 12:44 UTC
== 
Summary:"The reduction shall then proceed" is incorrect
== 

-- 
 (0003465) Mark_Galeck (reporter) - 2016-10-27 12:44
 http://austingroupbugs.net/view.php?id=1092#c3465 
-- 
This report is included in the summary report 1100 and can be cancelled. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-10-18 12:01 Mark_GaleckNew Issue
2016-10-18 12:01 Mark_GaleckName  => Mark Galeck 
2016-10-18 12:01 Mark_GaleckSection   => 2.10.1 Shell
Grammar Lexical Conventions
2016-10-18 12:01 Mark_GaleckPage Number   => 2375
2016-10-18 12:01 Mark_GaleckLine Number   => 75891-75892 
2016-10-19 09:37 kreNote Added: 0003434  
2016-10-19 20:27 Mark_GaleckNote Added: 0003438  
2016-10-27 12:44 Mark_GaleckNote Added: 0003465  
==

[1003.1(2016)/Issue7+TC2 0001098]: do_group symbol cannot be accepted as written, because rule 6 cannot yield Done token

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1098 
== 
Reported By:Mark_Galeck
Assigned To:
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1098
Category:   Shell and Utilities
Type:   Error
Severity:   Editorial
Priority:   normal
Status: New
Name:   Mark Galeck 
Organization:
User Reference:  
Section:2.10.2 Shell Grammar Rules 
Page Number:2379 
Line Number:76091 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2016-10-20 16:56 UTC
Last Modified:  2016-10-27 12:45 UTC
== 
Summary:do_group symbol cannot be accepted as written,
because rule 6 cannot yield Done token
== 

-- 
 (0003466) Mark_Galeck (reporter) - 2016-10-27 12:45
 http://austingroupbugs.net/view.php?id=1098#c3466 
-- 
I do want shware_systems to answer my Questions in my last note.  After
that, this report can be cancelled. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-10-20 16:56 Mark_GaleckNew Issue
2016-10-20 16:56 Mark_GaleckName  => Mark Galeck 
2016-10-20 16:56 Mark_GaleckSection   => 2.10.2 Shell
Grammar Rules
2016-10-20 16:56 Mark_GaleckPage Number   => 2379
2016-10-20 16:56 Mark_GaleckLine Number   => 76091   
2016-10-21 09:23 geoffclare Note Added: 0003448  
2016-10-21 09:24 geoffclare Note Edited: 0003448 
2016-10-21 09:41 geoffclare Note Edited: 0003448 
2016-10-21 21:56 Mark_GaleckNote Added: 0003449  
2016-10-22 08:00 geoffclare Note Added: 0003450  
2016-10-22 08:22 Mark_GaleckNote Added: 0003451  
2016-10-22 10:44 geoffclare Note Added: 0003452  
2016-10-22 12:01 Mark_GaleckNote Added: 0003453  
2016-10-22 12:18 Mark_GaleckNote Added: 0003454  
2016-10-22 12:19 Mark_GaleckNote Edited: 0003454 
2016-10-22 12:19 Mark_GaleckNote Edited: 0003454 
2016-10-22 12:20 Mark_GaleckNote Edited: 0003454 
2016-10-22 12:24 Mark_GaleckNote Edited: 0003453 
2016-10-22 12:29 Mark_GaleckNote Added: 0003455  
2016-10-25 23:16 shware_systems Note Added: 0003457  
2016-10-26 16:32 Mark_GaleckNote Added: 0003458  
2016-10-26 16:39 Mark_GaleckNote Edited: 0003458 
2016-10-26 16:44 Mark_GaleckNote Edited: 0003458 
2016-10-26 16:46 Mark_GaleckNote Edited: 0003458 
2016-10-26 16:51 Mark_GaleckNote Edited: 0003458 
2016-10-27 12:45 Mark_GaleckNote Added: 0003466  
==

[1003.1(2016)/Issue7+TC2 0001094]: Rule 7a is needed to apply to ASSIGNMENT_WORD productions

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1094 
== 
Reported By:Mark_Galeck
Assigned To:
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1094
Category:   Shell and Utilities
Type:   Error
Severity:   Editorial
Priority:   normal
Status: New
Name:   Mark Galeck 
Organization:
User Reference:  
Section:2.10.2 Shell Grammar Rules 
Page Number:2380 
Line Number:76105-76106 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2016-10-18 12:19 UTC
Last Modified:  2016-10-27 12:43 UTC
== 
Summary:Rule 7a is needed to apply to ASSIGNMENT_WORD
productions
== 

-- 
 (0003460) Mark_Galeck (reporter) - 2016-10-27 12:43
 http://austingroupbugs.net/view.php?id=1094#c3460 
-- 
This report is included in the summary report 1100 and can be cancelled. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-10-18 12:19 Mark_GaleckNew Issue
2016-10-18 12:19 Mark_GaleckName  => Mark Galeck 
2016-10-18 12:19 Mark_GaleckSection   => 2.10.2 Shell
Grammar Rules
2016-10-18 12:19 Mark_GaleckPage Number   => 2380
2016-10-18 12:19 Mark_GaleckLine Number   => 76105-76106 
2016-10-19 09:27 kreNote Added: 0003433  
2016-10-19 10:31 kreNote Edited: 0003433 
2016-10-19 20:21 Mark_GaleckNote Added: 0003437  
2016-10-20 08:23 geoffclare Note Added: 0003439  
2016-10-20 09:13 Mark_GaleckNote Added: 0003440  
2016-10-20 09:49 geoffclare Note Added: 0003441  
2016-10-20 12:03 Mark_GaleckNote Added: 0003442  
2016-10-20 12:04 Mark_GaleckNote Edited: 0003442 
2016-10-20 12:07 Mark_GaleckNote Edited: 0003442 
2016-10-20 12:14 Mark_GaleckNote Added: 0003443  
2016-10-20 14:26 geoffclare Note Added: 0003444  
2016-10-27 12:43 Mark_GaleckNote Added: 0003460  
==

[1003.1(2016)/Issue7+TC2 0001097]: Shell Grammar rule 4 is nonsense that conflicts with existing implementations

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1097 
== 
Reported By:Mark_Galeck
Assigned To:
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1097
Category:   Shell and Utilities
Type:   Error
Severity:   Editorial
Priority:   normal
Status: New
Name:   Mark Galeck 
Organization:
User Reference:  
Section:2.10.2 Shell Grammar Rules 
Page Number:2376, 2379 
Line Number:75919, 75920, 76068, 76069 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2016-10-20 15:24 UTC
Last Modified:  2016-10-27 12:43 UTC
== 
Summary:Shell Grammar rule 4 is nonsense that conflicts with
existing implementations
== 

-- 
 (0003461) Mark_Galeck (reporter) - 2016-10-27 12:43
 http://austingroupbugs.net/view.php?id=1097#c3461 
-- 
This report is included in the summary report 1100 and can be cancelled. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-10-20 15:24 Mark_GaleckNew Issue
2016-10-20 15:24 Mark_GaleckName  => Mark Galeck 
2016-10-20 15:24 Mark_GaleckSection   => 2.10.2 Shell
Grammar Rules
2016-10-20 15:24 Mark_GaleckPage Number   => 2376, 2379  
2016-10-20 15:24 Mark_GaleckLine Number   => 75919, 75920,
76068, 76069
2016-10-21 08:32 geoffclare Note Added: 0003447  
2016-10-27 12:43 Mark_GaleckNote Added: 0003461  
==

[1003.1(2013)/Issue7+TC1 0001017]: od -A n and final offset

[Austin Group Bug Tracker]

The following issue has been RESOLVED. 
== 
http://austingroupbugs.net/view.php?id=1017 
== 
Reported By:geoffclare
Assigned To:
== 
Project:1003.1(2013)/Issue7+TC1
Issue ID:   1017
Category:   Shell and Utilities
Type:   Clarification Requested
Severity:   Objection
Priority:   normal
Status: Resolved
Name:   Geoff Clare 
Organization:   The Open Group 
User Reference:  
Section:od 
Page Number:3012 
Line Number:99876-99881 
Interp Status:  --- 
Final Accepted Text: 
Resolution: Accepted
Fixed in Version:   
== 
Date Submitted: 2016-01-04 15:59 UTC
Last Modified:  2016-10-27 15:42 UTC
== 
Summary:od -A n and final offset
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-01-04 15:59 geoffclare New Issue
2016-01-04 15:59 geoffclare Name  => Geoff Clare 
2016-01-04 15:59 geoffclare Organization  => The Open Group  
2016-01-04 15:59 geoffclare Section   => od  
2016-01-04 15:59 geoffclare Page Number   => 3012
2016-01-04 15:59 geoffclare Line Number   => 99876-99881 
2016-01-04 15:59 geoffclare Interp Status => --- 
2016-01-04 16:36 joerg  Note Added: 0002994  
2016-01-04 19:19 shware_systems Note Added: 0002995  
2016-01-05 09:09 geoffclare Note Added: 0002996  
2016-01-06 15:23 joerg  Note Added: 0003011  
2016-10-27 15:42 Don Cragun Status   New => Resolved 
2016-10-27 15:42 Don Cragun Resolution   Open => Accepted
==

[1003.1(2016)/Issue7+TC2 0001098]: do_group symbol cannot be accepted as written, because rule 6 cannot yield Done token

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1098 
== 
Reported By:Mark_Galeck
Assigned To:
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1098
Category:   Shell and Utilities
Type:   Error
Severity:   Editorial
Priority:   normal
Status: New
Name:   Mark Galeck 
Organization:
User Reference:  
Section:2.10.2 Shell Grammar Rules 
Page Number:2379 
Line Number:76091 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2016-10-20 16:56 UTC
Last Modified:  2016-10-25 23:16 UTC
== 
Summary:do_group symbol cannot be accepted as written,
because rule 6 cannot yield Done token
== 

-- 
 (0003457) shware_systems (reporter) - 2016-10-25 23:16
 http://austingroupbugs.net/view.php?id=1098#c3457 
-- 
Maybe this be clearer:

The do_group production has 3 elements, the 2 keyword tokens and the list
production... Rule 6 possibly applies to just the first token, the Do, and
Rule 1 applies to the Done token, as the 3rd and 5th elements of the full
for_clause respectively when the in clause is not present (so the default
"in $@" applies). When an in clause is present Rule 1 applies to both
keyword tokens because as the Do token is no longer the 3rd WORD, In is,
the unmet qualifying clause of Rule 6's "third word" condition leaves Rule
1 as the default that does apply. For the 4 choices of the for_clause the
linebreak and sequential_sep references are significant whitespace for
counting purposes, not operator tokens, so Rule 6b applies to the first 2
with do_group and the in production in the second 2. Rule 6 is necessary to
force 'for' as unquoted text being treated as a keyword and not a simple
command with arguments, in the absence of a sequential_sep as 'best/longest
matching production' to satisfy the command production. A similar ambiguity
exists for 'in' in the case_clause production because of the empty portion
of the linebreak production. This isn't obvious if one is thinking the
grammar matches yacc or another standard's production style.
 
In the rules the square brackets are decorative, just grouping a portion of
the text to indicate narratively where in the productions the rule applies,
as forward references. No one has made them hyperlinks in the pdf or html,
that's all, but they're not commentary. 

The grammar is more 'best match' than 'first match', for h(yste)istorical
reasons, as the for construct and others were originally implemented as
external commands that could be loaded as an extension overlay into the
resident image of shells that only handled simple command parsing and
redirections; a special non-built-in, effectively, for low RAM machines (
See https://en.wikipedia.org/wiki/Thompson_shell ). When shells like the
Bourne shell could keep them resident, because more processors had the
luxury of 16-bit (or more) address buses to shoehorn code into, and added
features that required treatment grammatically other than as arguments the
necessary productions were added to existing text, I believe, not reworked
to match a particular meta-language's translation
requirements/restrictions. Rule 1 applies in the command production to have
the productions involving keywords or operators being best matches as
priority over simple_command, iow.

Something like the above may be suitable for adding to XRAT C.2.10, as a
historical note, but in XCU 2.10 I don't see that changes are required.
What's there is more a meta-meta-language, partly top down, partly bottom
up, but with the rules is internally consistent.

Example:
for varname do ( ) done
parses as a for loop, with '( )' representing a valid subshell
compound-list that does nothing, and fully matches for_clause choice 1;

for varname do \() done
parses as a simple command, 'for'; with 'varname', 'do', '()', and 'done'
as textual arguments,
as '\()' is an invalid compound-list that forces backtracking to
simple_command as best match.

\for varname do ( ) done
also parses as a simple command, but with '(' and ')' as separate
arguments, due to the escaping '\' disabling keyword recognition. 

Issue History 
Date ModifiedUsername   Field

[1003.1(2016)/Issue7+TC2 0001097]: Shell Grammar rule 4 is nonsense that conflicts with existing implementations

[Austin Group Bug Tracker]

The following issue has been CLOSED. 
== 
http://austingroupbugs.net/view.php?id=1097 
== 
Reported By:Mark_Galeck
Assigned To:
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1097
Category:   Shell and Utilities
Type:   Error
Severity:   Editorial
Priority:   normal
Status: Closed
Name:   Mark Galeck 
Organization:
User Reference:  
Section:2.10.2 Shell Grammar Rules 
Page Number:2376, 2379 
Line Number:75919, 75920, 76068, 76069 
Interp Status:  --- 
Final Accepted Text: 
Resolution: Withdrawn
Fixed in Version:   
== 
Date Submitted: 2016-10-20 15:24 UTC
Last Modified:  2016-10-27 18:09 UTC
== 
Summary:Shell Grammar rule 4 is nonsense that conflicts with
existing implementations
== 

-- 
 (0003474) Don Cragun (manager) - 2016-10-27 18:09
 http://austingroupbugs.net/view.php?id=1097#c3474 
-- 
Withdrawn by submitter per http://austingroupbugs.net/view.php?id=1097#c3461 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-10-20 15:24 Mark_GaleckNew Issue
2016-10-20 15:24 Mark_GaleckName  => Mark Galeck 
2016-10-20 15:24 Mark_GaleckSection   => 2.10.2 Shell
Grammar Rules
2016-10-20 15:24 Mark_GaleckPage Number   => 2376, 2379  
2016-10-20 15:24 Mark_GaleckLine Number   => 75919, 75920,
76068, 76069
2016-10-21 08:32 geoffclare Note Added: 0003447  
2016-10-27 12:43 Mark_GaleckNote Added: 0003461  
2016-10-27 18:09 Don Cragun Interp Status => --- 
2016-10-27 18:09 Don Cragun Note Added: 0003474  
2016-10-27 18:09 Don Cragun Status   New => Closed   
2016-10-27 18:09 Don Cragun Resolution   Open => Withdrawn   
==

[1003.1(2016)/Issue7+TC2 0001088]: "When more than one rule applies, the highest numbered rule shall apply " is pointless

[Austin Group Bug Tracker]

The following issue has been CLOSED. 
== 
http://austingroupbugs.net/view.php?id=1088 
== 
Reported By:Mark_Galeck
Assigned To:
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1088
Category:   Shell and Utilities
Type:   Clarification Requested
Severity:   Editorial
Priority:   normal
Status: Closed
Name:   Mark Galeck 
Organization:
User Reference:  
Section:2.10.1 Shell Grammar Lexical Conventions 
Page Number:2375 
Line Number:75892-75893 
Interp Status:  --- 
Final Accepted Text: 
Resolution: Withdrawn
Fixed in Version:   
== 
Date Submitted: 2016-10-18 10:58 UTC
Last Modified:  2016-10-27 18:20 UTC
== 
Summary:"When more than one rule applies, the highest
numbered rule shall apply " is pointless
==
Relationships   ID  Summary
--
related to  0001093 or applies globally is poin...
== 

-- 
 (0003480) Don Cragun (manager) - 2016-10-27 18:20
 http://austingroupbugs.net/view.php?id=1088#c3480 
-- 
Withdrawn by submitter in http://austingroupbugs.net/view.php?id=1088#c3469 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-10-18 10:58 Mark_GaleckNew Issue
2016-10-18 10:58 Mark_GaleckName  => Mark Galeck 
2016-10-18 10:58 Mark_GaleckSection   => 2.10.1 Shell
Grammar Lexical Conventions
2016-10-18 10:58 Mark_GaleckPage Number   => 2375
2016-10-18 10:58 Mark_GaleckLine Number   => 75892-75893 
2016-10-19 09:17 kreNote Added: 0003431  
2016-10-19 10:49 Mark_GaleckNote Added: 0003435  
2016-10-19 15:48 nick   Relationship added   related to 0001093  
2016-10-27 12:46 Mark_GaleckNote Added: 0003469  
2016-10-27 18:20 Don Cragun Interp Status => --- 
2016-10-27 18:20 Don Cragun Note Added: 0003480  
2016-10-27 18:20 Don Cragun Status   New => Closed   
2016-10-27 18:20 Don Cragun Resolution   Open => Withdrawn   
==

[1003.1(2016)/Issue7+TC2 0001094]: Rule 7a is needed to apply to ASSIGNMENT_WORD productions

[Austin Group Bug Tracker]

The following issue has been CLOSED. 
== 
http://austingroupbugs.net/view.php?id=1094 
== 
Reported By:Mark_Galeck
Assigned To:
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1094
Category:   Shell and Utilities
Type:   Error
Severity:   Editorial
Priority:   normal
Status: Closed
Name:   Mark Galeck 
Organization:
User Reference:  
Section:2.10.2 Shell Grammar Rules 
Page Number:2380 
Line Number:76105-76106 
Interp Status:  --- 
Final Accepted Text: 
Resolution: Withdrawn
Fixed in Version:   
== 
Date Submitted: 2016-10-18 12:19 UTC
Last Modified:  2016-10-27 18:08 UTC
== 
Summary:Rule 7a is needed to apply to ASSIGNMENT_WORD
productions
== 

-- 
 (0003473) Don Cragun (manager) - 2016-10-27 18:08
 http://austingroupbugs.net/view.php?id=1094#c3473 
-- 
Withdrawn by submitter as noted in
http://austingroupbugs.net/view.php?id=1094#c3460 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-10-18 12:19 Mark_GaleckNew Issue
2016-10-18 12:19 Mark_GaleckName  => Mark Galeck 
2016-10-18 12:19 Mark_GaleckSection   => 2.10.2 Shell
Grammar Rules
2016-10-18 12:19 Mark_GaleckPage Number   => 2380
2016-10-18 12:19 Mark_GaleckLine Number   => 76105-76106 
2016-10-19 09:27 kreNote Added: 0003433  
2016-10-19 10:31 kreNote Edited: 0003433 
2016-10-19 20:21 Mark_GaleckNote Added: 0003437  
2016-10-20 08:23 geoffclare Note Added: 0003439  
2016-10-20 09:13 Mark_GaleckNote Added: 0003440  
2016-10-20 09:49 geoffclare Note Added: 0003441  
2016-10-20 12:03 Mark_GaleckNote Added: 0003442  
2016-10-20 12:04 Mark_GaleckNote Edited: 0003442 
2016-10-20 12:07 Mark_GaleckNote Edited: 0003442 
2016-10-20 12:14 Mark_GaleckNote Added: 0003443  
2016-10-20 14:26 geoffclare Note Added: 0003444  
2016-10-27 12:43 Mark_GaleckNote Added: 0003460  
2016-10-27 18:08 Don Cragun Interp Status => --- 
2016-10-27 18:08 Don Cragun Note Added: 0003473  
2016-10-27 18:08 Don Cragun Status   New => Closed   
2016-10-27 18:08 Don Cragun Resolution   Open => Withdrawn   
==

[1003.1(2016)/Issue7+TC2 0001095]: Shell Grammar rule 2 cannot be the only one to apply because it does not assign WORD

[Austin Group Bug Tracker]

The following issue has been CLOSED. 
== 
http://austingroupbugs.net/view.php?id=1095 
== 
Reported By:Mark_Galeck
Assigned To:
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1095
Category:   Shell and Utilities
Type:   Error
Severity:   Editorial
Priority:   normal
Status: Closed
Name:   Mark Galeck 
Organization:
User Reference:  
Section:2.10.2 Shell Grammar Rules 
Page Number:2376, 2380 
Line Number:75911-75914, 76129 
Interp Status:  --- 
Final Accepted Text: 
Resolution: Withdrawn
Fixed in Version:   
== 
Date Submitted: 2016-10-20 02:01 UTC
Last Modified:  2016-10-27 18:12 UTC
== 
Summary:Shell Grammar rule 2 cannot be the only one to apply
because it does not assign WORD
== 

-- 
 (0003476) Don Cragun (manager) - 2016-10-27 18:12
 http://austingroupbugs.net/view.php?id=1095#c3476 
-- 
Withdrawn by submitter in http://austingroupbugs.net/view.php?id=1095#c3464 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-10-20 02:01 Mark_GaleckNew Issue
2016-10-20 02:01 Mark_GaleckName  => Mark Galeck 
2016-10-20 02:01 Mark_GaleckSection   => 2.10.2 Shell
Grammar Rules
2016-10-20 02:01 Mark_GaleckPage Number   => 2376, 2380  
2016-10-20 02:01 Mark_GaleckLine Number   => 75911-75914, 76129
2016-10-27 12:44 Mark_GaleckNote Added: 0003464  
2016-10-27 18:12 Don Cragun Interp Status => --- 
2016-10-27 18:12 Don Cragun Note Added: 0003476  
2016-10-27 18:12 Don Cragun Status   New => Closed   
2016-10-27 18:12 Don Cragun Resolution   Open => Withdrawn   
==

[1003.1(2016)/Issue7+TC2 0001092]: "The reduction shall then proceed" is incorrect

[Austin Group Bug Tracker]

The following issue has been CLOSED. 
== 
http://austingroupbugs.net/view.php?id=1092 
== 
Reported By:Mark_Galeck
Assigned To:
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1092
Category:   Shell and Utilities
Type:   Error
Severity:   Editorial
Priority:   normal
Status: Closed
Name:   Mark Galeck 
Organization:
User Reference:  
Section:2.10.1 Shell Grammar Lexical Conventions 
Page Number:2375 
Line Number:75891-75892 
Interp Status:  --- 
Final Accepted Text: 
Resolution: Withdrawn
Fixed in Version:   
== 
Date Submitted: 2016-10-18 12:01 UTC
Last Modified:  2016-10-27 18:13 UTC
== 
Summary:"The reduction shall then proceed" is incorrect
== 

-- 
 (0003477) Don Cragun (manager) - 2016-10-27 18:13
 http://austingroupbugs.net/view.php?id=1092#c3477 
-- 
Withdrawn by submitter in http://austingroupbugs.net/view.php?id=1092#c3465 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-10-18 12:01 Mark_GaleckNew Issue
2016-10-18 12:01 Mark_GaleckName  => Mark Galeck 
2016-10-18 12:01 Mark_GaleckSection   => 2.10.1 Shell
Grammar Lexical Conventions
2016-10-18 12:01 Mark_GaleckPage Number   => 2375
2016-10-18 12:01 Mark_GaleckLine Number   => 75891-75892 
2016-10-19 09:37 kreNote Added: 0003434  
2016-10-19 20:27 Mark_GaleckNote Added: 0003438  
2016-10-27 12:44 Mark_GaleckNote Added: 0003465  
2016-10-27 18:13 Don Cragun Interp Status => --- 
2016-10-27 18:13 Don Cragun Note Added: 0003477  
2016-10-27 18:13 Don Cragun Status   New => Closed   
2016-10-27 18:13 Don Cragun Resolution   Open => Withdrawn   
==

[1003.1(2016)/Issue7+TC2 0001091]: Some "WORD tokens" do not have "the associated command"

[Austin Group Bug Tracker]

The following issue has been CLOSED. 
== 
http://austingroupbugs.net/view.php?id=1091 
== 
Reported By:Mark_Galeck
Assigned To:
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1091
Category:   Shell and Utilities
Type:   Error
Severity:   Editorial
Priority:   normal
Status: Closed
Name:   Mark Galeck 
Organization:
User Reference:  
Section:2.10.1 Shell Grammar Lexical Conventions 
Page Number:2375 
Line Number:75895-75896 
Interp Status:  --- 
Final Accepted Text: 
Resolution: Withdrawn
Fixed in Version:   
== 
Date Submitted: 2016-10-18 11:55 UTC
Last Modified:  2016-10-27 18:19 UTC
== 
Summary:Some "WORD tokens" do not have "the associated
command"
== 

-- 
 (0003479) Don Cragun (manager) - 2016-10-27 18:19
 http://austingroupbugs.net/view.php?id=1091#c3479 
-- 
Withdrawn by submitter in http://austingroupbugs.net/view.php?id=1091#c3468 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-10-18 11:55 Mark_GaleckNew Issue
2016-10-18 11:55 Mark_GaleckName  => Mark Galeck 
2016-10-18 11:55 Mark_GaleckSection   => 2.10.1 Shell
Grammar Lexical Conventions
2016-10-18 11:55 Mark_GaleckPage Number   => 2375
2016-10-18 11:55 Mark_GaleckLine Number   => 75895-75896 
2016-10-18 14:48 geoffclare Note Added: 0003419  
2016-10-18 15:04 Mark_GaleckNote Added: 0003421  
2016-10-18 15:28 Mark_GaleckNote Added: 0003425  
2016-10-18 15:55 geoffclare Note Added: 0003428  
2016-10-19 04:44 Mark_GaleckNote Added: 0003429  
2016-10-19 05:51 kreNote Added: 0003430  
2016-10-27 12:46 Mark_GaleckNote Added: 0003468  
2016-10-27 18:19 Don Cragun Interp Status => --- 
2016-10-27 18:19 Don Cragun Note Added: 0003479  
2016-10-27 18:19 Don Cragun Status   New => Closed   
2016-10-27 18:19 Don Cragun Resolution   Open => Withdrawn   
==

[1003.1(2016)/Issue7+TC2 0001099]: the wordlist production should accept reserved words but as currently written it does not

[Austin Group Bug Tracker]

The following issue has been CLOSED. 
== 
http://austingroupbugs.net/view.php?id=1099 
== 
Reported By:Mark_Galeck
Assigned To:
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1099
Category:   Shell and Utilities
Type:   Error
Severity:   Editorial
Priority:   normal
Status: Closed
Name:   Mark Galeck 
Organization:
User Reference:  
Section:2.10.2 Shell Grammar Rules 
Page Number:2379 
Line Number:76045-76046 
Interp Status:  --- 
Final Accepted Text: 
Resolution: Withdrawn
Fixed in Version:   
== 
Date Submitted: 2016-10-20 17:25 UTC
Last Modified:  2016-10-27 18:10 UTC
== 
Summary:the wordlist production should accept reserved words
but as currently written it does not
== 

-- 
 (0003475) Don Cragun (manager) - 2016-10-27 18:10
 http://austingroupbugs.net/view.php?id=1099#c3475 
-- 
Withdrawn by submitter in http://austingroupbugs.net/view.php?id=1099#c3462 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-10-20 17:25 Mark_GaleckNew Issue
2016-10-20 17:25 Mark_GaleckName  => Mark Galeck 
2016-10-20 17:25 Mark_GaleckSection   => 2.10.2 Shell
Grammar Rules
2016-10-20 17:25 Mark_GaleckPage Number   => 2379
2016-10-20 17:25 Mark_GaleckLine Number   => 76045-76046 
2016-10-27 12:43 Mark_GaleckNote Added: 0003462  
2016-10-27 18:10 Don Cragun Interp Status => --- 
2016-10-27 18:10 Don Cragun Note Added: 0003475  
2016-10-27 18:10 Don Cragun Status   New => Closed   
2016-10-27 18:10 Don Cragun Resolution   Open => Withdrawn   
==

[1003.1(2016)/Issue7+TC2 0001093]: "or applies globally" is pointless

[Austin Group Bug Tracker]

The following issue has been CLOSED. 
== 
http://austingroupbugs.net/view.php?id=1093 
== 
Reported By:Mark_Galeck
Assigned To:
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1093
Category:   Shell and Utilities
Type:   Clarification Requested
Severity:   Editorial
Priority:   normal
Status: Closed
Name:   Mark Galeck 
Organization:
User Reference:  
Section:2.10.2 Shell Grammar Rules 
Page Number:2375 
Line Number:75909-75910 
Interp Status:  --- 
Final Accepted Text: 
Resolution: Withdrawn
Fixed in Version:   
== 
Date Submitted: 2016-10-18 12:07 UTC
Last Modified:  2016-10-27 18:18 UTC
== 
Summary:"or applies globally" is pointless
==
Relationships   ID  Summary
--
related to  0001088 When more than one rule applies, ...
== 

-- 
 (0003478) Don Cragun (manager) - 2016-10-27 18:18
 http://austingroupbugs.net/view.php?id=1093#c3478 
-- 
Withdrawn by submitter in http://austingroupbugs.net/view.php?id=1093#c3467 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-10-18 12:07 Mark_GaleckNew Issue
2016-10-18 12:07 Mark_GaleckName  => Mark Galeck 
2016-10-18 12:07 Mark_GaleckSection   => 2.10.2 Shell
Grammar Rules
2016-10-18 12:07 Mark_GaleckPage Number   => 2375
2016-10-18 12:07 Mark_GaleckLine Number   => 75909-75910 
2016-10-19 09:17 kreNote Added: 0003432  
2016-10-19 10:52 Mark_GaleckNote Added: 0003436  
2016-10-19 13:45 Don Cragun Note Edited: 0003432 
2016-10-19 13:46 Don Cragun Note Edited: 0003432 
2016-10-19 13:46 Don Cragun Note Edited: 0003432 
2016-10-19 13:47 Don Cragun Note Edited: 0003436 
2016-10-19 15:48 nick   Relationship added   related to 0001088  
2016-10-27 12:46 Mark_GaleckNote Added: 0003467  
2016-10-27 18:18 Don Cragun Interp Status => --- 
2016-10-27 18:18 Don Cragun Note Added: 0003478  
2016-10-27 18:18 Don Cragun Status   New => Closed   
2016-10-27 18:18 Don Cragun Resolution   Open => Withdrawn   
==

[1003.1(2013)/Issue7+TC1 0001020]: snprintf: the description of the n argument conflicts with ISO C

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1020 
== 
Reported By:ch3root
Assigned To:
== 
Project:1003.1(2013)/Issue7+TC1
Issue ID:   1020
Category:   System Interfaces
Type:   Error
Severity:   Objection
Priority:   normal
Status: Resolved
Name:   Alexander Cherepanov 
Organization:
User Reference:  
Section:fprintf() description of snprintf() 
Page Number:900 
Line Number:30166-30167 
Interp Status:  --- 
Final Accepted Text:http://austingroupbugs.net/view.php?id=1020#c3482 
Resolution: Accepted As Marked
Fixed in Version:   
== 
Date Submitted: 2016-01-05 16:34 UTC
Last Modified:  2016-11-07 09:21 UTC
== 
Summary:snprintf: the description of the n argument
conflicts with ISO C
==
Relationships   ID  Summary
--
related to  761 Requirement of error for snprintf with ...
== 

-- 
 (0003483) shware_systems (reporter) - 2016-11-07 09:21
 http://austingroupbugs.net/view.php?id=1020#c3483 
-- 
Re: 3020
I agree the language is more vague on details than other parts of the
standard, but I don't see it as particularly sloppy. The point of the '_s'
interfaces is having versions that don't have common security holes like
buffer overruns, so when it says 'fit within' or 'too big' to me the intent
is the implementations >>shall do what's necessary, documented or not<< to
prevent those overruns. It seems there it's left open 'how' to work that
magic so imps, at their discretion, can use their existing code to get it
done or new methods.

Either way could reference the same data in the memory manager free(void *)
has to, to get the value used with malloc() or realloc(), or calculate a
usable size if block chaining/coalescing used. This applies whether the
malloc() calls happen at runtime or when creating object descriptions for
an object file at compile time, for auto or static declarations. On POSIX
systems there's the complexity of supporting dl_sym() too, in some fashion,
for externs exported by libraries, but code exists for that also. The vague
aspect I see is whether the sizes are 'as declared' or 'as allocated to
satisfy alignment practices', not that sizing involves any magic. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-01-05 16:34 ch3rootNew Issue
2016-01-05 16:34 ch3rootName  => Alexander
Cherepanov
2016-01-05 16:34 ch3rootSection   => snprintf
2016-01-05 16:34 ch3rootPage Number   => (page or range of
pages)
2016-01-05 16:34 ch3rootLine Number   => (Line or range of
lines)
2016-01-05 17:49 jsm28  Note Added: 0002999  
2016-01-05 20:07 shware_systems Note Added: 0003000  
2016-01-05 20:18 eblake Relationship added   related to 761  
2016-01-05 22:26 Florian Weimer Issue Monitored: Florian Weimer 
  
2016-01-05 22:35 ch3rootNote Added: 0003006  
2016-01-07 05:02 shware_systems Note Added: 0003014  
2016-01-07 10:37 ch3rootNote Added: 0003016  
2016-01-07 11:43 Vincent LefevreNote Added: 0003018  
2016-01-07 13:51 shware_systems Note Added: 0003019  
2016-01-07 14:14 shware_systems Note Edited: 0003019 
2016-01-08 00:45 random832  Note Added: 0003020  
2016-01-08 02:52 Don Cragun Section  snprintf => fprintf()
description of snprintf()
2016-01-08 02:52 Don Cragun Page Number  (page or range of
pages) => 900
2016-01-08 02:52 Don Cragun Line Number  (Line or range of
lines) => 30166-30167
2016-01-08 02:52 Don Cragun Interp Status => ---