On 27/06/2019 09:29, Stephane Chazelas wrote:
2019-06-27 08:59:29 +0100, Harald van Dijk:
[...]
If there is no fnmatch() implementation that behaves that way, then agreed
that it makes sense to just specify that. That pax example in the rationale
should then also be changed to not escape any
The following issue has a resolution that has been APPLIED.
==
http://austingroupbugs.net/view.php?id=1234
==
Reported By:stephane
Assigned
The following issue has been UPDATED.
==
http://austingroupbugs.net/view.php?id=1234
==
Reported By:stephane
Assigned To:
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
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
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
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
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
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
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,
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
>
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
The following issue has been UPDATED.
==
http://austingroupbugs.net/view.php?id=1234
==
Reported By:stephane
Assigned To:
A NOTE has been added to this issue.
==
http://austingroupbugs.net/view.php?id=1234
==
Reported By:stephane
Assigned To:
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
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
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
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
A NOTE has been added to this issue.
==
http://austingroupbugs.net/view.php?id=1234
==
Reported By:stephane
Assigned To:
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
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
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
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
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
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
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.)
>
>
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
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
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
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
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.
>
>
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
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 '['
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.
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
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
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
A NOTE has been added to this issue.
==
http://austingroupbugs.net/view.php?id=1234
==
Reported By:stephane
Assigned To:
The following issue has been UPDATED.
==
http://austingroupbugs.net/view.php?id=1234
==
Reported By:stephane
Assigned To:
The following issue has been set as RELATED TO issue 985.
==
http://austingroupbugs.net/view.php?id=1234
==
Reported By:stephane
The following issue has been set as RELATED TO issue 247.
==
http://austingroupbugs.net/view.php?id=1234
==
Reported By:stephane
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
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
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
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
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
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
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
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
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 \
> >
> >
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)
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
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
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 \*
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
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
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
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
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
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
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
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
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
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
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
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
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
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" */\.'
>
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
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
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.
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
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
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
>
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").
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
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
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.
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
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
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
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
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 "."
>
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
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
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
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
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,
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))
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
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,
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:
>
>
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
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.
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
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
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
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
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. [...]
>
>
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
1 - 100 of 232 matches
Mail list logo
