[Issue 8 drafts 0001556]: clarify meaning of \n used in a bracket expression in a sed context address or s-command

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been SUBMITTED. 
== 
https://www.austingroupbugs.net/view.php?id=1556 
== 
Reported By:calestyo
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1556
Category:   Shell and Utilities
Type:   Clarification Requested
Severity:   Objection
Priority:   normal
Status: New
Name:   Christoph Anton Mitterer 
Organization:
User Reference:  
Section:Utilities, sed / 9.3.5 RE Bracket Expression 
Page Number:- 
Line Number:- 
Final Accepted Text: 
== 
Date Submitted: 2022-01-18 01:07 UTC
Last Modified:  2022-01-18 01:07 UTC
== 
Summary:clarify meaning of \n used in a bracket expression
in a sed context address or s-command
Description: 
The description of RE Bracket Expressions themselves says:
»When the bracket expression appears within a BRE, the special characters
'.', '*', '[', and '\\' (, , , and
, respectively) shall lose their special meaning within the
bracket expression.
When the bracket expression appears within an ERE, the special characters
'.', '(', '*', '+', '?', '{', '|', '$', '[', and '\\' (,
, , , , ,
, , , and ,
respectively) shall lose their special meaning within the bracket
expression;  ('^') shall lose its special meaning as an
anchor.«
(line 5840, draft)


OTOH, "Regular Expressions in sed" says:
»The escape sequence '\n' shall match a  embedded in the pattern
space. A
literal  shall not be used in the RE of a context address or in
the substitute
function.«
(line 106092, draft)


There is no mentioning which of the two wins, i.e. whether [\n] in a sed
context address or s-command would be the bracket expression of a single
newline, or that of a '\' and a 'n'.

GNU sed for example seems to consider it a newline.


This is somewhat related to Issue 0001551, which also deals with similar
ambiguities with respect to how REs are parsed in sed.
Desired Action: 
Clarify at least in the sed section (or ideally in both places) how '\n' in
a bracket expression is to be interpreted.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2022-01-18 01:07 calestyo   New Issue
2022-01-18 01:07 calestyo   Name  => Christoph Anton
Mitterer
2022-01-18 01:07 calestyo   Section   => Utilities, sed /
9.3.5 RE Bracket Expression
2022-01-18 01:07 calestyo   Page Number   => -   
2022-01-18 01:07 calestyo   Line Number   => -   
==

[1003.1(2016/18)/Issue7+TC2 0001552]: minor improvement in the description of […] in pattern matching notation

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been CLOSED. 
== 
https://austingroupbugs.net/view.php?id=1552 
== 
Reported By:calestyo
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1552
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Editorial
Priority:   normal
Status: Closed
Name:   Christoph Anton Mitterer 
Organization:
User Reference:  
Section:2.13.1 Patterns Matching a Single Character 
Page Number:- 
Line Number:- 
Interp Status:  --- 
Final Accepted Text: 
Resolution: Duplicate
Duplicate:  0
Fixed in Version:   
== 
Date Submitted: 2022-01-14 23:55 UTC
Last Modified:  2022-01-18 00:34 UTC
== 
Summary:minor improvement in the description of […] in
pattern matching notation
==
Relationships   ID  Summary
--
duplicate of985 quote removal missing from case stateme...
== 

-- 
 (0005620) Don Cragun (manager) - 2022-01-18 00:34
 https://austingroupbugs.net/view.php?id=1552#c5620 
-- 
Closed as requested by submitter. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2022-01-14 23:55 calestyo   New Issue
2022-01-14 23:55 calestyo   Name  => Christoph Anton
Mitterer
2022-01-14 23:55 calestyo   Section   => 2.13.1 Patterns
Matching a Single Character
2022-01-14 23:55 calestyo   Page Number   => -   
2022-01-14 23:55 calestyo   Line Number   => -   
2022-01-17 10:33 geoffclare Note Added: 0005615  
2022-01-17 10:34 geoffclare Relationship added   duplicate of 985
2022-01-17 18:49 calestyo   Note Added: 0005619  
2022-01-18 00:34 Don Cragun Interp Status => --- 
2022-01-18 00:34 Don Cragun Note Added: 0005620  
2022-01-18 00:34 Don Cragun Status   New => Closed   
2022-01-18 00:34 Don Cragun Resolution   Open => Duplicate   
==

Re: what variables are affected by the "allexport" shell option?

[Robert Elz via austin-group-l at The Open Group]

Date:Sun, 16 Jan 2022 20:26:00 +
From:"Martijn Dekker via austin-group-l at The Open Group" 

Message-ID:  <409b0a89-6fe1-d688-23f9-8c918ef89...@inlv.org>


  | I need some clarity. Should ${var:=value} and ${var=value} honour 
  | allexport?

Yes.

Any assignment (in the usual sense of that word) to a variable while -a is
in effect should result in the variable being exported, no matter how
it is accomplished.   Further in draft 2.1 it actually says:

  When this option is on, a variable that is assigned a value
 (see XBD Section 4.23),

[that xref is prehaps unfortunate, it really is not needed here as:]

  including variables that are assigned a value by the
  getopts, read, or cd utilities,

[those things are not variable assignments within the meaning of XBD 4.23]

  shall cause that variable to gain the export attribute.

But the fact that they're included makes it clear that any assignment
to a variable counts (even the absurd _ variable, which fortunately
is not posix, but is supported by ksh versions, and to varying extents
by most other shells).   Assignments performed as a side effect of
word expansions are certainly included.

Another case worth checking is unset var; set -a; echo $(( var=3 ));
and verify that after that, var is exported ($SHELL -c 'echo $var').

It might be worth appending to the "including variables..." clause
above:
and also including side effects of parameter and arithmetic expansions,


What follows has nothing to do with -a, but another aspect of ${var=value}

What is less clear about ${var=value} (and the form with the : as
well of course) is whether the assignemnt, when it is performed, ought
to be considered as a XBD 4.23 type variable assignment, with everything
that comes with that (including the rules for how tilde expansion happens).
IMO it should, it is absurd that (in many shells) and given

unset var

as a precondition, that

var=value
and
: ${var=value}

can result in different final settings for "var" (ie: "${var}" will
often expand differently).

Since the latter is a very frequently used shorthand for

if [ -z "${var+set}" ]; then var=value; fi

I believe it would be a very good idea to ensure that those two
forms produce identical results.

The standard cannot really require this at the minute, as too many
shells don't expand the "value" word the same way in the simple
assignment and the word expansion assignment - but it can make it
clear that either is acceptable, and recommend that they be expanded
the same way (while cautioning users that it is not currently guaranteed).
A "future directions" would be good too.

Implementors should really be making the two equivalent, regardless of
what the standard says, as anything else is simply incomprehensible to
the average user.

kre

[1003.1(2016/18)/Issue7+TC2 0001555]: -a/allexport spec should cover ${var=value} and ${var:=value}

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been SUBMITTED. 
== 
https://www.austingroupbugs.net/view.php?id=1555 
== 
Reported By:McDutchie
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1555
Category:   Shell and Utilities
Type:   Clarification Requested
Severity:   Editorial
Priority:   normal
Status: New
Name:   Martijn Dekker 
Organization:   ksh 93u+m  
User Reference:  
Section:XCU 2.14 
Page Number:2381 
Line Number:77125-77127 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2022-01-17 22:32 UTC
Last Modified:  2022-01-17 22:32 UTC
== 
Summary:-a/allexport spec should cover ${var=value} and
${var:=value}
Description: 
It is currently not mentioned what effect, if any, the -a/allexport shell
option should have on expansions of the form ${var=value} and
${var:=value}, nor is this explicitly unspecified.

Both the current draft phrase "Set the export attribute for all variable
assignments", and the current release phrase "When this option is on, the
export attribute shall be set for each variable to which an assignment is
performed", seem to suggest that these expansions should cause the
variable's export attribute to be set if they perform an assignment.

However, the subsequent reference to XBD Section 4.23, clarifying what is
meant by a variable assignment, seems to contradict that, as (both in the
release and the draft) that section only covers assignments of the form
"var=value".

According to my testing, today's situation is that all current shells
except ksh93, pdksh, mksh, and yash do set the export attribute for
assignments performed via ${var=value} and ${var:=value} if the
-a/allexport option is on.

In my view, the ksh93/pdksh/mksh/yash behaviour is a bug, and I would like
to fix ksh93 and report the bug to the other shells' maintainers. But I
think the standard's intention needs to be clarified.
Desired Action: 
Possible resolutions that I can see (apologies for not coming up with an
exact wording, I do not feel competent in that department):

* Amend the -a/allexport description to refer to both XBD 4.23 and default
value assignments via parameter expansions per XCU 2.6.2.

* Amend the definition of assignments in XBD 4.23 to include default value
assignments via parameter expansions per XCU 2.6.2.

* After line 77127, add a sentence clarifying that it is unspecified
whether this option causes variables that are assigned a default value via
a parameter expansion to be exported. (Not the option I would prefer.)

== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2022-01-17 22:32 McDutchie  New Issue
2022-01-17 22:32 McDutchie  Name  => Martijn Dekker  
2022-01-17 22:32 McDutchie  Organization  => ksh 93u+m

2022-01-17 22:32 McDutchie  Section   => XCU 2.14
2022-01-17 22:32 McDutchie  Page Number   => 2381
2022-01-17 22:32 McDutchie  Line Number   => 77125-77127 
==

[1003.1(2016/18)/Issue7+TC2 0001552]: minor improvement in the description of […] in pattern matching notation

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1552 
== 
Reported By:calestyo
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1552
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Editorial
Priority:   normal
Status: New
Name:   Christoph Anton Mitterer 
Organization:
User Reference:  
Section:2.13.1 Patterns Matching a Single Character 
Page Number:- 
Line Number:- 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2022-01-14 23:55 UTC
Last Modified:  2022-01-17 18:49 UTC
== 
Summary:minor improvement in the description of […] in
pattern matching notation
==
Relationships   ID  Summary
--
duplicate of985 quote removal missing from case stateme...
== 

-- 
 (0005619) calestyo (reporter) - 2022-01-17 18:49
 https://austingroupbugs.net/view.php?id=1552#c5619 
-- 
Formulation there seems fine and solve the issue from here as well. So I
agree that this should be closed. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2022-01-14 23:55 calestyo   New Issue
2022-01-14 23:55 calestyo   Name  => Christoph Anton
Mitterer
2022-01-14 23:55 calestyo   Section   => 2.13.1 Patterns
Matching a Single Character
2022-01-14 23:55 calestyo   Page Number   => -   
2022-01-14 23:55 calestyo   Line Number   => -   
2022-01-17 10:33 geoffclare Note Added: 0005615  
2022-01-17 10:34 geoffclare Relationship added   duplicate of 985
2022-01-17 18:49 calestyo   Note Added: 0005619  
==

[1003.1(2016/18)/Issue7+TC2 0001553]: find has two references to -n option that should be about -name

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1553 
== 
Reported By:andras_farkas
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1553
Category:   Shell and Utilities
Type:   Error
Severity:   Editorial
Priority:   normal
Status: New
Name:   Andras Farkas 
Organization:
User Reference:  
Section:find 
Page Number: 
Line Number: 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2022-01-17 03:05 UTC
Last Modified:  2022-01-17 18:42 UTC
== 
Summary:find has two references to -n option that should be
about -name
==
Relationships   ID  Summary
--
related to  0001031 Add -iname (case-insensitive name searc...
== 

-- 
 (0005618) andras_farkas (reporter) - 2022-01-17 18:42
 https://austingroupbugs.net/view.php?id=1553#c5618 
-- 
I see: thanks for pointing out bug 1031 to me.
I'd prefer the 2nd option, myself, for I feel bug fixes are generally
useful. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2022-01-17 03:05 andras_farkas  New Issue
2022-01-17 03:05 andras_farkas  Name  => Andras Farkas   
2022-01-17 03:05 andras_farkas  Section   => find
2022-01-17 10:00 geoffclare Note Added: 0005614  
2022-01-17 10:00 geoffclare Relationship added   related to 0001031  
2022-01-17 18:42 andras_farkas  Note Added: 0005618  
==

Re: [Issue 8 drafts 0001505]: Make doesn't seem to specify unset macro expansion behaviour

[Geoff Clare via austin-group-l at The Open Group]

Quentin Rameau wrote, on 17 Jan 2022:
>
> > A NOTE has been added to this issue. 
> > == 
> > https://austingroupbugs.net/view.php?id=1505 
> 
> Maybe we should use a different wording for qualifying the macro state,
> like “being set” and “unset” (or “not set”) instead of existing and
> not existing).
> 
> What do you think?

I used the "exist" phrasing in the proposal because it matches the
wording used for other additions to the make page in Issue 8 that have
already been applied, e.g. from bug 330.

-- 
Geoff Clare 
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England

Re: POSIX gettext() and uselocale()

[Bruno Haible via austin-group-l at The Open Group]

Geoff Clare wrote:
> The current draft says:
> 
> The returned string may be invalidated by a subsequent call to
> bind_textdomain_codeset(), bindtextdomain(), setlocale(), or
> textdomain() in the same process, or a subsequent call to
> uselocale() in the same thread, except for calls that only query
> values.
> 
> [...]
> 
> > I think that specifying gettext() to be so restricted is not useful.
> > It would make more sense to allow concurrent uselocale() calls.
> 
> The current draft text allows concurrent uselocale() calls.

This is better; thanks. Still, I don't think it is sufficient nor consistent.

OBJECTION 1:
  It requires applications to delegate some calls to separate threads.
  For example, take an application that regularly updates some UI and
  also occasionally writes an JSON file.

  For the UI updates, it will need to call gettext(). Let's assume that
  the UI caches the string the strings that the application passes it,
  e.g. for fast rerendering. This is the typical way a UI is built. E.g.
  Gtk+:   label1 = gtk_label_new (gettext ("Hello, world!"));
  Qt: label1 = new QLabel (gettext ("Hello, world!"), panel);

  For writing data in JSON format [1], it needs to convert
- strings to UTF-8 encoding,
- numbers to decimal representation, with '.' as decimal separator.
  For converting numbers to decimal, since the standard has strtod()
  but no strtod_l() [2], the most immediate implementation is to use
  uselocale() with a "C" locale argument, then call strtod(), then
  switch back to the previous locale using uselocale().

  With the current wording, converting a number to decimal like this
  will invalidate many of the strings that the UI is holding.

  Thus, the application will need to move its JSON file writing to a
  separate thread. This is a big architectural requirement.

OBJECTION 2:
  It is inconsistent with other parts of POSIX. For localeconv() [3]
  the wording is
"... might be overwritten by subsequent calls to setlocale() with the
 categories LC_ALL, LC_MONETARY, or LC_NUMERIC, or by calls to
 uselocale() which change the categories LC_MONETARY or LC_NUMERIC."

  To make things consistent, you would need to change the text for gettext
  from
"call to uselocale() in the same thread"
  to
"call to uselocale() in the same thread which changes the category
 LC_MESSAGES (for gettext(), gettext_l(), dgettext(), dgettext_l())
 respectively the locale passed to dcgettext(), dcgettext_l()"

Bruno

[1] https://datatracker.ietf.org/doc/html/rfc8259
[2] https://pubs.opengroup.org/onlinepubs/9699919799/functions/strtod.html
[3] https://pubs.opengroup.org/onlinepubs/9699919799/functions/localeconv.html

Re: [Issue 8 drafts 0001505]: Make doesn't seem to specify unset macro expansion behaviour

[Quentin Rameau via austin-group-l at The Open Group]

Hello,

> A NOTE has been added to this issue. 
> == 
> https://austingroupbugs.net/view.php?id=1505 

Maybe we should use a different wording for qualifying the macro state,
like “being set” and “unset” (or “not set”) instead of existing and
not existing).

What do you think?

Re: POSIX gettext() and uselocale()

[Geoff Clare via austin-group-l at The Open Group]

Bruno Haible wrote, on 16 Jan 2022:
>
> [First sent on 2021-05-03. Resending because it has not been handled.]

It has been handled.  This is how I reported the change to
austin-group-l on 25th May 2021 (in a reply to Jilles Tjoelker):

| In yesterday's teleconference we updated the proposed text to say
| that the returned string may be invalidated by a subsequent call to
| uselocale() in the same thread (and clarified that for the other
| functions it's a subsequent call in the same process).

> https://posix.rhansen.org/p/gettext_draft
> says (line 358):
> 
>   "The returned string may be invalidated by a subsequent call to
>bind_textdomain_codeset(), bindtextdomain(), setlocale(),
>textdomain(), or uselocale()."

The current draft says:

The returned string may be invalidated by a subsequent call to
bind_textdomain_codeset(), bindtextdomain(), setlocale(), or
textdomain() in the same process, or a subsequent call to
uselocale() in the same thread, except for calls that only query
values.

[...]

> I think that specifying gettext() to be so restricted is not useful.
> It would make more sense to allow concurrent uselocale() calls.

The current draft text allows concurrent uselocale() calls.

-- 
Geoff Clare 
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England

[1003.1(2016/18)/Issue7+TC2 0001527]: cd requires the impossible on standard output

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1527 
== 
Reported By:kre
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1527
Category:   Shell and Utilities
Type:   Error
Severity:   Objection
Priority:   normal
Status: New
Name:   Robert Elz 
Organization:
User Reference:  
Section:XCU 4 / cd 
Page Number:2563 
Line Number:83023-83027 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2021-10-28 00:24 UTC
Last Modified:  2022-01-17 12:21 UTC
== 
Summary:cd requires the impossible on standard output
== 

-- 
 (0005617) geoffclare (manager) - 2022-01-17 12:21
 https://austingroupbugs.net/view.php?id=1527#c5617 
-- 
I did some testing and saw two behaviours when the current dir can't be
determined:

In /bin/sh on Solaris 11.4 (a version of ksh93), cd writes nothing

In /bin/sh on macOS (bash 3), cd writes the pathname it passed to chdir()

These seem to me to be the only two reasonable behaviours, so I think
instead of saying "it is unspecified what, if anything, is written to the
standard output", I would prefer that the new text allows only those two
choices.

We should perhaps also add some application usage text warning that
applications should not assume that the pathname written by cd will always
be an absolute pathname. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2021-10-28 00:24 kreNew Issue
2021-10-28 00:24 kreName  => Robert Elz  
2021-10-28 00:24 kreSection   => XCU 4 / cd  
2021-10-28 00:24 krePage Number   => 2563
2021-10-28 00:24 kreLine Number   => 83023-83027 
2022-01-17 12:21 geoffclare Note Added: 0005617  
==

[Issue 8 drafts 0001505]: Make doesn't seem to specify unset macro expansion behaviour

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1505 
== 
Reported By:quinq
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1505
Category:   Shell and Utilities
Type:   Omission
Severity:   Comment
Priority:   normal
Status: Under Review
Name:   Quentin Rameau 
Organization:
User Reference:  
Section:EXTENDED DESCRIPTION 
Page Number:2935 
Line Number:98369 
Final Accepted Text:https://austingroupbugs.net/view.php?id=1505#c5549 
== 
Date Submitted: 2021-08-10 10:14 UTC
Last Modified:  2022-01-17 11:42 UTC
== 
Summary:Make doesn't seem to specify unset macro expansion
behaviour
== 

-- 
 (0005616) geoffclare (manager) - 2022-01-17 11:42
 https://austingroupbugs.net/view.php?id=1505#c5616 
-- 
In the Jan 13 teleconference it was decided that we should change to a
resolution that requires unset macros to expand to an empty string, and
deals with the issue of unexpectedly set/unset macros entirely in
non-normative text.  I took an action to propose new wording and this is my
proposal...

All page and line numbers are for Issue 8 draft 2.1.

On page 2943 line 98732 change:that completely matches the
[op]%[os] pattern on the left hand sideto:that
completely matches, in a case-sensitive manner, the [op]%[os] pattern on
the left hand side
On page 2944 line 98750 change:If the original value of the
variable named by string1 is an empty string, the final result shall
be an empty string. Matching shall be
case-sensitive.to:In all forms of macro expansion,
if the value of the macro named by string1 is an empty string, or if
the macro named by string1 does not exist, the final result shall be
an empty string.

Note:It is not safe to assume that a macro which has not
intentionally been set to a specific value will not exist. See APPLICATION
USAGE for more information.
On page 2951 after line 99038, add the following new paragraphs to
APPLICATION USAGE:Although make expands macros that do
not exist to an empty string, makefile authors should be aware that it is
not safe to assume that a macro which has not intentionally been set to a
specific value will expand to an empty string for everyone who uses the
makefile. There are two reasons for this:

1. When another user executes make, they might happen to have an
environment variable of the same name (which they have set for some
unrelated purpose) with a non-empty value.

2. A different implementation of make (or a later version of the
same implementation) might have a non-empty value for the macro in its
default set.

This is one aspect of a more general problem, which is that any macro that
is not one for which this standard requires a default value, and is not
explicitly set either in the makefile or on the make command line,
can have an unexpected value (or unexpectedly not exist) when the makefile
is used by a different user or with a different make
implementation.

For this reason, it is recommended that makefile authors do not design
makefile schemes in which values for non-standard macros are obtained from
the user's environment variables. Safer methods of allowing users to
configure macro values include:

* Setting the macros to default values in a make include file where
the user can edit the values.

* Executing make from one or more wrapper scripts which set macro
values on the command line (and which do not obtain those values from
environment variables).

Makefile authors who follow this recommendation may wish to check for any
macros they have overlooked by using a make implementation that
provides, as an extension, a command-line option that causes make to
report attempts to expand (or append to) macros that do not exist.  Users
of makefiles written by others can also benefit from use of such an option
to detect the opposite problem (where the author had a macro being set from
an environment variable but the user does not have the variable set). This
can avoid misbehaviors that would otherwise be hard to debug, such as a
file-processing utility reading from standard input because it was not
given any pathnames to process.

Makefile authors who choose not to follow the 

[1003.1(2016/18)/Issue7+TC2 0001552]: minor improvement in the description of […] in pattern matching notation

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been set as DUPLICATE OF issue 985. 
== 
https://austingroupbugs.net/view.php?id=1552 
== 
Reported By:calestyo
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1552
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Editorial
Priority:   normal
Status: New
Name:   Christoph Anton Mitterer 
Organization:
User Reference:  
Section:2.13.1 Patterns Matching a Single Character 
Page Number:- 
Line Number:- 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2022-01-14 23:55 UTC
Last Modified:  2022-01-17 10:34 UTC
== 
Summary:minor improvement in the description of […] in
pattern matching notation
==
Relationships   ID  Summary
--
duplicate of985 quote removal missing from case stateme...
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2022-01-14 23:55 calestyo   New Issue
2022-01-14 23:55 calestyo   Name  => Christoph Anton
Mitterer
2022-01-14 23:55 calestyo   Section   => 2.13.1 Patterns
Matching a Single Character
2022-01-14 23:55 calestyo   Page Number   => -   
2022-01-14 23:55 calestyo   Line Number   => -   
2022-01-17 10:33 geoffclare Note Added: 0005615  
2022-01-17 10:34 geoffclare Relationship added   duplicate of 985
==

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

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The issue 0001552 has been set as DUPLICATE OF the following issue. 
== 
https://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: Applied
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:See
https://austingroupbugs.net/view.php?id=985#c4562. 
Resolution: Accepted As Marked
Fixed in Version:   
== 
Date Submitted: 2015-09-17 19:22 UTC
Last Modified:  2019-11-28 12:08 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
related to  0001234 in most shells, backslash doesn't have ...
has duplicate   0001552 minor improvement in the description of...
related to  0001190 backslash has two special meanings in t...
== 

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 

[1003.1(2016/18)/Issue7+TC2 0001552]: minor improvement in the description of […] in pattern matching notation

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1552 
== 
Reported By:calestyo
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1552
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Editorial
Priority:   normal
Status: New
Name:   Christoph Anton Mitterer 
Organization:
User Reference:  
Section:2.13.1 Patterns Matching a Single Character 
Page Number:- 
Line Number:- 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2022-01-14 23:55 UTC
Last Modified:  2022-01-17 10:33 UTC
== 
Summary:minor improvement in the description of […] in
pattern matching notation
== 

-- 
 (0005615) geoffclare (manager) - 2022-01-17 10:33
 https://austingroupbugs.net/view.php?id=1552#c5615 
-- 
This problem has already been fixed by bug
https://austingroupbugs.net/view.php?id=985. This bug should be
closed as a dup of 985. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2022-01-14 23:55 calestyo   New Issue
2022-01-14 23:55 calestyo   Name  => Christoph Anton
Mitterer
2022-01-14 23:55 calestyo   Section   => 2.13.1 Patterns
Matching a Single Character
2022-01-14 23:55 calestyo   Page Number   => -   
2022-01-14 23:55 calestyo   Line Number   => -   
2022-01-17 10:33 geoffclare Note Added: 0005615  
==

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

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been set as RELATED TO issue 0001553. 
== 
https://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: Applied
Name:   DannyNiu/NJF 
Organization:
User Reference:  
Section:The 'find' utility.  
Page Number:2761-2770 
Line Number:90443-90860 
Interp Status:  --- 
Final Accepted Text:https://austingroupbugs.net/view.php?id=1031#c3559 
Resolution: Accepted As Marked
Fixed in Version:   
== 
Date Submitted: 2016-03-07 03:21 UTC
Last Modified:  2020-04-14 15:19 UTC
== 
Summary:Add -iname (case-insensitive name search) to the
find utility.
==
Relationships   ID  Summary
--
related to  0001553 find has two references to -n option th...
== 

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   =>
https://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
2017-02-16 16:34 geoffclare Tag Attached: issue8 
2020-04-14 15:19 geoffclare Status   Resolved => Applied 
2022-01-17 10:00 geoffclare Relationship added   related to 0001553  
==

[1003.1(2016/18)/Issue7+TC2 0001553]: find has two references to -n option that should be about -name

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been set as RELATED TO issue 0001031. 
== 
https://austingroupbugs.net/view.php?id=1553 
== 
Reported By:andras_farkas
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1553
Category:   Shell and Utilities
Type:   Error
Severity:   Editorial
Priority:   normal
Status: New
Name:   Andras Farkas 
Organization:
User Reference:  
Section:find 
Page Number: 
Line Number: 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2022-01-17 03:05 UTC
Last Modified:  2022-01-17 10:00 UTC
== 
Summary:find has two references to -n option that should be
about -name
==
Relationships   ID  Summary
--
related to  0001031 Add -iname (case-insensitive name searc...
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2022-01-17 03:05 andras_farkas  New Issue
2022-01-17 03:05 andras_farkas  Name  => Andras Farkas   
2022-01-17 03:05 andras_farkas  Section   => find
2022-01-17 10:00 geoffclare Note Added: 0005614  
2022-01-17 10:00 geoffclare Relationship added   related to 0001031  
==

[1003.1(2016/18)/Issue7+TC2 0001553]: find has two references to -n option that should be about -name

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1553 
== 
Reported By:andras_farkas
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1553
Category:   Shell and Utilities
Type:   Error
Severity:   Editorial
Priority:   normal
Status: New
Name:   Andras Farkas 
Organization:
User Reference:  
Section:find 
Page Number: 
Line Number: 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2022-01-17 03:05 UTC
Last Modified:  2022-01-17 10:00 UTC
== 
Summary:find has two references to -n option that should be
about -name
== 

-- 
 (0005614) geoffclare (manager) - 2022-01-17 10:00
 https://austingroupbugs.net/view.php?id=1553#c5614 
-- 
These problems have been fixed in the Issue 8 drafts as a side-effect of
adding the -iname primary. See bug https://austingroupbugs.net/view.php?id=1031.

The are two options for handling this new bug:

1. Close it as a dup of 1031.

2. Resolve it with the same change that was made in 1031 but omitting
-iname, and tag it tc3-2008.

Effectively the only difference between these options is what would happen
in the unlikely event that we end up doing a TC3. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2022-01-17 03:05 andras_farkas  New Issue
2022-01-17 03:05 andras_farkas  Name  => Andras Farkas   
2022-01-17 03:05 andras_farkas  Section   => find
2022-01-17 10:00 geoffclare Note Added: 0005614  
==