14 Ocak 2022 Cuma tarihinde Christoph Anton Mitterer
yazdı:
> Which is impossible again, especially in a portable manner, when it's
> ambiguous what a valid RE is.
Except it's not. Use a delimiter that doesn't appear in the RE and you're
good.
> But since it is neither specified how the
On Fri, 2022-01-14 at 13:03 +0300, Oğuz wrote:
> Yes you can, and it can be that simple. Providing a valid RE is
> application developer's responsibility
Which is impossible again, especially in a portable manner, when it's
ambiguous what a valid RE is.
> Backslash not being special inside a
>
On Fri, 2022-01-14 at 00:10 -0800, Don Cragun wrote:
> It isn't that simple.
IMO it's even more complex ;-)
> When you find the first delimiter, you can't look for the second
> delimiter in the middle of a bracket expression and you can't look
> for the second delimiter in the middle of a
On Fri, 2022-01-14 at 09:07 +0300, Oğuz wrote:
> > And where does it say that? I mean in the standard.
> > I.e. where does it say, that parsing is only allowed to happen in
> > one
> > stage from left to right, especially not only with respect to an RE
> > itself, but also when an RE is embedded
On Fri, Jan 14, 2022 at 11:10 AM Don Cragun wrote:
> It isn't that simple. The string between the first and second delimiters in
> a substitute command has to be an RE (and "[" can't be the end of an RE; it
> is the start of a bracket expression). Note also that is not
> special inside a
> On Jan 13, 2022, at 10:07 PM, Oğuz via austin-group-l at The Open Group
> wrote:
>
> On Thu, Jan 13, 2022 at 6:36 PM Christoph Anton Mitterer
> wrote:
>> And where does it say that? I mean in the standard.
>> I.e. where does it say, that parsing is only allowed to happen in one
>> stage
On Thu, Jan 13, 2022 at 6:36 PM Christoph Anton Mitterer
wrote:
> And where does it say that? I mean in the standard.
> I.e. where does it say, that parsing is only allowed to happen in one
> stage from left to right, especially not only with respect to an RE
> itself, but also when an RE is
btw: Things seem even worse, as also non-special characters used as
delimiters may be affected by implementation-ambiguities:
GNU sed:
$ printf '%s\n' '9+' | sed 's+9\++X+'
X
$ printf '%s\n' '99+' | sed 's+9\++X+'
9X
$ printf '%s\n' '999+' | sed 's+9\++X+'
99X
=> these results are IMO
On Thu, 2022-01-13 at 10:04 +0300, Oğuz via austin-group-l at The Open
Group wrote:
> > a) Is it defined, how the unescaping of delimiters vs. special
> > characters happens?
> > Consider the following example:
> > s(\\((X(
> > There are at least two ways to parse that:
>
> I see only one. From
Clicked Reply instead of Reply All, sorry.
-- Forwarded message -
From: Oğuz
Date: Thu, Jan 13, 2022 at 9:40 AM
Subject: Re: sed and delimiters that are also special characters to REs
To: Christoph Anton Mitterer
On Tue, Jan 11, 2022 at 1:15 AM Christoph Anton Mitterer via
Hey Don.
On Mon, 2022-01-10 at 22:27 -0800, Don Cragun wrote:
> * In a context address, the construction "\cREc",
> where c is any character other than
> or , shall be identical to "/RE/". If
> the character designated by c appears following
> a , then it
> On Jan 10, 2022, at 2:15 PM, Christoph Anton Mitterer via austin-group-l at
> The Open Group wrote:
>
> Hey.
>
> Maybe someone can help me with this (or point out that it's undefined -
> and perhaps should be):
>
> I was looking into when BREs/EREs are used with delimiters (i.e. sed's
>
Hey.
Maybe someone can help me with this (or point out that it's undefined -
and perhaps should be):
I was looking into when BREs/EREs are used with delimiters (i.e. sed's
s- and y-commands) that are also special characters with respect to the
respective RE syntax.
There were some things which
13 matches
Mail list logo
