Regular expression for *not* a *sequence* of characters
-
@JonB said in Regular expression for *not* a *sequence* of characters:
How do you do "not a sequence of chars"?
RegExp does not have (and probably never will) this construct. The argument is that it can easily be inverted from the calling code, i.e. write the regex that matches the sequence and then instead of
if(regexp.match())you'd useif(!regexp.match())"La mort n'est rien, mais vivre vaincu et sans gloire, c'est mourir tous les jours"
~Napoleon BonaparteOn a crusade to banish setIndexWidget() from the holy land of Qt
-
@JonB said in Regular expression for *not* a *sequence* of characters:
How do you do "not a sequence of chars"?
RegExp does not have (and probably never will) this construct. The argument is that it can easily be inverted from the calling code, i.e. write the regex that matches the sequence and then instead of
if(regexp.match())you'd useif(!regexp.match())@VRonin
Ah, now we're getting somewhere --- that might explain why I don't know how to do it! I thought it could be done using one of these new-fangled "negative lookahead/behind" constructs, but no? You've set me a challenge now... :)It seems strange to me that reg exs can cope with "not one character" but not with "not multiple characters".
I know I can do it "in code" as you have shown. But Qt has various places which allow a reg ex filter/matcher, e.g. a
QLineEditvalidator which I think has to match for the validation to succeed. I could use[^*]to reject any line with*in it. But to reject lines which have**in them, you're saying I cannot use a plain reg ex validator string and have to go write some kind of code (I think the Qt validators allow for that, but that's not my point)?EDIT
(?<!foo)Negative Lookbehind Asserts that what immediately precedes the current position in the string is not fooThis is probably what I was thinking about. So, for example, I presume:
^.*(?<!\*\*)$rejects lines which end with
**, which is "rejecting by a sequence of characters"? [Yep, tested.] Can we expand on this to implement the "not" in-line instead? -
@VRonin
Ah, now we're getting somewhere --- that might explain why I don't know how to do it! I thought it could be done using one of these new-fangled "negative lookahead/behind" constructs, but no? You've set me a challenge now... :)It seems strange to me that reg exs can cope with "not one character" but not with "not multiple characters".
I know I can do it "in code" as you have shown. But Qt has various places which allow a reg ex filter/matcher, e.g. a
QLineEditvalidator which I think has to match for the validation to succeed. I could use[^*]to reject any line with*in it. But to reject lines which have**in them, you're saying I cannot use a plain reg ex validator string and have to go write some kind of code (I think the Qt validators allow for that, but that's not my point)?EDIT
(?<!foo)Negative Lookbehind Asserts that what immediately precedes the current position in the string is not fooThis is probably what I was thinking about. So, for example, I presume:
^.*(?<!\*\*)$rejects lines which end with
**, which is "rejecting by a sequence of characters"? [Yep, tested.] Can we expand on this to implement the "not" in-line instead? -
@kshegunov That works because of
^/$you can't matchabc ** this is matching ** but not this ** and this is a new one ** defwhere the sequence to exclude is** -
@kshegunov , @VRonin
The following is probably what you're both saying. But it is possible to "only match a complete line which does not contain**anywhere in it" (e.g. for aQLineEditvalidator) by (https://stackoverflow.com/a/406408/489865, also an example at https://www.regextester.com/15, they call it "Match string not containing string"):^((?!\*\*).)*$Which I certainly never knew!
@VRonin
I don't know what you mean by your last post (yes, the reg ex does include^/$), would you care to clarify? I suspect it's to do with "group capturing as opposed to whole match", but not at all sure. -
@kshegunov That works because of
^/$you can't matchabc ** this is matching ** but not this ** and this is a new one ** defwhere the sequence to exclude is**I haven't tried to. As far as understood the question - match lines that do not contain.
@JonB
Pretty much the same idea as what I used.Read and abide by the Qt Code of Conduct
-
I haven't tried to. As far as understood the question - match lines that do not contain.
@JonB
Pretty much the same idea as what I used.@kshegunov
Yes it is what you used (though your example really confused me with its[^t]|tin it, did you just complicate it to test me out? ;-) )There is something in @VRonin 's final statement where he accepts use of
^/$but then says "you can't match..." where I do not know what he is trying to convey... -
@kshegunov
Yes it is what you used (though your example really confused me with its[^t]|tin it, did you just complicate it to test me out? ;-) )There is something in @VRonin 's final statement where he accepts use of
^/$but then says "you can't match..." where I do not know what he is trying to convey...@JonB said in Regular expression for *not* a *sequence* of characters:
Yes it is what you used (though your example really confused me with its [^t]|t in it, did you just complicate it to test me out? ;-) )
Surely not. It just seemed more natural to me - match anything but
tORtthat's not followed by "[t]his thing" ... seemed like kind of the human way of doing it ;PThere is something in @VRonin 's final statement where he accepts use of ^/$ but then says "you can't match..." where I do not know what he is trying to convey...
I think he just misunderstood the question and wants to match stuff that's between
**pairs ...Read and abide by the Qt Code of Conduct
-
@JonB said in Regular expression for *not* a *sequence* of characters:
Yes it is what you used (though your example really confused me with its [^t]|t in it, did you just complicate it to test me out? ;-) )
Surely not. It just seemed more natural to me - match anything but
tORtthat's not followed by "[t]his thing" ... seemed like kind of the human way of doing it ;PThere is something in @VRonin 's final statement where he accepts use of ^/$ but then says "you can't match..." where I do not know what he is trying to convey...
I think he just misunderstood the question and wants to match stuff that's between
**pairs ...@kshegunov
Surely. Have you heard of "KISS"? :-; When trying to illustrate your use of((?!.....).)*, which is what I needed to learn as the solution, do you think adding the extra stuff would make it easy for me to understand which bit was the principle? :)I always respect what @VRonin writes. But when he said:
RegExp does not have (and probably never will) this construct.
it now seems to me that it does have such a construct, unless he explains just what he meant...
-
@kshegunov
Surely. Have you heard of "KISS"? :-; When trying to illustrate your use of((?!.....).)*, which is what I needed to learn as the solution, do you think adding the extra stuff would make it easy for me to understand which bit was the principle? :)I always respect what @VRonin writes. But when he said:
RegExp does not have (and probably never will) this construct.
it now seems to me that it does have such a construct, unless he explains just what he meant...
@JonB said in Regular expression for *not* a *sequence* of characters:
it now seems to me that it does have such a construct
It does not have a generic way. It has a "line does not contain" or "document does not contain". Say you want to capture stuff inside**(so\*\*(.+?)\*\*) but exclude the capture if.+?matchesfoo. I don't think that is possible.Forget what I said.
"La mort n'est rien, mais vivre vaincu et sans gloire, c'est mourir tous les jours"
~Napoleon BonaparteOn a crusade to banish setIndexWidget() from the holy land of Qt
-
@JonB said in Regular expression for *not* a *sequence* of characters:
it now seems to me that it does have such a construct
It does not have a generic way. It has a "line does not contain" or "document does not contain". Say you want to capture stuff inside**(so\*\*(.+?)\*\*) but exclude the capture if.+?matchesfoo. I don't think that is possible.Forget what I said.
