Help find 2nd occurrence and replace
Cesar Silva last edited by
Hello everyone I am trying to find the 2nd occurence of ; and replace with TTT but I am not able to come up with one. I tried to run the on below but it’s not working for me. My line is:
and I wanted to be
Here is what I have tried
Terry R last edited by Terry R
I am trying to find the 2nd occurence of ;
Your regex got close I see. I edited it a bit and came up with the following rough solution. It works with your examples.
I used an online tester to get the solution as above. Try https://regex101.com/
guy038 last edited by guy038
Don’t forget your leading
(?-s)or detail a setting for the
. matches newlinecheckbox. I find the former easier.
I think maybe the OP attempted to “abstract” the data for us by using
So perhaps an even better search term would be:
“Better” as in : more restrictive to avoid changing unintended areas that just happen to match
guy038 last edited by
Very clever, indeed. You’are right about it : this look-ahead, alone, is enough to, precisely determine the position of the zero-length string ;-))
Your remarks are pertinent, too !. Finally, the best regex S/R, regarding the OP, should be :
4people needed to reach the pantheon of regular expressions, pheew ;-))
(?-s)is no longer needed. :-)
For readers that don’t know why that is true: It is only needed if a
.appears in the regular expression.
guy038 last edited by
So, @Alan-kilborn has the last word !
Don’t forget your leading (?-s) or detail a setting for the . matches newline checkbox. I find the former easier.
Oh, no, too much typewriting - it’s sunday morning :)
Now, getting serious, you’re right on general cases, but in this particular one, given the data structure, that modifier has no effect at all. OP could check the
. matches newlineoption but the output would be exactly the same.
Of course, in other cases or situations it could do a lot of harm. Granted.
but in this particular one, given the data structure
Yep, given the data structure…
…but what if what the OP has shown is only part of a huge file, with vastly different types of data in different sections of the file? The user does a Replace All, verifies the section that they are currently looking at (cool, looks good!), doesn’t notice the other sections, saves, quits, they a few days later notices all of the unintended replacements in other sections of the file. Too late!
It’s better to be safer, rather than potentially sorrier. My general rule: If I use a
.in a regex, I always specify (?s) or (?-s) ahead of it, and ignore the
. matches newlinebox.
Of course, it is problem in that posters with questions of these type rarely give enough information to give foolproof solutions.
Also, I’ve noticed that you’re “casual” about the
. matches newlineor
(?-s)specifications in other thread’s postings, when it is NOT as clear cut as this thread’s is. Just a word to “be careful” – this setting matters a lot when it comes to regex.
As far as I can understand, you take a more protective attitude towards OP than me, maybe experience had taught you that. It’s fine and have nothing against it. However, in my case and in the absence of any compelling reason I try to respond as accurately as possible to the data exemplified, assuming that the posted example is representative of the data set to be processed. In other words, I am confident that OP made a correct analysis of the issue.
Which is the best approach? Neither is unreasonable a priori, nor are wrong those who decided to take a more or less intermediate position. I suppose context would help to make better decisions - see my second example, below.
Concerning the casual point, what I understand - and if I am wrong, please correct me - is that the modifier
(?s)or its negated form has real significance when it is quantified, i.e. affected by
+. I mean, given this data:
Line1 Line2 Line3 Line4
a search expression as
Lin.\dwill get four matches, no matter what adjustment has been made -
(?-s). In this case it is useless to take precautions. However, if a quantifier is added, either
+, then the regex in one match could find the whole set given the
. matches newlineis checked.
Thus, in the last regex I posted, https://community.notepad-plus-plus.org/post/52389, in which the data provided was insufficient, I took due precautions to control the regex, changing the modifier as appropriate so that the regex would do the desired job correctly.
Anyway, rest assured that my posts aim to help people, as far as my limited knowledge allows. And if any response of mine is not entirely adequate, it will have been by unintentional error, but never by malice.
I am confident that OP made a correct analysis of the issue.
I guess you haven’t read as many of these types of postings as I have.
You’re predicating your subsequent statements on that “correct analysis”. :-)
Sure the case of
.by itself (not in a
.+?construct, and some others less frequently used) is fairly immune to trouble; for Windows files (which is what we talk about mostly, obviously) a single
.shouldn’t be able to cause line-ending harm (it would take two
.to match the
It’s okay, I was just trying to offer some friendly advice concerning
.. I think it has been beat to death.
rest assured that my posts aim to help people,
Of course. I think you’ve been a strong contributor to date.
guy038 last edited by guy038
Yes, at first sight, we could think that a single regex dot character, between two characters, is handled in a same way, whatever the state of the
sin-line modifier and/or the state of the
. matches newlineoption
But it’s not always the case :-( For instance, let’s suppose the
3-lines text, below, with
UnixEOL, the last line without any EOL, and a space char between the last two
(?s)c.cwould match, successively, the
7strings cbc , c1c , c
LFc , cZc , c9c , c
LFc and c c, so all the text !
Whereas the regex
(?-s)c.cwould match the
5strings cbc , c1c , cZc , c9c and c c, only !
Therefore, it is best to remain precise and indicate the modifiers
(?-s), whenever necessary ;-)
It’s okay, I was just trying to offer some friendly advice concerning …
And I took it like this. What’s more, it’s even good advice, since I only considered the case of Windows, ignoring Unix and Mac.
Thank you, and I’ll keep that in mind.