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 par
The following issue has a resolution that has been APPLIED.
==
http://austingroupbugs.net/view.php?id=1234
==
Reported By:stephane
Assigned T
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 I
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 unspeci
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 sentence
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 internal
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 otherwis
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:
===
The following issue has been set PARENT OF issue 0001295.
==
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 ma
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 comp
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
http://austingroupbugs.net/view.php?
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
> >---
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 instead
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
imple
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 4
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 Li
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 diff
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 configu
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 c
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 compon
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 searc
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 e
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.
>
> Th
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 pe
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 '[' th
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. This
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 contains
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 treated
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
Assigned
The following issue NEEDS AN INTERPRETATION.
==
http://austingroupbugs.net/view.php?id=1234
==
Reported By:stephane
Assigned To:
The following issue has been set as RELATED TO issue 247.
==
http://austingroupbugs.net/view.php?id=1234
==
Reported By:stephane
Assigned
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 backslash,
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 q
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 quoti
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,
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 s
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 specia
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.
>
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 \
> >
> > Whic
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
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) escape
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
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 ch
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 \* c
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 wi
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
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 agai
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 esc
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 is
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 gre
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 spe
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 a
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 cod
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 perfor
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 should
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 the
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 tellin
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
> backsla
2019-06-27 10:55:12 -0400, Chet Ramey:
[...]
> > And that shell is "bash" (not just "bash5"). All versions I tried do
> > it (including bash3 on macOS).
>
> This behavior has been in the bash pattern matcher since the pre-1.0
> releases. The oldest version I have built is bash-2.05b, but the code
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 i
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 t
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.
Yo
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 di
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 "ba
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 k
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 shel
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 '%s\
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
applicatio
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 unqu
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 t
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, but
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 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)) is still special in ksh93, and the exte
2019-06-26 15:32:44 +0100, Geoff Clare:
[...]
> Implementations may also treat as a special pattern a sequence of
> characters consisting of one of the following, not inside a bracket
> expression:
>
> * an unquoted '?' or '*' character
>
> * a (quoted or unquoted) '+', '@', '
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, unqu
1 - 100 of 257 matches
Mail list logo
