Date:Mon, 25 Jun 2018 17:30:25 +0200
From:tlaro...@polynum.com
Message-ID: <20180625153025.ga2...@polynum.com>
| About the POSIX description "2.13.1 Patterns Matching a Single
| Character", have the draft assigned a precedence between "XBD RE Bracket
| Expression
Hello,
About the POSIX description "2.13.1 Patterns Matching a Single
Character", have the draft assigned a precedence between "XBD RE Bracket
Expression" and the shell behavior, i.e. "XBD RE Bracket"
taking precedence over the shell behavior?
Because one might interpret the reference to "XBD RE
Rhialto wrote:
> On Mon 25 Jun 2018 at 01:58:25 +0700, Robert Elz wrote:
>> Date:Sun, 24 Jun 2018 19:09:58 +0200
>> From:Rhialto
>> Message-ID: <20180624170958.gj8...@falu.nl>
>>
>> | Are we to assume that NetBSD's sh(1) manual page is correct?
>>
>> Well, yes an
On Mon 25 Jun 2018 at 01:58:25 +0700, Robert Elz wrote:
> Date:Sun, 24 Jun 2018 19:09:58 +0200
> From:Rhialto
> Message-ID: <20180624170958.gj8...@falu.nl>
>
> | Are we to assume that NetBSD's sh(1) manual page is correct?
>
> Well, yes and no...
>
> | Since tha
Date:Sun, 24 Jun 2018 19:09:58 +0200
From:Rhialto
Message-ID: <20180624170958.gj8...@falu.nl>
| Are we to assume that NetBSD's sh(1) manual page is correct?
Well, yes and no...
| Since that clearly says that your example above should not match.
Actually, it doe
On Sun 24 Jun 2018 at 19:49:25 +0700, Robert Elz wrote:
> But the effect of that way of doing the specification is that the \
> which escapes magic characters in regular expressions does
> not work inside [ ] (and the text is explicit about that - and correct)
> which means the technique in the pro
On Sun, Jun 24, 2018 at 09:55:25PM +0700, Robert Elz wrote:
> Date:Sun, 24 Jun 2018 15:52:21 +0200
> From:tlaro...@polynum.com
> Message-ID: <20180624135221.gb...@polynum.com>
>
> | It's a mess...
>
> Yes...
>
> | Wouldn't it be simple for POSIX to let the case.
Date:Sun, 24 Jun 2018 15:52:21 +0200
From:tlaro...@polynum.com
Message-ID: <20180624135221.gb...@polynum.com>
| It's a mess...
Yes...
| Wouldn't it be simple for POSIX to let the case...esac
| as is and introduce a ecase...esac[e] (à la grep, egrep) with somet
Well, discard my suggestion : you have already answered: the problem
is that the "*" is already used as meaning litteral '*' so my point
of view is incompatible with the existing standard.
It's a mess... Wouldn't it be simple for POSIX to let the case...esac
as is and introduce a ecase...esac[e] (
[For reader, please refer to Robert Elz' whole enlightening answer. I
edit it]
On Sun, Jun 24, 2018 at 07:49:25PM +0700, Robert Elz wrote:
> | - [Suppression of the double quotes?
>
> This is, of course, the heart of the matter...
>
> In POSIX, quote removal is explicitly not done on case
> pat
Date:Sun, 24 Jun 2018 13:19:00 +0200
From:tlaro...@polynum.com
Message-ID: <20180624111859.ga...@polynum.com>
First, thanks for reading the message, and looking at the tests
and sending the comments/question - this is exactly the kind of
response I was hoping for.
Asi
Hello,
On Sun, Jun 24, 2018 at 05:11:34PM +0700, Robert Elz wrote:
> Hi all,
>
> I am soon going to add an ATF test for sh pattern matching (it tests all
> 3 forms, glob expansion, case patterns, and ${var#patern})
>
>[...]
>
> [97] var="[:alpha:]"; case "[" in (["$var"]) printf M;; (*) printf
Hi all,
I am soon going to add an ATF test for sh pattern matching (it tests all
3 forms, glob expansion, case patterns, and ${var#patern})
There are many tests, some of them quite esoteric...
First a general heads up ... the glob tests need files to match
against, and many of them ... so the te
13 matches
Mail list logo
