This was introduced in 232d2612fe which
tries to split a line by spaces and then tries splitted[1] and
splitted[2] which will cause a SIGABRT if the line isn't actually that
long.
This also uses the 4th argument to the 301 line to determine if this
message is because we sent a message to ourselfs. Previously the 3rd
option was used, which is always our own nick. This was resulting in any
301 line being halted.
Downside of antiidle is that because it messages yourself internally
the irc server will send messages to you when you're marked as away.
This can end up being really annoying, so those messages are blocked
with these changes.
Signed-off-by: Toon Schoenmakers <nighteyes1993@gmail.com>
This should stop all fights against ChanServ. Please note that nothing will
happen if we are the only one in the channel after 15 secs since this module
only checks if it needs to do something when someone leaves a channel.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Modern/decent networks have services anyway, and for registered channels
this module is useless. Also it tends to fight ChanServ in case if
ChanServ joins/parts the channel to remove ops.
Users of deprecated ne^W^Wnetworks without services can use it from extra.
This was broken since znc-0.098-17-g64e565c (563bce5987)
which introduced possibility of log module to specify wanted path as argument.
Thanks to turnor for reporting this.
This causes every piece of code which wants to use CFile or CDir to have to
include FileUtils.h. This causes quite some noise.
Signed-off-by: Uli Schlachter <psychon@znc.in>
As a result, Utils.h no longer has to include Socket.h and lots of stuff breaks.
Due to a severe case of lazyness, some of the code for CExecSock is still in
Utils.cpp. Feel free to fix if you really have to.
Signed-off-by: Uli Schlachter <psychon@znc.in>
shell didn't compile since 6bc36d1708 because it used the
three-argument-version of CModule::PutModule(). This commit replaced that with a
call to CModule::PutUser().
Signed-off-by: Uli Schlachter <psychon@znc.in>
If you did ./configure --enable-tcl, tcl wasn't actually enabled because
--enable-extra was missing, That's less than optimal.
Just moving modtcl out of modules/extra solves this problem.
Big thanks go to zynox/kylef for noticing this!
Signed-off-by: Uli Schlachter <psychon@znc.in>
When someone connects to ZNC, this connection is first handled by an instance of
CIncomingConnection. Once we determined if this is a HTTP or an IRC connection,
the connection is handed of to the appropriate class.
The CIncomingConnection instance that was used first will still linger around
for the next event loop iteration and then be destroyed. Since this socket isn't
a "real" connection anymore (another instance of Csock took over for this one),
listsockets should ignore all sockets in state CLT_DEREFERENCE.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@2213 726aef4b-f618-498e-8847-2d620e286838
Patch by kylef and submitted via git. Sorry that we are using subversion and
that subversion is bad at tracking this kind of authorship. :(
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@2211 726aef4b-f618-498e-8847-2d620e286838
Saving a pointer in a map seems like a bad idea and means we have to delete all
the contained stuff by hand when the channel is destroyed. This requires us to
loop through the channel which is slow. A map is meant as a container, so use it
as one and directly save the stuff we want it to save in there.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@2175 726aef4b-f618-498e-8847-2d620e286838
Since the user can't read detached channels, there is no point in clearing their
buffer. Let's leave them alone instead.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@2151 726aef4b-f618-498e-8847-2d620e286838
"virtual host" seems to be confusing to users since they wonder why
i.am.superman doesn't work. Let's rename this to "bindhost" and perhaps it
becomes clearer what this setting does.
Thanks to SilverLeo!
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@2113 726aef4b-f618-498e-8847-2d620e286838
