Hi, @alan-kilborn and All,
Indeed, as the \A is not working properly, a lot of particular cases occur and I confess that detailing them all is a bit tedious work !
Regarding your first question :
I don’t see the connection here…where is the dot regex being used?
The fact of the simple . regex does not match the FF character, of Unicode code-point \x{000C} means that, it is implicitly seen as a non-standard character, i.e. a pseudo EOL character !
So, from the @Terry-r’s solution (?<!\x0A)^, which can be rewritten as (?<!\n)^, I first added the \r case to the negative look-behind, to handle MAC files and then added the Form Feed character case in case some of these chars are present in current file giving the final form (?<!\n|\r|\f)^
For instance, assuming the text, below, where three Form Feed chars ( \x{000c} ) are inserted between the strings 12345 and 67890 of the first line
12345 67890
This is a test
to verify
-----><-----
some oddities
on this very
simple text
Paste this text in a new tab
Now, open the Replace dialog
SEARCH (?<!\n|\r)^ ( The \f is not present )
REPLACE ABC
Tick the Wrap around option
Select the Regular expression search mode
Put the caret, on the line -----><----- between symbols > and <
Click on the Replace All button
You get the text :
ABC12345 ABC ABC ABC67890
This is a test
to verify
-----><-----
some oddities
on this very
simple text
As you can see, it correctly adds the string ABC at beginning of file, but also after each FF character :-(
Now, change the search regex as (?<!\n|\r|\f)^
Put the caret, on the line -----><----- between symbols > and <
Click on the Replace All button
This time, we have the expected text, with the string ABC , inserted at beginning if the first line, only ;-))
ABC12345 67890
This is a test
to verify
-----><-----
some oddities
on this very
simple text
So, the 3 syntaxes (?<!\n|\r|\f)^, \^A and also \A^ are correct work-arounds to the bugged \A assertion, used alone !
Note, Alan, that the syntax \A^ seems a bit more logic than the opposite form ^\A. However, remark that two consecutive assertions are commutative. For instance, the regexes ^$ and $^ are equivalent as, both, searches for a location which is, either, a beginning and an end of lines and match the zero-length location at the beginning of any empty line
Similarly, two consecutive look-around, which can be considered as user’s assertions, are commutative too ! For instance, the regexes (?-s)(?=ABC)(?=.*XYZ).+ and (?-s)(?=.*XYZ)(?=ABC).+ are equivalent and match any non-null range of chars, beginning with ABC, till the end of current line, if, in addition, the string XYZ occurs from right after ABC till the end of current line !
I hope that these lines answer to your third question :
I understand why the earlier (?<!\x0A)^ or (?<!\n|\r|\f)^ work, but ^\A is hard to get one’s head around
Now, contrary to the 3 correct regex syntaxes, above, the initial regex S/R, against our sample text :
SEARCH \A
REPLACE ABC
gives the complete mess, below, adding the string ABC after any existing character :-((
ABC1ABC2ABC3ABC4ABC5ABC ABC ABC ABC6ABC7ABC8ABC9ABC0ABC
ABCTABChABCiABCsABC ABCiABCsABC ABCaABC ABCtABCeABCsABCtABC
ABCtABCoABC ABCvABCeABCrABCiABCfABCyABC
ABC-ABC-ABC-ABC-ABC-ABC>ABC<ABC-ABC-ABC-ABC-ABC-ABC
ABCsABCoABCmABCeABC ABCoABCdABCdABCiABCtABCiABCeABCsABC
ABCoABCnABC ABCtABChABCiABCsABC ABCvABCeABCrABCyABC
ABCsABCiABCmABCpABClABCeABC ABCtABCeABCxABCtABC
ABC
Now, regarding your second question :
I’m not sure I’m following this, either.
How about some real examples that you are usually so good at? :-)
Well, if we still assume our sample text :
12345 67890
This is a test
to verify
-----><-----
some oddities
on this very
simple text
Let’s use, now, the following regex S/R, with Wrap around, Regular expression set and the caret between the >< string :
SEARCH \A^
REPLACE ABC\r\n ( Note that we add some EOL chars, at the end of the replacement regex )
As expected, after clicking on the Replace All button, we obtain the text, with the line ABC inserted before the present first line
ABC
12345 67890
This is a test
to verify
-----><-----
some oddities
on this very
simple text
Now, hit Ctrl + Z to undo the changes
Hit 3 times on the Enter key, to create three empty lines, beginning current file
Re-run the same S/R
This time, we get :
ABC
ABC
ABC
ABC
12345 67890
This is a test
to verify
-----><-----
some oddities
on this very
simple text
Which is not, obviously, what it is expected ! This is the reason why I said :
In case of your replacement regex ends with the forms \r\n, \n or \r, depending of your file(s) structure, as above, the file(s) must not begin with one/several true empty lines !
Finally :
Hit, again, Ctrl + Z to undo the changes
Use the initial regex S/R, below, against our sample text, with the first three empty lines :
SEARCH \A
REPLACE ABC\r\n
This time, it’s even worse ! As you can see, below , everything seems to go wrong for all ;-(((
ABC
ABC
ABC
ABC
1ABC
2ABC
3ABC
4ABC
5ABC
ABC
ABC
ABC
6ABC
7ABC
8ABC
9ABC
0ABC
ABC
TABC
hABC
iABC
sABC
ABC
iABC
sABC
ABC
aABC
ABC
tABC
eABC
sABC
tABC
ABC
tABC
oABC
ABC
vABC
eABC
rABC
iABC
fABC
yABC
ABC
-ABC
-ABC
-ABC
-ABC
-ABC
>ABC
<ABC
-ABC
-ABC
-ABC
-ABC
-ABC
ABC
sABC
oABC
mABC
eABC
ABC
oABC
dABC
dABC
iABC
tABC
iABC
eABC
sABC
ABC
oABC
nABC
ABC
tABC
hABC
iABC
sABC
ABC
vABC
eABC
rABC
yABC
ABC
sABC
iABC
mABC
pABC
lABC
eABC
ABC
tABC
eABC
xABC
tABC
ABC
Best Regards,
guy038
