Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possible misformatting for set_mode messages #137

Open
kenneaal opened this issue Mar 4, 2020 · 1 comment
Open

Possible misformatting for set_mode messages #137

kenneaal opened this issue Mar 4, 2020 · 1 comment

Comments

@kenneaal
Copy link
Contributor

kenneaal commented Mar 4, 2020

Attempts to set modelines on channels fail; pydle merely gets a banlist in return, probably indicating the message is misformatted.

Code:
await bot.set_mode("#test", "+b *!*@99.99.99.99")

Debug output:

DEBUG:XX:yy:>> MODE #test :+b *!*@99.99.99.99
DEBUG:XX:yy:<< :irc.fuelrats.dev 368 XX #test :End of Channel Ban List
WARNING:FIDO:fuelrats:Unknown command: [irc.local] 368 ['XX', '#test', 'End of Channel Ban List']

I do not think MODE messages can take a : before the modeline being set.

Edit:
await bot.set_mode("#test", "+b", "*!*@99.99.99.99") does work. This is poorly documented, and not really a sane way to handle modelines, IMO.

@ZeroKnight
Copy link
Contributor

ZeroKnight commented Jun 17, 2020

The code

await bot.set_mode("#test", "+b *!*@99.99.99.99")

results in the ill-formed message MODE #test :+b *!*@99.99.99.99 because of the way that set_mode calls rawmsg:
https://github.com/Shizmob/pydle/blob/e583c9b57526604f87b01b8eacfdbee26dc31c2b/pydle/features/rfc1459/client.py#L370

The call chain ultimately lands in RFC1459Message.construct:
https://github.com/Shizmob/pydle/blob/e583c9b57526604f87b01b8eacfdbee26dc31c2b/pydle/features/rfc1459/parsing.py#L97-L131
Due to the logic in the for loop, it interprets the argument "+b *!*@99.99.99.99" as a trailing parameter, which prepends a : and produces an erroneous message.

I feel that the signature that @kenneaal attempted to use is more intuitive than the current one. At the very least, the documentation could be a bit clearer on usage.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants