Hi,

small example…

set a 111222333
regsub {2+} $a {\1kk}

111kk333

the *regsub* does not complain about *non* defined '\1', the *sed* raise an error

LANG=C sed -i -E 's/'\''\$\(\w+_CPPFLAGS\)'\''/'\''@\1@'\''/g' theConfig/ccmsgque/Makefile.am
sed: -e expression #1, char 31: invalid reference \1 on `s' command's RHS

background → if you explicit define an '\1' you assume that an '(...)' is available.
if NOT this is mostly an error.


mfg ao

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 30.03.24 15:32, Gerald Lester wrote:

On 3/30/24 02:29, aotto1968 wrote:

Hi,

small example…

set a 111222333
regsub {2+} $a {\1kk}

111kk333

the *regsub* does not complain about *non* defined '\1', the *sed* raise an error

LANG=C sed -i -E 's/'\''\$\(\w+_CPPFLAGS\)'\''/'\''@\1@'\''/g' theConfig/ccmsgque/Makefile.am
sed: -e expression #1, char 31: invalid reference \1 on `s' command's RHS

background → if you explicit define an '\1' you assume that an '(...)' is available.
if NOT this is mostly an error.

Ah, the man page does not say that.  regsub is not sed.

The \1 ... \9 are the empty string if not matched.

→ yes, make a BUG to a FEATURE and you are fine.

I already had some "problems" because of this BUG because it is *IMPOSSIBLE* to check the
regular expression of the *regsub* to be *valid* again a target replacement.

I understand that you already have code that depends on this BUG but with a "-strict" switch
you have a chance to fix this BUG.

mfg

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-03-31, aotto1968 <[email protected]> wrote:

On 30.03.24 15:32, Gerald Lester wrote:

< --------

Ah, the man page does not say that.  regsub is not sed.

The \1 ... \9 are the empty string if not matched.

→ yes, make a BUG to a FEATURE and you are fine.

I already had some "problems" because of this BUG because it is
*IMPOSSIBLE* to check the regular expression of the *regsub* to be *valid* again a target replacement.

I understand that you already have code that depends on this BUG but
with a "-strict" switch you have a chance to fix this BUG.

mfg

It behaves as documented, so it's not a bug. It's always (as far as I
know) behaved like that, so you are requesting a change - write a TIP !

But I for one would be interested in seeing an example of your
*IMPOSSIBLE* validation.

Eric
--
ms fnd in a lbry

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 31.03.24 14:50, Eric wrote:

On 2024-03-31, aotto1968 <[email protected]> wrote:

On 30.03.24 15:32, Gerald Lester wrote:

It behaves as documented, so it's not a bug. It's always (as far as I
know) behaved like that, so you are requesting a change - write a TIP !

But I for one would be interested in seeing an example of your
*IMPOSSIBLE* validation.

Eric

As I already show in the initial post that *sed* is doing such kind of test. With *IMPOSSIPLE* I mean to check a regular expression in *tcl* is close to *IMPOSSIPLE*.
the *-strict* switch is just an example how to fix this BUG without break *old* code.

just my initial background:

I have a tool called *change.tcl* which read a file and do string/regxp replacement.

the usage is simple: change.tcl -r "from-regexp" "to-something" file...

if the "from-regexp" does not match with "to-something" because of the BUG from above
you end up with "broken" files.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 31 Mar 2024 20:21:58 +0200, aotto1968 wrote:

As I already show in the initial post that *sed* is doing such kind of
test. With *IMPOSSIPLE* I mean to check a regular expression in *tcl* is >close to *IMPOSSIPLE*. the *-strict* switch is just an example how to fix >this BUG without break *old* code.

**************************

I see your point, you do have a point, but it's not impossible.

% set a 111222333
111222333
% regexp {2+} $a -> found1
1
% info exists found1
1
% set found1
<-- empty string
% regexp {(2+)} $a -> found1
1
% set found1
222

So you can always check if something was stored in found1, found2,
found3... etc. There is your safety check. It's only going to cost you
two additional lines.

--
Luc

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

aotto1968 <[email protected]> wrote:

With *IMPOSSIPLE* I mean to check a regular expression in *tcl* is
close to *IMPOSSIPLE*.

Do you know about [regexp -about $RE] ?

First element of its result is the number of subexpressions.
You could check the replacement-string for \\\d sequences that
have a larger digit than the number of subexpressions.


Apart from that, if your code uses an RE and replacement given
from the caller, then the caller alone is responsible for
their correctness... Afterall, if either is wrong, even
if right w.r.t backreferences, then the result file would
still be broken.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 31.03.24 20:47, Luc wrote:

On Sun, 31 Mar 2024 20:21:58 +0200, aotto1968 wrote:

As I already show in the initial post that *sed* is doing such kind of
test. With *IMPOSSIPLE* I mean to check a regular expression in *tcl* is
close to *IMPOSSIPLE*. the *-strict* switch is just an example how to fix
this BUG without break *old* code.

**************************

I see your point, you do have a point, but it's not impossible.

% set a 111222333
111222333
% regexp {2+} $a -> found1
1
% info exists found1
1
% set found1
<-- empty string
% regexp {(2+)} $a -> found1
1
% set found1
222

So you can always check if something was stored in found1, found2,
found3... etc. There is your safety check. It's only going to cost you
two additional lines.

I use *regsub* and in *regsub* you have no place to add some testing code.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 1 Apr 2024 08:17:17 +0200, aotto1968 wrote:

I use *regsub* and in *regsub* you have no place to add some testing code.

You run the test with regexp immediately before you run regsub, in
case you still want to run the regsub depending on the result of the
test.


--
Luc

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)