@NisseEngström That pattern looks like it's already caught by Pattern-matching website in answer and Pattern-matching website in body; append -force if you really want to do that.
### ErrorReturnCode_1 on teward/Solar Flare at 2019-04-27T16:01:18Z:
RAN: /usr/bin/git pull
STDOUT:
STDERR: You are not currently on a branch. Please specify which branch you want to merge with. See git-pull(1) for details.
git pull <remote> <branch>
File "/home/smokey/SmokeDetector/chatcommunicate.py", line 453, in __call__ result = self.__func__(*processed_args) File "/home/smokey/SmokeDetector/chatcommands.py", line 724, in pull GitManager.pull_remote() File "/home/smokey/SmokeDetector/gitmanager.py", line 382, in pull_remote
@double-beep You are not a privileged user. Please see the privileges wiki page for information on what privileges are and what is expected of privileged users.
@double-beep You are not a privileged user. Please see the privileges wiki page for information on what privileges are and what is expected of privileged users.
OK. It should be back to normal. I also had NobodyNada/Raspberry Pi pull the current version. It was running a version from February, which was probably causing the auth issue.
@Machavity That's strange. At least it got there in the end. If you're talking about getting code-admin, there are multiple things that need to be changed. There are changes on metasmoke, GitHub, and PullApprove. After the change on metasmoke, SD has to have !!/amicodeprivileged run in order to update its cached information. Alternately, SD should update its cache when restarted.
@Makyen Ok, third time is the charm I think. This regex should match all the binfer.com addresses, but not match anything else, like fbinfer.com /(.+\.|/)binfer\.com(?![.-]) Works on regex101 and in MS search
@Machavity Yes, your methodology was a bit off, due to not being aware of what's added to the regex when it's created from the regex text stored in the bad_keywords.txt and watched_keywords.txt files. The actual regexes are constructed here and two lines below.
For blacklisted keywords and the watchlist, the regex you !!/watch or !!/blacklist-keyword is bookended by \b (more or less; you can look in the code for exactly what's used, or I repeat it here).
For example, !!/blacklist-keyword binfer actually searches the text with a regex that's equivalent to \bbinfer\b.
Thus, for testing entries targeting either the blacklisted keywords or watchlist, you should test the regex with \b at the start and end. If you're using . in the regex, then you should also set the s flag, as that changes the meaning of the . wildcard.
The blacklisted websites and blacklisted usernames regexes are not bookended by \b, so are much more likely to erroneously catch things that are unintended and FP (particularly the blacklisted websites list).
Note: for the watchlist and keyword blacklist the bookending is actually a bit more complex than just \b, but that only matters when you're trying to match the actual start/end of the post's body/title/username string and that string starts/ends with a character in the \W class, or when using a regex that has non-latin Unicode characters/words.
The start/end of string issue is that \b doesn't match a \W character to end of string transition, nor start of string to \W character transition. So, for preceding the regex (?:\b|^) is used, while (?:\b|$) is used for after the regex.
[Note: all post bodies start with an HTML tag and end with a closing HTML tag. As a result, post bodies always start and end with a \W character. However, only a few of our regexes actually search for those.]
The (?w:\b) that's also used in the regex bookending is specific to the regex package and matches word/non-word transitions as more complexly defined in Unicode, which is an issue for writing using non-latin characters.
@Machavity Sorry, I should have sent at least the first part of that ^ earlier.
Yeah, I know the feeling. I had several regexes that didn't work quite the way I intended until I got more familiar with the specifics of the regex package.
Yes, but because you are using ., you need to set the s flag. In this case, you'll find that the regex will run-on from URL to URL. You should also be careful about having the m flag set. Sometimes it's convenient for testing multiple things at a time, but it's not set in the actual regex (unless you set it in your regex), so the performance will be different, if you are using ^ or $ in your regex.
In addition, we have a preference for using non-capturing groups (?:) instead of capturing groups () as compute performance is better with non-capturing groups.
@Machavity The blacklisted websites are intended to also match the domain in plain text, so we can't rely on having a / prior to the domain. The character prior to a domain could be most \W, but not -, as that's a valid character in domains. In addition, there are some instances where domains are obfuscated with other characters surrounding them. I'm mixed about capturing subdomains for the why data. My concern about it might give the impression that we're actually looking for it.
@Machavity I don't see what the (?!\W\-) is intended to do. It will never be the case when the next character is b, which is the only thing that will match the rest.
We currently don't have an entry for binfer.com in the website blacklist. You removed the entry here.
In the interim, I'd suggest re-adding \b(?<!-)binfer\.com(?![.-])\b
I thought I'd put it back 12 hours ago, but it appears I didn't. In the meantime, I'm going to go ahead and re-add that ^. Feel free to keep working on it and remove/update it when you have something you like better.
[ SmokeDetector | MS ] Url in title, bad keyword in body, body starts with title and ends in url, potentially bad ns for domain in body, potentially bad ns for domain in title, +2 more (294): www.factsofhealth.info/entramax/ by yodayrfaei on wordpress.SE
[ SmokeDetector | MS ] Few unique characters in answer, luncheon meat detected, no whitespace in answer, potentially bad keyword in answer, repeating characters in answer (308): Get Hashset Key by asfffffffffffff on stackoverflow.com
