eggheads / eggdrop

The Eggdrop IRC Bot
GNU General Public License v2.0
496 stars 88 forks source link

ctcp action is also binded with pubm #1313

Open crazycatdevs opened 1 year ago

crazycatdevs commented 1 year ago

When doing a /me in a channel (probably in pvmsg too), the eggdrop react on ctcp and on pubm.

I found this since I use 1.9.3 RC1:

bind ctcp - "ACTION" tact
bind pub - * tpub
bind pubm - * tpubm

proc tact {nick uhost hand chan key text} {
   putserv "PRIVMSG $chan :* <$nick> $text"
}
proc tpub {nick uhost hand chan text} {
   putserv "PRIVMSG $chan :<$nick> $text"
}
proc tpubm {nick uhost hand chan text} {
   putserv "PRIVMSG $chan :<$nick> $text (m)"
}

In channel :

08:45:22 <Jarvis> * <CrazyCat> does a test 2
08:45:24 <Jarvis> <CrazyCat>  ACTION does a test 2 (m) 
crazycatdevs commented 1 year ago

cf #1314 : CAP echo-message

crazycatdevs commented 1 year ago

I reopen this issue because I got the trouble with eggdrop 1.9.3 stable.

CAP enabled invite-notify extended-join sasl account-notify

Test script

bind ctcp - "ACTION" tact
bind pubm - * tpubm

proc tact {nick uhost hand chan key text} {
   putserv "PRIVMSG $chan :ACT <$nick> $text"
}
proc tpubm {nick uhost hand chan text} {
   putserv "PRIVMSG $chan :PUBM <$nick> $text"
}

Result

* CrazyCat shows the trouble
<Jarvis> ACT <CrazyCat> shows the trouble
<Jarvis> PUBM <CrazyCat>  ACTION shows the trouble 

As you can see, the two binds react to a /me, but this time the trouble doesn't come from echo-message.

I can reproduce that on any 1.9.3 stable eggdrop

thommey commented 1 year ago

I assume you expect Eggdrop to check if the message is of the format \001 + msg + \001 and only treat it as CTCP and not a pub(m). The difficulty in that is that Eggdrop supports or at least intends to support an obscure feature called "embedded CTCP". It is specified in one of the various CTCP draft standards, e.g. https://www.irchelp.org/protocol/ctcpspec.html With it, you can combine a CTCP with a message or other CTCPs, so it blurs the line between "CTCP" and "message" a bit. I guess pubm could try to not match on the CTCP part of the message but that is a bit more complicated than it seems at first glance. There could also be a situation of mismatched or missing \001 end tags that would need to be handled somehow.

vanosg commented 1 year ago

Is there an action to take on this? Or is this 'intended functionality' ?

Stali0N commented 9 months ago

Hello, Not sure if it's related but if so, this cause an issue with flood protection. Because the bot count it as 2 separate messages see example below (this is the channel log from the eggdrop): [22:14:12] Action: alxd slaps ManCcChaSse around a bit with a large trout [22:14:12] ACTION slaps ManCcChaSse around a bit with a large trout [22:14:13] yo man [22:14:18] feek [22:14:23] feel [22:14:23] #quebec: mode change '+mD ' by WatchDog!quebec@WatchDog.users.undernet.org [22:14:24] #quebec: mode change '+b !@Alerion.users.undernet.org' by X!cservice@undernet.org [22:14:24] alxd kicked from #Quebec by X: (WatchDog) Trop de message en un cours lapse de temps (Text Flood) [id: 495]

The text flood is set to 4:7 (between :12 and :18 there is 6 seconds) I just don't know why it triggered the protection only at the 5th message and not right after the 4th one... Unless there is a delay and the bot was just lagging...

DreadDuchess commented 1 month ago

This issue continues to occur in 1.9.5.