Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching
On 03/07/2019 15:27, Geoff Clare wrote: Harald van Dijk wrote, on 03 Jul 2019: On 03/07/2019 11:08, Geoff Clare wrote: Stephane Chazelas wrote, on 03 Jul 2019: 2019-07-03 09:24:10 +0100, Geoff Clare: [...] [...] If any character (ordinary, shell special, or pattern special) is quoted or (where shell quoting is not in effect) escaped with a , that pattern shall match the character itself. [...] [...] And again, that's an incompatible change for dash, ksh88, ksh93, pdksh, mksh, bosh, yash where: a='\*' ls -ld $a lists the files that start with \ Which is inconsistent with find, pax, fnmatch() and glob(). I thought the new wording you proposed would require this to list the files that start with \, as this is a context where shell quoting is in effect, No, it's a context where shell-quoting backslash *doesn't* work. Therefore the backslash should act as an escape character just like in find, pax, fnmatch() and glob(). It's not about shell quoting the backslash, it's about whether shell quoting can be used on the asterisk. The quoted sentence says that if shell quoting cannot be used on the asterisk, then it can be escaped with a backslash instead. But shell quoting can be used on the asterisk: just try a='*' ls -ld "$a" This does work for listing only a file literally named '*'. Cheers, Harald van Dijk
[1003.1(2016)/Issue7+TC2 0001267]: sh HOME should not be UP shaded
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=1267 == Reported By:dennisw Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1267 Category: Shell and Utilities Type: Error Severity: Comment Priority: normal Status: New Name: Dennis Wölfing Organization: User Reference: Section:sh Page Number:3228 Line Number:108396-108397 Interp Status: --- Final Accepted Text: == Date Submitted: 2019-07-03 15:24 UTC Last Modified: 2019-07-03 16:22 UTC == Summary:sh HOME should not be UP shaded == -- (0004470) shware_systems (reporter) - 2019-07-03 16:22 http://austingroupbugs.net/view.php?id=1267#c4470 -- I believe it is UP shaded because embedded systems may not maintain a getpwnam() file, and take advantage of the unspecified behavior allowance of HOME being unset to replace the tilde with an arbitrary absolute path constant. Systems conforming to the UP option are required to maintain that file, I believe, so a valid value for HOME is always plausible and shouldn't be unset, or even a null string. Issue History Date ModifiedUsername FieldChange == 2019-07-03 15:24 denniswNew Issue 2019-07-03 15:24 denniswName => Dennis Wölfing 2019-07-03 15:24 denniswSection => sh 2019-07-03 15:24 denniswPage Number => 3228 2019-07-03 15:24 denniswLine Number => 108396-108397 2019-07-03 16:22 shware_systems Note Added: 0004470 ==
Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching
Stephane Chazelas wrote, on 03 Jul 2019: > > Before (Bourne/ksh88...) it was: > > *, ? and [...] are wildcard operators and quoting can be used to > remove their special meaning. > > Which applies to both shell and fnmatch() (where quoting is done > with \). > > With your proposed change, the sh documentation has to be > changed to: > > *, ? and [...] are wildcard operators and quoting can be used to > remove their special meaning, but an unquoted backslash (as can > be produced by leaving a word expansion unquoted) can also be > used to escape the following character if any (unspecified if > there's no following character), but bearing in mind that in the > pathname expansion case, it only happens for words that contain > an unquoted and unescaped (with that unquoted \ character) > wildcard operator (unspecified if [ is not matched by an > unquoted unescaped ] in the same path component)... I think you have deliberately come up with as bad a modification as you could. Obviously it could be made much clearer and easier to read. A lot of the added complexity applies equally to direct patterns, and is already needed. If that stuff is added (or already exists in some form) somewhere that applies to both direct and indirect patterns, then all that would be needed to this part is: *, ? and [...] are wildcard operators and quoting can be used to remove their special meaning. In contexts where the pattern is not affected by shell quoting, only a preceding backslash can be used. although it might be helpful to the reader to include the "(such as ...)" by way of illustration. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching
Just being picky, re:
"Arguments to find, pax, fnmatch() and glob() are others."
at the bottom, which to me should be:
"Arguments to exec('find',...), exec('pax',...), fnmatch() and glob() are
others."
as parameters of find and pax in scripts are shell words covered by the
statement preceding that. It is after parameter expansions and quote removal
that the resulting token value may be an argument string to be treated as a
pattern for those utilities.
On Wednesday, July 3, 2019 Geoff Clare wrote:
Stephane Chazelas wrote, on 03 Jul 2019:
>
> 2019-07-03 11:08:57 +0100, Geoff Clare:
> [...]
> > > And again, that's an incompatible change for dash, ksh88, ksh93,
> > > pdksh, mksh, bosh, yash where:
> > >
> > > a='\*'
> > > ls -ld $a
> > >
> > > lists the files that start with \
> >
> > Which is inconsistent with find, pax, fnmatch() and glob().
>
> And again, that argument doesn't hold.
>
> There's no find implementation that I know where
>
> find . -name '"*"*'
> find . -name '"$var"*'
>
> works the same as
>
> printf '%s\n' "*"*
> printf '%s\n' "$var"*
The goal is consistency of backslash handling. There was never any
intention in 1992 to require find, pax, fnmatch() and glob() to mimic
shell single quotes or double quotes, nor is there now, nor does there
need to be.
> fnamtch() didn't add \ support for consistency with the shell,
> It did add the *, ? and [ glob operators of the shell and the \
> quoting operator of the shell. \ is not a glob operator there
> but a quoting operator in its very limited syntax (compared to
> that of the shell which has other forms of quoting, and many
> forms of expansions).
>
> Adding it back to the shell *as an extra layer* hardly helps
> with consistency and adds confusion.
The proposed resolution makes clear that it is not an extra layer, it's
an alternative for situations where the shell quoting backslash is not
available. Thus providing consistency and reducing confusion.
> [...]
> > > a='\d*'
> > > ls -ld $a
> > >
> > > lists the filenames that start with \d
> >
> > Which is inconsistent with find, pax, fnmatch() and glob().
>
> Irrelevant, pax, fnmatch() and glob() don't do variable
> expansion. find -name '$a' is unspecified but in all
> implementations, that returns the files called $a literally.
The goal is consistency of how backslash behaves in patterns.
A direct pattern in a shell word and an indirect pattern in a shell
variable (that is then used unquoted) are two places a pattern can
occur. Arguments to find, pax, fnmatch() and glob() are others.
--
Geoff Clare <
g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
[1003.1(2016)/Issue7+TC2 0001267]: sh HOME should not be UP shaded
The following issue has been SUBMITTED. == http://austingroupbugs.net/view.php?id=1267 == Reported By:dennisw Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1267 Category: Shell and Utilities Type: Error Severity: Comment Priority: normal Status: New Name: Dennis Wölfing Organization: User Reference: Section:sh Page Number:3228 Line Number:108396-108397 Interp Status: --- Final Accepted Text: == Date Submitted: 2019-07-03 15:24 UTC Last Modified: 2019-07-03 15:24 UTC == Summary:sh HOME should not be UP shaded Description: HOME is UP shaded in the ENVIRONMENT VARIABLES section of the sh utility. However XCU 2.6.1 clearly states that HOME is always used by the shell for tilde expansion without a login name, not just on systems that implement the UP option. Desired Action: On page 3228 lines 108396-108397 section sh, remove UP shading from:HOMEDetermine the pathname of the user’s home directory. The contents of HOME are used in tilde expansion as described in [xref to XCU 2.6.1]. == Issue History Date ModifiedUsername FieldChange == 2019-07-03 15:24 denniswNew Issue 2019-07-03 15:24 denniswName => Dennis Wölfing 2019-07-03 15:24 denniswSection => sh 2019-07-03 15:24 denniswPage Number => 3228 2019-07-03 15:24 denniswLine Number => 108396-108397 ==
[1003.1(2016)/Issue7+TC2 0001266]: sh -s with operands
The following issue has been SUBMITTED. == http://austingroupbugs.net/view.php?id=1266 == Reported By:dennisw Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1266 Category: Shell and Utilities Type: Error Severity: Objection Priority: normal Status: New Name: Dennis Wölfing Organization: User Reference: Section:sh Page Number:3226 Line Number:108308-108309 Interp Status: --- Final Accepted Text: == Date Submitted: 2019-07-03 15:18 UTC Last Modified: 2019-07-03 15:18 UTC == Summary:sh -s with operands Description: When the -i option is not present, the standard currently says that the shell is only interactive when there are no operands and stdin and stderr are a terminal. However when the -s option is given commands are read from stdin even when operands are present and existing shells do treat -s with operands as interactive when stdin and stderr refer to a terminal. Desired Action: On page 3226 lines 108308-108309 section sh, change: If the −i option is present, or if there are no operands and the shell’s standard input and standard error are attached to a terminal, the shell is considered to be interactive. to If the −i option is present, or if the shell reads commands from the standard input and the shell’s standard input and standard error are attached to a terminal, the shell is considered to be interactive. == Issue History Date ModifiedUsername FieldChange == 2019-07-03 15:18 denniswNew Issue 2019-07-03 15:18 denniswName => Dennis Wölfing 2019-07-03 15:18 denniswSection => sh 2019-07-03 15:18 denniswPage Number => 3226 2019-07-03 15:18 denniswLine Number => 108308-108309 ==
Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching
2019-07-03 15:19:18 +0100, Geoff Clare: [...] > > Irrelevant, pax, fnmatch() and glob() don't do variable > > expansion. find -name '$a' is unspecified but in all > > implementations, that returns the files called $a literally. > > The goal is consistency of how backslash behaves in patterns. > A direct pattern in a shell word and an indirect pattern in a shell > variable (that is then used unquoted) are two places a pattern can > occur. Arguments to find, pax, fnmatch() and glob() are others. [...] And now, you have to balance it against breaking backward compatibility and making the syntax of the shell more complicated, for no benefit other than that preceived consistency. Before (Bourne/ksh88...) it was: *, ? and [...] are wildcard operators and quoting can be used to remove their special meaning. Which applies to both shell and fnmatch() (where quoting is done with \). With your proposed change, the sh documentation has to be changed to: *, ? and [...] are wildcard operators and quoting can be used to remove their special meaning, but an unquoted backslash (as can be produced by leaving a word expansion unquoted) can also be used to escape the following character if any (unspecified if there's no following character), but bearing in mind that in the pathname expansion case, it only happens for words that contain an unquoted and unescaped (with that unquoted \ character) wildcard operator (unspecified if [ is not matched by an unquoted unescaped ] in the same path component)... -- Stephane
Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching
Harald van Dijk wrote, on 03 Jul 2019: > > On 03/07/2019 11:08, Geoff Clare wrote: > >Stephane Chazelas wrote, on 03 Jul 2019: > >> > >>2019-07-03 09:24:10 +0100, Geoff Clare: > >>[...] > >>> [...] If any character (ordinary, shell > >>>special, or pattern special) is quoted or (where shell quoting is not > >>>in effect) escaped with a , that pattern shall match the > >>>character itself. [...] > >>[...] > >> > >>And again, that's an incompatible change for dash, ksh88, ksh93, > >>pdksh, mksh, bosh, yash where: > >> > >>a='\*' > >>ls -ld $a > >> > >>lists the files that start with \ > > > >Which is inconsistent with find, pax, fnmatch() and glob(). > > I thought the new wording you proposed would require this to list the files > that start with \, as this is a context where shell quoting is in effect, No, it's a context where shell-quoting backslash *doesn't* work. Therefore the backslash should act as an escape character just like in find, pax, fnmatch() and glob(). -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching
Stephane Chazelas wrote, on 03 Jul 2019: > > 2019-07-03 11:08:57 +0100, Geoff Clare: > [...] > > > And again, that's an incompatible change for dash, ksh88, ksh93, > > > pdksh, mksh, bosh, yash where: > > > > > > a='\*' > > > ls -ld $a > > > > > > lists the files that start with \ > > > > Which is inconsistent with find, pax, fnmatch() and glob(). > > And again, that argument doesn't hold. > > There's no find implementation that I know where > > find . -name '"*"*' > find . -name '"$var"*' > > works the same as > > printf '%s\n' "*"* > printf '%s\n' "$var"* The goal is consistency of backslash handling. There was never any intention in 1992 to require find, pax, fnmatch() and glob() to mimic shell single quotes or double quotes, nor is there now, nor does there need to be. > fnamtch() didn't add \ support for consistency with the shell, > It did add the *, ? and [ glob operators of the shell and the \ > quoting operator of the shell. \ is not a glob operator there > but a quoting operator in its very limited syntax (compared to > that of the shell which has other forms of quoting, and many > forms of expansions). > > Adding it back to the shell *as an extra layer* hardly helps > with consistency and adds confusion. The proposed resolution makes clear that it is not an extra layer, it's an alternative for situations where the shell quoting backslash is not available. Thus providing consistency and reducing confusion. > [...] > > > a='\d*' > > > ls -ld $a > > > > > > lists the filenames that start with \d > > > > Which is inconsistent with find, pax, fnmatch() and glob(). > > Irrelevant, pax, fnmatch() and glob() don't do variable > expansion. find -name '$a' is unspecified but in all > implementations, that returns the files called $a literally. The goal is consistency of how backslash behaves in patterns. A direct pattern in a shell word and an indirect pattern in a shell variable (that is then used unquoted) are two places a pattern can occur. Arguments to find, pax, fnmatch() and glob() are others. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching
On 03/07/2019 11:08, Geoff Clare wrote: Stephane Chazelas wrote, on 03 Jul 2019: 2019-07-03 09:24:10 +0100, Geoff Clare: [...] [...] If any character (ordinary, shell special, or pattern special) is quoted or (where shell quoting is not in effect) escaped with a , that pattern shall match the character itself. [...] [...] And again, that's an incompatible change for dash, ksh88, ksh93, pdksh, mksh, bosh, yash where: a='\*' ls -ld $a lists the files that start with \ Which is inconsistent with find, pax, fnmatch() and glob(). I thought the new wording you proposed would require this to list the files that start with \, as this is a context where shell quoting is in effect, so the use of backslash as an escape character is not supported and it just matches itself. If that is not what you were trying to say with the new wording, it is not clear to me what the intent is. Cheers, Harald van Dijk
Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching
2019-07-03 11:08:57 +0100, Geoff Clare: [...] > > And again, that's an incompatible change for dash, ksh88, ksh93, > > pdksh, mksh, bosh, yash where: > > > > a='\*' > > ls -ld $a > > > > lists the files that start with \ > > Which is inconsistent with find, pax, fnmatch() and glob(). And again, that argument doesn't hold. There's no find implementation that I know where find . -name '"*"*' find . -name '"$var"*' works the same as printf '%s\n' "*"* printf '%s\n' "$var"* even though that's currently allowed by the spec. And I don't expect we want to go there. And if we go there, I don't expect we would want to also add back those to the shell as a second level of evaluation (like in pattern='"$var"*'; ls -- $pattern). fnamtch() didn't add \ support for consistency with the shell, It did add the *, ? and [ glob operators of the shell and the \ quoting operator of the shell. \ is not a glob operator there but a quoting operator in its very limited syntax (compared to that of the shell which has other forms of quoting, and many forms of expansions). Adding it back to the shell *as an extra layer* hardly helps with consistency and adds confusion. But more importantly would break backward compatibility in most shells. [...] > > a='\d*' > > ls -ld $a > > > > lists the filenames that start with \d > > Which is inconsistent with find, pax, fnmatch() and glob(). Irrelevant, pax, fnmatch() and glob() don't do variable expansion. find -name '$a' is unspecified but in all implementations, that returns the files called $a literally. > > And in ksh93 > > > > a='\d*' > > case string in $a) > > > > matches on strings that start with digits. > > Which has never been allowed by any possible interpretation of the standard. But would be once bug 1234 is fixed properly by allowing both the most common behaviour and that of bash. > > I still don't understand why you want to specify a behaviour > > that is not present in any shell (but one), that would break > > backward compatibility, that is not needed, that would make the > > syntax of the shell and the text of the spec more confusing. > > We know you don't get it; you've told us several times already. > Repeating it more times is not going to achieve anything and will just > waste everybody's time. [...] We have diverging views. Bug 1234 is about saying that your view is wrong. If you don't agree, you can close that bug as "won't fix" and be done with it. But AFAICT, Eric's and Joerg's views at least are currently closer to mine than to yours. -- Stephane
Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching
On 03/07/2019 09:24, Geoff Clare wrote: Harald van Dijk wrote, on 02 Jul 2019: That's not because the word "unquoted" is used, which only applies to shell quoting, that's because 2.13.1 contains "All of the requirements and effects of quoting on ordinary, shell special, and special pattern characters shall apply to escaping in this context", which specifies that quoting and other escaping have the same effect. So what's the problem? The text that you complained about in my proposed resolution is in 2.13.1, so is covered by this. Let's get back to the wording you proposed. [...] If any character (ordinary, shell special, or pattern special) is quoted, using either shell quoting or (where shell quoting is not in effect) a escape, that pattern shall match the character itself. [...] This wording wrongly claims that where shell quoting is not in effect, a escape quotes the next character. It does not just say that character is treated as if it were quoted like the current text says, it says it *is* quoted. That's extremely picky, but I take your point. Here's an alternative that I think fixes the problem: [...] If any character (ordinary, shell special, or pattern special) is quoted or (where shell quoting is not in effect) escaped with a , that pattern shall match the character itself. [...] Thanks, that looks like a proper fix for that issue. Cheers, Harald van Dijk
Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching
Joerg Schilling wrote, on 03 Jul 2019: > > Geoff Clare wrote: > > > Joerg Schilling wrote, on 03 Jul 2019: > > > > Do you like to say that pax behaves inconsistent to ls? > > > > The inconsistentcy has nothing to do with ls. It's with how those > > shells interpret the (indirect) pattern \* compared to how find, pax, > > fnmatch() and glob() (and the shell itself when it's a direct pattern) > > interpret it. > > It seems that you missinterpret that effect. > > pax is not a shell and ls does not include own pattern matching. > > You thus cannot compare the behavior of these programs with each other or > with > a shell. Huh? find, pax, fnmatch() and glob() all do pattern matching as described in XCU 2.13. The shell is supposed to as well. I already said it has nothing to do with ls. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching
Geoff Clare wrote: > Joerg Schilling wrote, on 03 Jul 2019: > > Do you like to say that pax behaves inconsistent to ls? > > The inconsistentcy has nothing to do with ls. It's with how those > shells interpret the (indirect) pattern \* compared to how find, pax, > fnmatch() and glob() (and the shell itself when it's a direct pattern) > interpret it. It seems that you missinterpret that effect. pax is not a shell and ls does not include own pattern matching. You thus cannot compare the behavior of these programs with each other or with a shell. Jörg -- EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching
Joerg Schilling wrote, on 03 Jul 2019: > > Geoff Clare wrote: > > > Stephane Chazelas wrote, on 03 Jul 2019: > > > And again, that's an incompatible change for dash, ksh88, ksh93, > > > pdksh, mksh, bosh, yash where: > > > > > > a='\*' > > > ls -ld $a > > > > > > lists the files that start with \ > > > > Which is inconsistent with find, pax, fnmatch() and glob(). > > Do you like to say that pax behaves inconsistent to ls? The inconsistentcy has nothing to do with ls. It's with how those shells interpret the (indirect) pattern \* compared to how find, pax, fnmatch() and glob() (and the shell itself when it's a direct pattern) interpret it. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching
Geoff Clare wrote: > Stephane Chazelas wrote, on 03 Jul 2019: > > And again, that's an incompatible change for dash, ksh88, ksh93, > > pdksh, mksh, bosh, yash where: > > > > a='\*' > > ls -ld $a > > > > lists the files that start with \ > > Which is inconsistent with find, pax, fnmatch() and glob(). Do you like to say that pax behaves inconsistent to ls? Jörg -- EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching
Stephane Chazelas wrote, on 03 Jul 2019: > > 2019-07-03 09:24:10 +0100, Geoff Clare: > [...] > > [...] If any character (ordinary, shell > >special, or pattern special) is quoted or (where shell quoting is not > >in effect) escaped with a , that pattern shall match the > >character itself. [...] > [...] > > And again, that's an incompatible change for dash, ksh88, ksh93, > pdksh, mksh, bosh, yash where: > > a='\*' > ls -ld $a > > lists the files that start with \ Which is inconsistent with find, pax, fnmatch() and glob(). > Or zshsh where > > a='\d*' > ls -ld $a > > lists the filenames that start with \d Which is inconsistent with find, pax, fnmatch() and glob(). > And in ksh93 > > a='\d*' > case string in $a) > > matches on strings that start with digits. Which has never been allowed by any possible interpretation of the standard. > I still don't understand why you want to specify a behaviour > that is not present in any shell (but one), that would break > backward compatibility, that is not needed, that would make the > syntax of the shell and the text of the spec more confusing. We know you don't get it; you've told us several times already. Repeating it more times is not going to achieve anything and will just waste everybody's time. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching
Harald van Dijk wrote, on 02 Jul 2019: > > >>That's not because the word "unquoted" is used, which only applies to shell > >>quoting, that's because 2.13.1 contains "All of the requirements and effects > >>of quoting on ordinary, shell special, and special pattern characters shall > >>apply to escaping in this context", which specifies that quoting and other > >>escaping have the same effect. > > > >So what's the problem? The text that you complained about in my > >proposed resolution is in 2.13.1, so is covered by this. > > Let's get back to the wording you proposed. > > > [...] If any character (ordinary, shell > >special, or pattern special) is quoted, using either shell quoting > >or (where shell quoting is not in effect) a escape, that > >pattern shall match the character itself. [...] > > This wording wrongly claims that where shell quoting is not in effect, a > escape quotes the next character. It does not just say that > character is treated as if it were quoted like the current text says, it > says it *is* quoted. That's extremely picky, but I take your point. Here's an alternative that I think fixes the problem: [...] If any character (ordinary, shell special, or pattern special) is quoted or (where shell quoting is not in effect) escaped with a , that pattern shall match the character itself. [...] -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
[1003.1(2016)/Issue7+TC2 0001265]: Knock-on effects of Issue 7 change to XCU 2.8.1
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=1265 == Reported By:geoffclare Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1265 Category: Shell and Utilities Type: Error Severity: Objection Priority: normal Status: New Name: Geoff Clare Organization: The Open Group User Reference: Section:2.14 (dot, shift, trap) Page Number:2393,2416,2421 Line Number:76558,77394,77559 Interp Status: --- Final Accepted Text: == Date Submitted: 2019-07-02 11:08 UTC Last Modified: 2019-07-03 06:24 UTC == Summary:Knock-on effects of Issue 7 change to XCU 2.8.1 == -- (0004469) shware_systems (reporter) - 2019-07-03 06:24 http://austingroupbugs.net/view.php?id=1265#c4469 -- No, I will not consider those... They are regular utilities, not special built-ins, that allow the application to interpret non-success appropriately, as fatal, warning, or informative, as part of failure recovery, because the shell shall not exit. They are still considered failures, for the boolean question "Did the utility succeed or not?", that applies for "shall exit" now with special built-ins. Issue History Date ModifiedUsername FieldChange == 2019-07-02 11:08 geoffclare New Issue 2019-07-02 11:08 geoffclare Name => Geoff Clare 2019-07-02 11:08 geoffclare Organization => The Open Group 2019-07-02 11:08 geoffclare Section => 2.14 (dot, shift, trap) 2019-07-02 11:08 geoffclare Page Number => 2393,2416,2421 2019-07-02 11:08 geoffclare Line Number => 76558,77394,77559 2019-07-02 11:08 geoffclare Interp Status => --- 2019-07-02 14:50 chet_ramey Note Added: 0004462 2019-07-02 15:50 shware_systems Note Added: 0004463 2019-07-02 15:57 shware_systems Note Edited: 0004463 2019-07-02 16:19 geoffclare Note Added: 0004464 2019-07-02 17:37 shware_systems Note Added: 0004465 2019-07-02 17:53 shware_systems Note Edited: 0004465 2019-07-02 18:17 chet_ramey Note Added: 0004466 2019-07-02 20:00 shware_systems Note Added: 0004467 2019-07-03 00:06 kreNote Added: 0004468 2019-07-03 06:24 shware_systems Note Added: 0004469 ==
