It's pointless and looks stupid.
It will look even more stupid when we enable multiline, because the
suffixes will be in the middle of the concatenated message.
Sometimes (very rarely), the test errors with:
```
======================================================================
FAIL: testHistsearch (Aka.test.AkaChannelTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/supybot/test.py", line 214, in runTest
originalRunTest()
File "/usr/lib/python3/dist-packages/supybot/plugins/Aka/test.py", line 67, in testHistsearch
self.assertResponse('histsearch .*', '@echo foo')
File "/usr/lib/python3/dist-packages/supybot/test.py", line 402, in assertResponse
self.assertEqual(m.args[1], expectedResponse,
AssertionError: '@aka add histsearch "last --from [cif true[80 chars]"]]"' != '@echo foo'
- @aka add histsearch "last --from [cif true \"echo test\" \"echo test\"] --regexp [concat \"m/$1/\" [re s/g// \"@2\"]]"
+ @echo foo
: '@echo foo' != '@aka add histsearch "last --from [cif true \\"echo test\\" \\"echo test\\"] --regexp [concat \\"m/$1/\\" [re s/g// \\"@2\\"]]"'
```
ie. histsearch returns the 'aka add' message instead of the 'echo foo'
one.
My guess is that if they happen too closely to each other, they get
added to the history in the wrong order (how? it's not threaded)
So this commit works around the issue by making the regexp unambiguous.
_sendToOthers expects msg.channel to be 'in otherIrc.state.channels',
but IrcMsg objects don't have their 'channel' attribute set until they
are passed through irclib, so it was left unset, which means messages
were never sent at all.
Regression introduced in c1ae3f5c81.
Otherwise, if some IP addresses don't work (eg. all odd ones), the bot will
consecutively fail because it can't connect, then connect + get STS + reconnect,
then fail again, then connect + get STS, etc.
Fixes a regression in ecc2c32950 that caused
Socket.py to ignore the IP address entirely after computing it, and
to call getSocket() and connect() with the hostname instead.
FAIL: testMoreIsCaseInsensitive (Misc.test.MiscTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File /home/travis/virtualenv/python3.8-dev/lib/python3.8/site-packages/supybot/test.py, line 214, in runTest
originalRunTest()
File ./plugins/Misc/test.py, line 260, in testMoreIsCaseInsensitive
self.assertNotError('more %s' % nick.upper())
File /home/travis/virtualenv/python3.8-dev/lib/python3.8/site-packages/supybot/test.py, line 355, in assertNotError
m = self._feedMsg(query, **kwargs)
File /home/travis/virtualenv/python3.8-dev/lib/python3.8/site-packages/supybot/test.py, line 526, in _feedMsg
response = self.irc.takeMsg()
File /home/travis/virtualenv/python3.8-dev/lib/python3.8/site-packages/supybot/log.py, line 368, in m
return f(self, *args, **kwargs)
File /home/travis/virtualenv/python3.8-dev/lib/python3.8/site-packages/supybot/irclib.py, line 1308, in takeMsg
assert not msg.tagged('emulatedEcho')
AssertionError
I don't understand why it's happening or why it's only that specific test,
but there we go.
Plugins implementing inFilter do not set receivedAt, so incoming messages
rewritten by inFilter would be detected as echo messages, and ignored
by most plugins.
running supybot-adduser (or supybot-reset-password) with a recent
python would result in the warning:
> ```
> /usr/local/bin/supybot-adduser:59: SyntaxWarning: "is not" with a literal. Did you mean "!="?
> if len(args) is not 1:
> ```
This commits corrects the syntax.
`
Even if they are not trusted. This fixes a regression in
97016b9c55.
This happens because 'user._checkCapability' raises a KeyError
when the user has neither this cap or the anticap; which was mistakenly
caught here by the 'except KeyError' expecting to catch non-existing
users.
(And that why 'try' blocks should be limited to as few lines as possible.)
This reverts commit 1fe414764c.
I initially wrote that commit so that plugins with echoMessage=True can
get the nick/prefix from the message (eg. the SkypeRelay plugin in my
personal repo).
Unfortunately, this breaks any test that does equality comparison on
between the result of getMsg()/takeMsg() and an IrcMsg object they
crafted themselves.
Additionally, the filled in nick and prefix might be inaccurate if the
bot changes nick/host at the same time. So instead plugins should check
for the None value.
(Also, editing IrcMsgs on the fly like this isn't great, and the commit
forgot to reset the `_str` attribute.)
"Search not found in the last X *messages*" is a bit confusing because this is really counting the entire history, which includes all other lines of IRC communication (this means pings, /NAMES replies and so on).
Reported by fred` at #limnoria.
This adds a new message tag applied to all messages SedRegex has seen, in addition to the one for marking messages parsed as a regexp.
SedRegex will now look through the message history and check that all messages without the "seen" tag are not in fact a regexp, before
marking it as seen so that it doesn't do repeated work.
This is a safe command for admins to allow as it's limited to text reminders,
unlike the equivalent scheduler.add (+ misc.echo) which usually needs to be
restricted to prevent abuse
It showed 'Not replying to <command> in None,', since channel is None in
private (unlike the former msg.args[0], which was the bot's nick).
I wasn't careful enough when I replaced msg.args[0] with msg.channel
across the codebase.
This is not a regression; this was already forbidden before
23417b0675, and this commit was not
tagged/released yet at the moment I'm writing this one.
