Geoff Clare wrote, on 16 Apr 2018:
>
> Robert Elz wrote, on 13 Apr 2018:
> >
> > Date:Fri, 13 Apr 2018 15:07:07 +0100
> > From:Geoff Clare
> >
> > | For those the only difference from REs is the '^' -> '!' one,
> >
> > Not for fnmatch() which can have \ to escape cha
Geoff Clare wrote:
> Clearly the statement in XBD 9.3.5:
>
> The special characters '.', '*', '[', and '\\' ( ,
> , , and , respectively)
> shall lose their special meaning within a bracket expression.
>
> is intended to apply to backslashes in fnmatch(), just as it does to
> the spec
Robert Elz wrote, on 13 Apr 2018:
>
> Date:Fri, 13 Apr 2018 15:07:07 +0100
> From:Geoff Clare
>
> | For those the only difference from REs is the '^' -> '!' one,
>
> Not for fnmatch() which can have \ to escape characters (anywhere
> according to its description, whic
Date:Fri, 13 Apr 2018 15:07:07 +0100
From:Geoff Clare
Message-ID: <20180413140707.GB19570@lt2.masqnet>
| Bracket expressions are not only used in REs and the shell. There are
| also fnmatch(), glob(), find and pax to consider, where shell quoting
| does not app
Robert Elz wrote, on 13 Apr 2018:
>
> Date:Fri, 13 Apr 2018 12:04:51 +0100
> From:Geoff Clare
>
> | In the case of , this does not make clear that it is only
> | referring to the RE-and-shell-pattern-matching special meaning of
> | and does not affect its shell-quo
Robert Elz wrote, on 13 Apr 2018:
>
> I think we have had enough of this topic, so I will not continue it
> after this message, but...
>
> | I maintain that the requirements of 2.2.3 are indeed universal.
>
> If that's true, then surely those words must be read in conjunction with
> what the i
Date:Fri, 13 Apr 2018 11:51:12 +0100
From:Geoff Clare
Message-ID: <20180413105112.GA16858@lt2.masqnet>
I think we have had enough of this topic, so I will not continue it
after this message, but...
| I maintain that the requirements of 2.2.3 are indeed universal.
Robert Elz wrote:
> I know it is irritating to duplicate text, and if they were truly the same,
> I would not advocate it, but glob patterns and RE patterns are just
> different - only the char classes look kind of similar (and even there we
> need to do the '^' -> '!' substitution) but aren't re
Date:Fri, 13 Apr 2018 12:04:51 +0100
From:Geoff Clare
Message-ID: <20180413110451.GA17286@lt2.masqnet>
| In the case of , this does not make clear that it is only
| referring to the RE-and-shell-pattern-matching special meaning of
| and does not affect its shel
I wrote, on 13 Apr 2018:
>
> Note that whilst extra text is not *needed* regarding quoting inside
> bracket expressions, I would have no objection to some sort of explanatory
> note being added to lessen the chances that readers fail to realise that
> the quoting rules still apply inside bracket ex
Robert Elz wrote, on 13 Apr 2018:
>
> That is, your comment that the text in 2.2.3 which says "shall preserve
> the literal value..." is not universal throughout the spec as you implied.
I maintain that the requirements of 2.2.3 are indeed universal.
> If it doesn't always apply, then we need ex
Date:Fri, 13 Apr 2018 09:32:40 +0100
From:Geoff Clare
Message-ID: <20180413083240.GA14937@lt2.masqnet>
| Neither of your examples is valid because the standard already explicitly
| describes the behaviour in those cases.
Sorry, but those sections have nothing wha
"Schwarz, Konrad" wrote:
> As the Bourne Shell source code posted earlier showed, that implementation
> did not clearly separate the phases: a character with its high-bit set was
> quoted for all further purposes.
This worked with 7-bit ASCII.
As we have an 8-bit clean Bourne Shell since 1986
Robert Elz wrote:
> Date:Thu, 12 Apr 2018 12:10:04 -0700
> From:Don Cragun
> Message-ID:
>
> | The fact that the $ is special is what is the key.
>
> The problem is in the interpretation of just what "treated literally" means.
>
> If it just means that "the charac
Robert Elz wrote, on 13 Apr 2018:
>
> I have also just realised that a better example than ${ in "" would have been
> $( inside "".
>
> There, because of the double quotes, the '(' is treated literally, as a '('
> character, and not as the '(' operator. But still when the command
> substitition
> -Original Message-
> From: Robert Elz [mailto:k...@munnari.oz.au]
> Put that reasoning into the argument in the previous message, instead
> of the ${ version and I think it becomes clearer how the current text
> allows the '-' inside "a-c" to be treated literally, as the string is
> pa
I have also just realised that a better example than ${ in "" would have been
$( inside "".
There, because of the double quotes, the '(' is treated literally, as a '('
character, and not as the '(' operator. But still when the command
substitition (inside the "") is performed, the '(' is availab
Date:Thu, 12 Apr 2018 12:10:04 -0700
From:Don Cragun
Message-ID:
| The fact that the $ is special is what is the key.
The problem is in the interpretation of just what "treated literally" means.
If it just means that "the character is itself and is not transforme
> On Apr 12, 2018, at 8:07 AM, Robert Elz wrote:
>
>Date:Thu, 12 Apr 2018 14:25:32 +0100
>From:Geoff Clare
>Message-ID: <20180412132532.GA9483@lt2.masqnet>
>
> | It treats them as literal characters, just as 2.2.3 says.
>
> I thought that might have been the res
Date:Thu, 12 Apr 2018 14:25:32 +0100
From:Geoff Clare
Message-ID: <20180412132532.GA9483@lt2.masqnet>
| It treats them as literal characters, just as 2.2.3 says.
I thought that might have been the response, in that case in
"${xxx}"
The '{' has to be treat
Robert Elz wrote, on 12 Apr 2018:
>
> Date:Thu, 12 Apr 2018 13:25:01 +0100
> From:Geoff Clare
>
> | Yes there is. I quoted it earlier in this thread.
>
> I know that, but that's useless for this purpose. We know the quoted
> (part of) the string is treated literally
Date:Thu, 12 Apr 2018 13:25:01 +0100
From:Geoff Clare
Message-ID: <20180412122501.GA8783@lt2.masqnet>
| Yes there is. I quoted it earlier in this thread.
I know that, but that's useless for this purpose. We know the quoted
(part of) the string is treated literal
Robert Elz wrote, on 12 Apr 2018:
>
> Date:Thu, 12 Apr 2018 11:39:11 +0100
> From:Geoff Clare
>
> | Huh? The '-' is quoted by the double quotes and should therefore be
> | treated literally.
>
> The problem is that there is nothing in either TC2 or TC2 + 985-fix th
Date:Thu, 12 Apr 2018 11:39:11 +0100
From:Geoff Clare
Message-ID: <20180412103911.GA6656@lt2.masqnet>
| Huh? The '-' is quoted by the double quotes and should therefore be
| treated literally.
The problem is that there is nothing in either TC2 or TC2 + 985-fix
Date:Thu, 12 Apr 2018 12:10:20 +0200
From:Joerg Schilling
Message-ID: <5acf308c.yoyva4vzwwu8t7jp%joerg.schill...@fokus.fraunhofer.de>
Jörg:
| Since '' and "" quoting in the shell is highly complex and no longer
present at
| the time the shell pattern matching i
Geoff Clare wrote:
> >
> > > ["a\-c"] the backslash is not special and should be treated literally
> >
> > This string is converted into [\a\\-\c] by the shell macro expansion code.
> >
> > With the shell gmatch() code, this results in a match for 'a' and '\\' ..
> > 'c'.
>
> Huh? The '-' is
Joerg Schilling wrote, on 12 Apr 2018:
>
> Geoff Clare wrote:
>
> > > Maybe, I should again mention history:
> > >
> > > - fmnatch() has been introduced with issue 4 (1995). It does not
> > > seem to be related to a historic UNIX. Since the oldest known
> > > impleme
Geoff Clare wrote:
> > Maybe, I should again mention history:
> >
> > - fmnatch() has been introduced with issue 4 (1995). It does not
> > seem to be related to a historic UNIX. Since the oldest known
> > implementation is from IBM, fnmatch() may have been intro
Robert Elz wrote:
> And yes, in particular if a [a\-c] means a class with the three chars 'a' '-'
> and 'c' in it in sh it should mean that in fnmatch() as well, or if that
> pattern means a class with 8 chars (0x5c .. 0x63) with 'a' there 2 ways,
> in fnmatch() then it should mean that in sh as
Joerg Schilling wrote, on 12 Apr 2018:
>
> It seems that we need to define how quoting works in a real shell
> implementation.
>
> If we require the strings to be in the form \c\h\a\r in case of a quoted
> string
> at that specific part of the shell, we may explain how quoting works for
> "c
Date:Thu, 12 Apr 2018 09:24:51 +0100
From:Geoff Clare
Message-ID: <20180412082451.GA3949@lt2.masqnet>
| Bug 985 moves the detail from the current 2.13 into the fnmatch()
| description and makes 2.13 refer to fnmatch().
Oh - I did not read all of it all that caref
Robert Elz wrote:
> Date:Wed, 11 Apr 2018 15:14:00 +0100
> From:Geoff Clare
> Message-ID: <20180411141400.GA32463@lt2.masqnet>
>
> | I also have a feeling we will have to abandon the neat idea of defining
> | shell pattern matching in terms of fnmatch().
>
> Yes
Robert Elz wrote, on 12 Apr 2018:
>
> Date:Wed, 11 Apr 2018 15:14:00 +0100
> From:Geoff Clare
>
> | I also have a feeling we will have to abandon the neat idea of defining
> | shell pattern matching in terms of fnmatch().
>
> Yes, but for a slightly different reason
Date:Wed, 11 Apr 2018 15:14:00 +0100
From:Geoff Clare
Message-ID: <20180411141400.GA32463@lt2.masqnet>
| I also have a feeling we will have to abandon the neat idea of defining
| shell pattern matching in terms of fnmatch().
Yes, but for a slightly different rea
Robert Elz wrote, on 11 Apr 2018:
>
> Date:Wed, 11 Apr 2018 12:18:27 +0100
> From:Geoff Clare
>
> | No, that text is very careful to say "*was* quoted", not "is quoted",
> | for precisely this reason. To conform to this requirement, the shell
> | has to remember wh
Date:Wed, 11 Apr 2018 14:14:18 +0200
From:Joerg Schilling
Message-ID: <5acdfc1a.st0sitei1fsdsgeb%joerg.schill...@fokus.fraunhofer.de>
| Then we should change the wording.
I agree.
| The characters '.', '*' and '[' really lose their special meaning inside a
|
Date:Wed, 11 Apr 2018 12:18:27 +0100
From:Geoff Clare
Message-ID: <2018041827.GA29286@lt2.masqnet>
| No, that text is very careful to say "*was* quoted", not "is quoted",
| for precisely this reason. To conform to this requirement, the shell
| has to rememb
Robert Elz wrote:
> Date:Wed, 11 Apr 2018 11:28:38 +0200
> From:Joerg Schilling
> Message-ID:
> <5acdd546.fkln7tigk21a+de6%joerg.schill...@fokus.fraunhofer.de>
>
> | The problem is that the term "quote removal" is not related to a real
> verified
> | shell imp
Date:Wed, 11 Apr 2018 11:28:38 +0200
From:Joerg Schilling
Message-ID: <5acdd546.fkln7tigk21a+de6%joerg.schill...@fokus.fraunhofer.de>
| The problem is that the term "quote removal" is not related to a real
verified
| shell implementation but rather explained by
Robert Elz wrote, on 11 Apr 2018:
>
> Incidentally, I know that this part of the 985 new text ...
>
> the first argument (pattern) is the same as patt, except each character
> that was quoted in patt and is not in a bracket expression is prefixed
> by a backslash
>
> is intended to
Geoff Clare wrote:
> Here's a much simpler demonstration of the same "quoting within
> brackets" issue:
>
> $ ls
> b
>
> ksh93:
> $ echo ["a-c"]
> b
>
> ksh88 and bash:
> $ echo ["a-c"]
> [a-c]
>
> As Joerg pointed out, the intention would have been for POSIX to
> specify the ksh88 behaviour, so
Geoff Clare wrote:
> Robert Elz wrote, on 11 Apr 2018:
> >
> > Lower down, it says ...
> >
> > In order from the beginning to the end of the case statement, each
> > pattern
> > that labels a compound-list shall be subjected to tilde expansion,
> > parameter
> > expansion, command
Date:Wed, 11 Apr 2018 10:00:27 +0100
From:Geoff Clare
Message-ID: <20180411090027.GA18582@lt2.masqnet>
| There is nothing to suggest that this does not apply to the characters
| which, when unquoted, have a special meaning within bracket expressions
| ('!', '-',
Martijn Dekker wrote:
> Op 10-04-18 om 15:59 schreef Joerg Schilling:
> > Whom do you call "current ksh93 lead developers"?
>
> As far as I can tell from what's going on at the github repo, Siteshwar
> Vashisht and Kurtis Rader currently appear to be in charge of its
> development.
I am still
Robert Elz wrote:
> Date:Tue, 10 Apr 2018 13:41:25 +0100
> From:Martijn Dekker
> Message-ID:
>
> | Does POSIX specify anything, either way, regarding the effect of shell
> | quoting within glob bracket patterns?
>
> I would say it is unclear - in general, quoti
Martijn Dekker wrote:
> Op 10-04-18 om 21:06 schreef Robert Elz:
> > Date:Tue, 10 Apr 2018 13:41:25 +0100
> > From:Martijn Dekker
> > Message-ID:
> >
> >| Does POSIX specify anything, either way, regarding the effect of shell
> >| quoting within glob bra
I wrote:
>
> And I believe the standard does clearly require the ksh88/bash
> behaviour because of this statement in 2.2.3 Double-Quotes:
>
> Enclosing characters in double-quotes ("") shall preserve the
> literal value of all characters within the double-quotes, with the
> exception o
Martijn Dekker wrote, on 10 Apr 2018:
>
> Re: https://github.com/att/ast/issues/71
>
> Consider this test script:
>
> (set -o posix) 2>/dev/null && set -o posix
> emulate sh 2>/dev/null # for zsh
> for var in 'a-c' '!a'; do
> case b in
> ( ["$var"] )echo 'quirk' ;;
> ( [$v
Robert Elz wrote, on 11 Apr 2018:
>
> Lower down, it says ...
>
> In order from the beginning to the end of the case statement, each
> pattern
> that labels a compound-list shall be subjected to tilde expansion,
> parameter
> expansion, command substitution, and arithmetic exp
Op 10-04-18 om 22:50 schreef Jilles Tjoelker:
I prefer "no quirk" twice as output but it is indeed not fully
specified.
I agree with your preference.
Ignoring shell quoting in glob bracket patterns means removing a useful
feature: the ability to pass an arbitrary string of characters in a
pa
On Tue, Apr 10, 2018 at 01:41:25PM +0100, Martijn Dekker wrote:
> Re: https://github.com/att/ast/issues/71
> Consider this test script:
> (set -o posix) 2>/dev/null && set -o posix
> emulate sh 2>/dev/null # for zsh
> for var in 'a-c' '!a'; do
> case b in
> ( ["$var"] )echo 'quir
Op 10-04-18 om 15:59 schreef Joerg Schilling:
Whom do you call "current ksh93 lead developers"?
As far as I can tell from what's going on at the github repo, Siteshwar
Vashisht and Kurtis Rader currently appear to be in charge of its
development.
- M.
Op 10-04-18 om 21:52 schreef Robert Elz:
No, it doesn't.
Read that again, with the emphasis I am adding ...
|http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_04_05
| | The conditional construct case shall execute the/compound-list/
| | corresponding t
Date:Tue, 10 Apr 2018 21:28:01 +0100
From:Martijn Dekker
Message-ID: <6e79f3b1-732e-a7d4-1d07-a04d7a9cf...@inlv.org>
| But it is. POSIX explicitly specifies quote removal for 'case' patterns:
No, it doesn't.
Read that again, with the emphasis I am adding ...
|
On 4/10/18 4:28 PM, Martijn Dekker wrote:
>> [this includes case patterns as quote removal is not performed on them]
>
> But it is. POSIX explicitly specifies quote removal for 'case' patterns:
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_04_05
>
> | The c
Op 10-04-18 om 21:06 schreef Robert Elz:
Date:Tue, 10 Apr 2018 13:41:25 +0100
From:Martijn Dekker
Message-ID:
| Does POSIX specify anything, either way, regarding the effect of shell
| quoting within glob bracket patterns?
I would say it is unclear - in g
Date:Tue, 10 Apr 2018 13:41:25 +0100
From:Martijn Dekker
Message-ID:
| Does POSIX specify anything, either way, regarding the effect of shell
| quoting within glob bracket patterns?
I would say it is unclear - in general, quoting inside [] does not work
(XCU 2.
Martijn Dekker wrote:
> Re: https://github.com/att/ast/issues/71
>
> Consider this test script:
>
> (set -o posix) 2>/dev/null && set -o posix
> emulate sh 2>/dev/null # for zsh
> for var in 'a-c' '!a'; do
> case b in
> ( ["$var"] )echo 'quirk' ;;
> ( [$var] ) echo 'no
58 matches
Mail list logo
