From Newsgroup: comp.lang.tcl

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
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.tcl

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.


--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.tcl

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
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.tcl

On 3/31/24 06:27, aotto1968 wrote:

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.

Please submit a TIP for adding a strict switch with a sample
implementation.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.tcl

On 2024-03-31, aotto1968 <aotto1968@t-online.de> 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
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.tcl

On 31.03.24 14:50, Eric wrote:

On 2024-03-31, aotto1968 <aotto1968@t-online.de> 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.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.tcl

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

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.tcl

aotto1968 <aotto1968@t-online.de> 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.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.tcl

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.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.tcl

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

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.tcl

On 4/1/24 01:17, aotto1968 wrote:

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.

Use the varname with regsub and place the substituted string in a temp variable. Then check the return value of regsub to see if the count is
what you expected it to be.


--- Synchronet 3.20a-Linux NewsLink 1.114