Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-10-24 Thread Geoff Clare
Harald van Dijk wrote, on 23 Oct 2019: > > On 22/10/2019 09:47, Geoff Clare wrote: > >Good catch. Since there is no reason for a user or application to > >escape a slash with a backslash, I see no reason why this shouldn't be > >made unspecified. > I wanted to agree with this, especially since

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-10-24 Thread Robert Elz
Date:Thu, 24 Oct 2019 09:25:52 +0100 From:Harald van Dijk Message-ID: <9c38ef54-adf6-9af5-0f98-1f3105526...@gigawatt.nl> | That is what almost all shells do, but not what POSIX specifies. Not explicitly perhaps, but it is almost the only way to achieve the effects

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-10-24 Thread Harald van Dijk
On 24/10/2019 08:16, Robert Elz wrote: Date:Thu, 24 Oct 2019 06:46:52 +0100 From:Harald van Dijk Message-ID: <5d23eeba-1ac5-6574-d348-2a8b43f97...@gigawatt.nl> | This is currently well-defined. We are talking about changing the | standard to make it

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-10-24 Thread Robert Elz
Date:Thu, 24 Oct 2019 06:46:52 +0100 From:Harald van Dijk Message-ID: <5d23eeba-1ac5-6574-d348-2a8b43f97...@gigawatt.nl> | This is currently well-defined. We are talking about changing the | standard to make it unspecified. I am not sure about the first

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-10-23 Thread Harald van Dijk
On 24/10/2019 00:42, Robert Elz wrote: Date:Wed, 23 Oct 2019 20:58:08 +0100 From:Harald van Dijk Message-ID: | That is, if a user runs |echo "/dev/"* | dash will call glob() with a pattern string of '\/dev\/*'. Bizarre. Why? Some shell

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-10-23 Thread Robert Elz
Date:Wed, 23 Oct 2019 20:58:08 +0100 From:Harald van Dijk Message-ID: | That is, if a user runs |echo "/dev/"* | dash will call glob() with a pattern string of '\/dev\/*'. Bizarre. Why? However, that is no reason to change anything (proposed or

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-10-23 Thread Harald van Dijk
On 22/10/2019 09:47, Geoff Clare wrote: Good catch. Since there is no reason for a user or application to escape a slash with a backslash, I see no reason why this shouldn't be made unspecified. I suggest adding the following to the bug 1234 resolution: On page 2383 line 76261 section 2.13.3,

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-10-22 Thread Geoff Clare
Harald van Dijk wrote, on 19 Oct 2019: > > On 23/09/2019 16:39, Austin Group Bug Tracker wrote: > >-- > > (0004564) geoffclare (manager) - 2019-09-23 15:39 > > http://austingroupbugs.net/view.php?id=1234#c4564 >

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-10-19 Thread Harald van Dijk
On 23/09/2019 16:39, Austin Group Bug Tracker wrote: -- (0004564) geoffclare (manager) - 2019-09-23 15:39 http://austingroupbugs.net/view.php?id=1234#c4564

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-09-30 Thread Harald van Dijk
On 30/09/2019 12:00, Geoff Clare wrote: Harald van Dijk wrote, on 30 Sep 2019: (As an aside, why is this exception limited to patterns used for filename expansion? Existing practice is that it applies to all patterns: case [a in [*) echo match ;; *) echo no match ;; esac This prints "no

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-09-30 Thread Geoff Clare
Harald van Dijk wrote, on 30 Sep 2019: > >> > >>>If the pattern contains an open bracket ( '[' ) that does not introduce a > >>>bracket expression as in XBD RE Bracket Expression, it is unspecified > >>>whether other unquoted pattern matching characters within the same > >>>slash-delimited

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-09-30 Thread Harald van Dijk
On 30/09/2019 10:51, Geoff Clare wrote: Harald van Dijk wrote, on 28 Sep 2019: On 23/09/2019 16:39, Austin Group Bug Tracker wrote: -- (0004564) geoffclare (manager) - 2019-09-23 15:39

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-09-30 Thread Geoff Clare
Harald van Dijk wrote, on 28 Sep 2019: > > On 23/09/2019 16:39, Austin Group Bug Tracker wrote: > >-- > > (0004564) geoffclare (manager) - 2019-09-23 15:39 > > http://austingroupbugs.net/view.php?id=1234#c4564 >

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-09-27 Thread Harald van Dijk
On 23/09/2019 16:39, Austin Group Bug Tracker wrote: -- (0004564) geoffclare (manager) - 2019-09-23 15:39 http://austingroupbugs.net/view.php?id=1234#c4564

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-09-26 Thread Harald van Dijk
On 26/09/2019 14:27, Joerg Schilling wrote: Harald van Dijk wrote: Not the same way, but it could still be trivially fixed: instead of as_echo='printf %s\n' configure scripts could do as_echo() { printf '%s\n' "$@"; } as_echo=as_echo Well, the problem with using printf

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-09-26 Thread Joerg Schilling
Harald van Dijk wrote: > Not the same way, but it could still be trivially fixed: instead of > >as_echo='printf %s\n' > > configure scripts could do > >as_echo() { printf '%s\n' "$@"; } >as_echo=as_echo Well, the problem with using printf instead of echo is that not all printf

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-09-25 Thread Harald van Dijk
On 25/09/2019 15:49, Geoff Clare wrote: There are differences due to the version number change and there are differences due to the build configuration being different. I only mentioned the build configuration in order to preempt a response claiming that the differences between bash 3 and bash

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-09-25 Thread Geoff Clare
Harald van Dijk wrote, on 25 Sep 2019: > > On 25/09/2019 10:22, Geoff Clare wrote: > >Harald van Dijk wrote, on 24 Sep 2019: > >> > Regardless, a single shell is not enough to say "most shells", not even if > it is multiple versions of that single shell. > >>> > >>>I consider bash 4 on

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-09-25 Thread Stephane Chazelas
2019-09-25 10:22:07 +0100, Geoff Clare: [...] > I wrote the above before I had fully thought it through, and having slept > on it my preference is now much stronger, and I certainly would object to > specifying the NetBSD sh behaviour. The reason is because treating > backslash differently in

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-09-25 Thread Harald van Dijk
On 25/09/2019 10:22, Geoff Clare wrote: Harald van Dijk wrote, on 24 Sep 2019: Regardless, a single shell is not enough to say "most shells", not even if it is multiple versions of that single shell. I consider bash 4 on Linux and bash 3 on macOS to be different shells. (Their build

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-09-25 Thread Geoff Clare
Harald van Dijk wrote, on 24 Sep 2019: > > >>Regardless, a single shell is not enough to say "most shells", not even if > >>it is multiple versions of that single shell. > > > >I consider bash 4 on Linux and bash 3 on macOS to be different shells. > >(Their build configuration is different.) > >

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-09-24 Thread Harald van Dijk
On 24/09/2019 15:32, Geoff Clare wrote: Harald van Dijk wrote, on 24 Sep 2019: There is a reason I wrote "in its current version". I do not think it is reasonable to describe bash 4 behaviour that had already been changed when this was being discussed as "existing practice". Bash 3 on macOS

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-09-24 Thread Stephane Chazelas
2019-09-24 15:53:07 +0100, Geoff Clare: [...] > to: > > 3. If a specified pattern contains any '*', '?' or '[' characters >that will be treated as special (see [xref to 2.13.1]), it shall >be matched against existing filenames and pathnames, as >appropriate. Each

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-09-24 Thread Geoff Clare
Stephane Chazelas wrote, on 24 Sep 2019: > > In: > > */x, the shell only needs search access to all the directories > in the current directory (it will typically attempt a > lstat(dir/x) for each of them. (And you need search and read > access to the current directory) > > In x/*, you need

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-09-24 Thread Geoff Clare
Harald van Dijk wrote, on 24 Sep 2019: > > On 24/09/2019 12:24, Geoff Clare wrote: > >Harald van Dijk wrote, on 24 Sep 2019: > >> > >>>2. Existing practice in most shells that do treat backslash as special in > >>>"indirect" patterns in pathname expansions is only to match patterns > >>>against

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-09-24 Thread Stephane Chazelas
2019-09-24 12:24:43 +0100, Geoff Clare: [...] > > In NetBSD sh, backslash is given this special treatment only if the current > > pathname component of the pattern includes a metacharacter. That is, an > > indirect /de\v/nul[l] does not find /dev/null, but an indirect /d[e]\v/null > > does. > >

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-09-24 Thread Stephane Chazelas
2019-09-24 09:46:27 +0100, Geoff Clare: [...] > > Regardless, the above question applies in > > [...] > var='\*' [...] > > printf '%s\n' */$var > > > > Or > > > > printf '%s\n' $var/* > > Those both have a * that will be treated as special, so matching > against existing files is performed. The

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-09-24 Thread Harald van Dijk
On 24/09/2019 12:24, Geoff Clare wrote: Harald van Dijk wrote, on 24 Sep 2019: 2. Existing practice in most shells that do treat backslash as special in "indirect" patterns in pathname expansions is only to match patterns against existing pathnames if the pattern includes a '*', '?' or '['

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-09-24 Thread Geoff Clare
Harald van Dijk wrote, on 24 Sep 2019: > > >2. Existing practice in most shells that do treat backslash as special in > >"indirect" patterns in pathname expansions is only to match patterns > >against existing pathnames if the pattern includes a '*', '?' or '[' that > >is treated as special.

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-09-24 Thread Harald van Dijk
On 23/09/2019 16:39, Austin Group Bug Tracker wrote: [...] -- (0004564) geoffclare (manager) - 2019-09-23 15:39 http://austingroupbugs.net/view.php?id=1234#c4564

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-09-24 Thread Geoff Clare
Stephane Chazelas wrote, on 24 Sep 2019: > > 2019-09-23 15:39:49 +, Austin Group Bug Tracker: > [...] > > On page 2384 line 76271 section 2.13.3, change:3. Specified > > patterns shall be matched against existing filenames and pathnames, as > > appropriate.to:3. If a specified pattern

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-09-24 Thread Stephane Chazelas
2019-09-23 15:39:49 +, Austin Group Bug Tracker: [...] > On page 2384 line 76271 section 2.13.3, change:3. Specified > patterns shall be matched against existing filenames and pathnames, as > appropriate.to:3. If a specified pattern contains > any '*', '?' or '[' characters that will be

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-07-04 Thread Harald van Dijk
On 04/07/2019 09:09, Geoff Clare wrote: Harald van Dijk wrote, on 03 Jul 2019: 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

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-07-04 Thread Geoff Clare
Geoff Clare wrote, on 04 Jul 2019: > > Harald van Dijk wrote, on 03 Jul 2019: > > > > >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

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-07-04 Thread Geoff Clare
Harald van Dijk wrote, on 03 Jul 2019: > > >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

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-07-03 Thread Harald van Dijk
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

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-07-03 Thread Geoff Clare
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

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-07-03 Thread Shware Systems
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

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-07-03 Thread Stephane Chazelas
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

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-07-03 Thread Geoff Clare
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

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-07-03 Thread Geoff Clare
Joerg Schilling wrote, on 03 Jul 2019: > > Geoff Clare wrote: > > > Joerg Schilling wrote, on 03 Jul 2019: > > > 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. >

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-07-03 Thread Geoff Clare
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 \ > > > >

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-07-03 Thread Joerg Schilling
Geoff Clare wrote: > Joerg Schilling wrote, on 03 Jul 2019: > > 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

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-07-03 Thread Harald van Dijk
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)

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-07-03 Thread Stephane Chazelas
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

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-07-03 Thread Harald van Dijk
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

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-07-03 Thread Geoff Clare
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 \*

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-07-03 Thread Joerg Schilling
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

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-07-03 Thread Geoff Clare
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

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-07-03 Thread Joerg Schilling
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

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-07-03 Thread Geoff Clare
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

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-07-03 Thread Geoff Clare
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

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-07-02 Thread Harald van Dijk
On 02/07/2019 10:20, Geoff Clare wrote: Harald van Dijk wrote, on 01 Jul 2019: On 01/07/2019 10:36, Geoff Clare wrote: Harald van Dijk wrote, on 30 Jun 2019: POSIX does not even limit the concept of "syntax errors" to errors in the syntax, see e.g. the "shift" command: If the n operand

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-07-02 Thread Geoff Clare
Harald van Dijk wrote, on 01 Jul 2019: > > On 01/07/2019 10:36, Geoff Clare wrote: > >Harald van Dijk wrote, on 30 Jun 2019: > >> > >>POSIX does not even limit the concept of "syntax errors" to errors in the > >>syntax, see e.g. the "shift" command: > >> > >>>If the n operand is invalid or is

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-07-01 Thread Harald van Dijk
On 01/07/2019 10:36, Geoff Clare wrote: Harald van Dijk wrote, on 30 Jun 2019: On 28/06/2019 09:38, Geoff Clare wrote: Harald van Dijk wrote, on 27 Jun 2019: On 27/06/2019 10:04, Geoff Clare wrote: In particular, XRAT's explanation of it is "Conforming applications are required to quote

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-07-01 Thread Geoff Clare
Harald van Dijk wrote, on 30 Jun 2019: > > On 28/06/2019 09:38, Geoff Clare wrote: > >Harald van Dijk wrote, on 27 Jun 2019: > >> > >>On 27/06/2019 10:04, Geoff Clare wrote: > > > >In particular, XRAT's explanation of it is "Conforming applications > >are required to quote or escape the shell

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-30 Thread Robert Elz
Date:Thu, 27 Jun 2019 12:27:55 +0200 From:Joerg Schilling Message-ID: <5d149a2b.tueush4pd3wqoutl%joerg.schill...@fokus.fraunhofer.de> | Note that POSIX is a portable source standard and other shells that may | behave like bash5 currently only compile and work on

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-30 Thread Harald van Dijk
On 28/06/2019 09:38, Geoff Clare wrote: Harald van Dijk wrote, on 27 Jun 2019: On 27/06/2019 10:04, Geoff Clare wrote: Stephane Chazelas wrote, on 26 Jun 2019: Or again, forget all about it and treat the ksh93 behaviour as non-compliant as is already the case. I'm starting to think that

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-30 Thread Harald van Dijk
On 28/06/2019 16:05, Joerg Schilling wrote: Harald van Dijk wrote: That aside, I asked you last time you made this claim about POSIX to back it up. There is no requirement for standard utilities to be implemented portably. You responded then: POSIX intends to create portability at source

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-28 Thread Chet Ramey
On 6/24/19 12:31 PM, Stephane Chazelas wrote: > 2019-06-24 11:52:56 -0400, Chet Ramey: > [...] >>> Before going in the details of the language, can we at least >>> agree on what the "intention" should be? >> >> Your intention is obvious. It's in the part I quoted. >> >> Pathname expansion is

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-28 Thread Chet Ramey
On 6/24/19 11:49 AM, Stephane Chazelas wrote: > Just tried with the current head of the devel branch from today > (5.0.7(5)-maint). > > In an empty dir: > > $ mkdir -m a=r readable > $ mkdir -m a=x searchable > > $ bash5 -c 'printf "%s\n" */.' > searchable/. > $ bash5 -c 'printf "%s\n" */\.' >

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-28 Thread Joerg Schilling
Harald van Dijk wrote: > That aside, I asked you last time you made this claim about POSIX to > back it up. There is no requirement for standard utilities to be > implemented portably. You responded then: > > > POSIX intends to create portability at source code level. > > > > Code that is not

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-28 Thread Geoff Clare
Harald van Dijk wrote, on 27 Jun 2019: > > On 27/06/2019 10:04, Geoff Clare wrote: > >Stephane Chazelas wrote, on 26 Jun 2019: > >> > >>Or again, forget all about it and treat the ksh93 behaviour as > >>non-compliant as is already the case. > > > >I'm starting to think that this is what we

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-28 Thread Stephane Chazelas
2019-06-27 10:48:20 -0400, Chet Ramey: > On 6/27/19 2:15 AM, Stephane Chazelas wrote: > > > I could be convinced that it makes sense for the ksh93 X(...) > > operators to be allowed if there was one non-anecdotal > > implementation of fnmatch() that implemented it, but I don't > > think there it.

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-27 Thread Harald van Dijk
On 27/06/2019 10:04, Geoff Clare wrote: Stephane Chazelas wrote, on 26 Jun 2019: Or again, forget all about it and treat the ksh93 behaviour as non-compliant as is already the case. I'm starting to think that this is what we should do, given the number of oddities you have identified and

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-27 Thread Harald van Dijk
On 27/06/2019 11:27, Joerg Schilling wrote: Stephane Chazelas wrote: Hi, thank you for starting a new discussion that is based on analysing the overall results of the "proposed new behavior". Today, by your reading of the spec and I agree it can be seen as a valid reading, the spec is

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-27 Thread Stephane Chazelas
2019-06-21 18:48:16 +, Austin Group Bug Tracker: [...] > There's another aspect which I haven't mentioned yet (I'll develop more on > that later) where the bash5 behaviour is making things worse when character > sets like BIG5, GB18030 that have characters that contain the encoding of >

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-27 Thread Chet Ramey
On 6/27/19 6:51 AM, Geoff Clare wrote: >>> a='\**' >>> printf '%s\n' $a >>> >>> is a portable script that is meant to list the filenames that >>> start with "*" in the current directory >> >> See 1), there is just one shell that behaves this way. > > And that shell is "bash" (not just "bash5").

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-27 Thread Chet Ramey
On 6/27/19 2:15 AM, Stephane Chazelas wrote: > I could be convinced that it makes sense for the ksh93 X(...) > operators to be allowed if there was one non-anecdotal > implementation of fnmatch() that implemented it, but I don't > think there it. All glibc versions going back a number of years

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-27 Thread Geoff Clare
Joerg Schilling wrote, on 27 Jun 2019: > > Geoff Clare wrote: > > > > > 2. > > > > > > > > a='\**' > > > > printf '%s\n' $a > > > > > > > > is a portable script that is meant to list the filenames that > > > > start with "*" in the current directory > > > > > > See 1), there is just one shell

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-27 Thread Stephane CHAZELAS
2019-06-27 14:04:18 +0200, Joerg Schilling: [...] > > And kresh (netbsd 8.1) and zsh in sh mode. In zshsh, that's > > I cannot check "kresh" as it does not compile on UNIX. Note that you can install NetBSD in a VM in a few minutes. I just did that a few days ago to test that shell's behaviour.

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-27 Thread Joerg Schilling
Stephane Chazelas wrote: > 2019-06-27 11:51:11 +0100, Geoff Clare: > > Joerg Schilling wrote, on 27 Jun 2019: > [...] > > > > 2. > > > > > > > > a='\**' > > > > printf '%s\n' $a > > > > > > > > is a portable script that is meant to list the filenames that > > > > start with "*" in the current

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-27 Thread Joerg Schilling
Geoff Clare wrote: > > > 2. > > > > > > a='\**' > > > printf '%s\n' $a > > > > > > is a portable script that is meant to list the filenames that > > > start with "*" in the current directory > > > > See 1), there is just one shell that behaves this way. > > And that shell is "bash" (not just

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-27 Thread Stephane CHAZELAS
2019-06-27 12:27:55 +0200, Joerg Schilling: [...] > > 4 is portable in practice. 5 as well but only because of the > > buggy fallback string comparison in ksh93. > > So you wrote this because the shell that makes @ special also > has the fallback? [...] Well, it may be tempting to suspect that

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-27 Thread Stephane Chazelas
2019-06-27 11:51:11 +0100, Geoff Clare: > Joerg Schilling wrote, on 27 Jun 2019: [...] > > > 2. > > > > > > a='\**' > > > printf '%s\n' $a > > > > > > is a portable script that is meant to list the filenames that > > > start with "*" in the current directory > > > > See 1), there is just one

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-27 Thread Geoff Clare
Joerg Schilling wrote, on 27 Jun 2019: > > Stephane Chazelas wrote: > > > Today, by your reading of the spec and I agree it can be seen as > > a valid reading, the spec is telling me that: > > > > 1. > > > > a='\.' > > printf '%s\n' $a > > > > is a portable script that is meant to output "." >

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-27 Thread Joerg Schilling
Stephane Chazelas wrote: Hi, thank you for starting a new discussion that is based on analysing the overall results of the "proposed new behavior". > Today, by your reading of the spec and I agree it can be seen as > a valid reading, the spec is telling me that: > > 1. > > a='\.' > printf

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-27 Thread Geoff Clare
Stephane Chazelas wrote, on 26 Jun 2019: > > Or again, forget all about it and treat the ksh93 behaviour as > non-compliant as is already the case. I'm starting to think that this is what we should do, given the number of oddities you have identified and the potential to break existing

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-27 Thread Stephane Chazelas
2019-06-27 08:59:29 +0100, Harald van Dijk: [...] > > 2 is slightly more portable, but even in those shells where it > > does that, that's not because they implement \ processing the > > way POSIX seems to specify it, and all do it a different way. > > I'm not opposing POSIX *allows* a \ in an

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-27 Thread Harald van Dijk
On 27/06/2019 07:15, Stephane Chazelas wrote: 2019-06-26 23:56:06 +0100, Harald van Dijk: [...] You are proposing a fundamental change to the design of pattern matching, not a clarification as you previously called it, and you are now discussing how to allow the behaviour of one specific shell

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-27 Thread Stephane Chazelas
2019-06-26 23:56:06 +0100, Harald van Dijk: [...] > You are proposing a fundamental change to the design of pattern matching, > not a clarification as you previously called it, and you are now discussing > how to allow the behaviour of one specific shell that does not behave the > way you like,

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-26 Thread Harald van Dijk
On 26/06/2019 20:42, Stephane Chazelas wrote: 2019-06-26 17:24:49 +0100, Stephane Chazelas: 2019-06-26 15:32:44 +0100, Geoff Clare: [...] That could be interpreted as implying that a sequence that includes a ( followed by two unquoted ) is required *not* to be treated specially. Yet, @(@(x))

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-26 Thread Stephane Chazelas
2019-06-26 15:32:44 +0100, Geoff Clare: [...] > * the unquoted sequence "{n}" where n consists of one or more digits > > * the unquoted sequence "{m,n}" where m and n consist of zero or more > digits [...] More like: * the sequence "{n}" where n consists of one or more digits and

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-26 Thread Geoff Clare
Stephane Chazelas wrote, on 26 Jun 2019: > > 2019-06-26 12:24:21 +0100, Geoff Clare: > [...] > > On page 2383 line 76232 section 2.13.1 insert a new paragraph: > > > > Implementations may also treat as a special pattern a sequence of > > characters consisting of one of the following,

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-26 Thread Stephane Chazelas
2019-06-26 12:24:21 +0100, Geoff Clare: [...] > On page 2383 line 76232 section 2.13.1 insert a new paragraph: > > Implementations may also treat as a special pattern a sequence of > characters consisting of one of the following, unquoted and not > inside a bracket expression: > >

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-26 Thread Geoff Clare
Stephane Chazelas wrote, on 25 Jun 2019: > That text was probably only to accomodate ast-open/ksh, and it > again overlooked the case of globs in word expansions. We > should be able to limit the damage to ( and \ when not inside > bracket expressions Here's an attempt at fixing this issue

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-25 Thread Stephane Chazelas
2019-06-25 08:51:38 +0100, Harald van Dijk: [...] > > IFS='|' > > text='foo|bar' > > for i in $text; do... > > All of these are fine, since it is about shell special characters during > pattern matching. All the special characters in your examples are removed > before pattern matching starts.

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-25 Thread Harald van Dijk
On 25/06/2019 08:30, Stephane Chazelas wrote: 2019-06-24 21:56:48 +0100, Harald van Dijk: On 24/06/2019 21:15, Stephane Chazelas wrote: But that means that those ksh extended glob operators are not enabled in: pattern='@(x)'; cmd $pattern or case string in $pattern) ... (for the latter, that

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-25 Thread Stephane Chazelas
2019-06-24 21:56:48 +0100, Harald van Dijk: > On 24/06/2019 21:15, Stephane Chazelas wrote: > > But that means that those ksh extended glob operators are not > > enabled in: > > > > pattern='@(x)'; cmd $pattern > > or > > case string in $pattern) ... > > > > (for the latter, that changed in

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-24 Thread Harald van Dijk
On 24/06/2019 21:15, Stephane Chazelas wrote: But that means that those ksh extended glob operators are not enabled in: pattern='@(x)'; cmd $pattern or case string in $pattern) ... (for the latter, that changed in ksh93 which makes it non-compliant; ksh88, pdksh, mksh are still OK). I do not

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-24 Thread Stephane Chazelas
2019-06-24 18:45:55 +0100, Harald van Dijk: [...] > This particular example is already not required to behave in any particular > way for other reasons, but I do not know whether changes to this example > might produce something where an overly strict requirement in POSIX would > prohibit ksh's

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-24 Thread Stephane Chazelas
2019-06-24 18:45:55 +0100, Harald van Dijk: [...] > FWIW, that is not what ksh implements and it might be an unreasonable > requirement on ksh. From its manpage: > > > Following splitting, each field is scanned for the characters ∗, ?, (, > > and [ unless the -f option has been set. [...] > >

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-24 Thread Chet Ramey
On 6/24/19 1:53 PM, Harald van Dijk wrote: > On 24/06/2019 15:16, Chet Ramey wrote: >> On 6/22/19 8:57 AM, Harald van Dijk wrote: >> But in bash5's files='/a/\b/??/x/*' ls -d $files That \ becomes a globbing operator, so we get the same list of files as in a

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-24 Thread Harald van Dijk
On 22/06/2019 06:33, Stephane Chazelas wrote: 2019-06-21 11:15:51 +0100, Geoff Clare: [...] if test -n "$BASH_VERSION"; then eval 'as_f_echo() { printf "%s\n" "$@"; }' as_echo=as_f_echo fi Probably simpler just to put "set -f" at the top of the configure script. (And if globbing is

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-24 Thread Harald van Dijk
On 24/06/2019 15:16, Chet Ramey wrote: On 6/22/19 8:57 AM, Harald van Dijk wrote: But in bash5's files='/a/\b/??/x/*' ls -d $files That \ becomes a globbing operator, so we get the same list of files as in a literal /a/[b]/??/x/*, not a literal /a/\b/??/x/* That doesn't sound right. The

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-24 Thread Harald van Dijk
On 24/06/2019 11:04, Joerg Schilling wrote: Austin Group Bug Tracker wrote: Where you refer to "*every* shell (except bash5 ...)", that's inaccurate because: 1. Robert Elz and Harald van Dijk have shells that behave like bash5. I would be happy to check these shells, but unfortunately they

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-24 Thread Harald van Dijk
On 24/06/2019 16:52, Chet Ramey wrote: On 6/24/19 11:51 AM, Stephane Chazelas wrote: 2019-06-24 09:48:21 -0400, Chet Ramey: On 6/22/19 2:51 AM, Stephane Chazelas wrote: For them, and me, and it seems Eric as well, globbing is an operator that is invoked whenever a word contains an unquoted

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-24 Thread Stephane Chazelas
2019-06-24 11:52:56 -0400, Chet Ramey: [...] > > Before going in the details of the language, can we at least > > agree on what the "intention" should be? > > Your intention is obvious. It's in the part I quoted. > > Pathname expansion is performed on words that contain an unquoted > `*', `?',

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-24 Thread Geoff Clare
Chet Ramey wrote, on 24 Jun 2019: > > On 6/24/19 11:51 AM, Stephane Chazelas wrote: > > 2019-06-24 09:48:21 -0400, Chet Ramey: > >> On 6/22/19 2:51 AM, Stephane Chazelas wrote: > >> > >>> For them, and me, and it seems Eric as well, globbing is an > >>> operator that is invoked whenever a word

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

2019-06-24 Thread Chet Ramey
On 6/24/19 11:51 AM, Stephane Chazelas wrote: > 2019-06-24 09:48:21 -0400, Chet Ramey: >> On 6/22/19 2:51 AM, Stephane Chazelas wrote: >> >>> For them, and me, and it seems Eric as well, globbing is an >>> operator that is invoked whenever a word contains an unquoted >>> wildcard character (in

  1   2   >