nick check

simonbell · Post by **simonbell** » Thu Sep 19, 2002 3:34 pm

Hi

im trying to work out how to implement a check on whether a nick is currently online.

The user would type /msg bot userinfo $nick

and the bot would check whether the user (nick) was online first, then if it is, find the handle in the bot and display some information about it.

I know ive got to use the ISON command, but im not sure how i would implement this. The bot is running on an unreal type ircd.

thanks
Simon

egghead · Post by **egghead** » Thu Sep 19, 2002 3:54 pm

Simon, basically you must send the ISON $nick command to the IRC server.

Refer to section 5.8 of http://www.faqs.org/rfcs/rfc1459.html for info on ISON.

The IRC server will respond to the ISON request with a RAW 303 message RPL_ISON (or a 461 message ERR_NEEDMOREPARAMS)

This RAW message you can catch with a "bind RAW" bound to the RAW numeric 303 or 461. Refer to doc/tcl-commands.doc for info on the "bind RAW". I can write a small sample script, but that will take away your joy of discovering the RFC and the RAW messages.

Note that after the ISON command and its reply, it still is not possible to associate a $handle in the bot's database with the $nick.
Unless that $nick is in the $channel monitored by the bot.
Or unless you retrieve the $userhost of that $nick from the irc-server. Then it is possible to look up the $handle associated with that $nick in the bot's database through its $userhost.
Or unless you are already sure that $nick and $handle are the same.

In case you are only interested in those nicks on a channel monitored by the bot, there is no need to send a request to the irc-server. In that particular case all necessary information is available at the bot.

simonbell · Post by **simonbell** » Thu Sep 19, 2002 4:15 pm

Hi.

this is what i have so far.

this bind/proc to get the bot to issue the command

bind msg - userinfo msg_userinfo
proc msn_userinfo {nick uhost hand arg} {
set nick_requested [lindex $arg 0]
putserv "ISON $nick_requested"
}

then the part which im stuck on

bind raw - 303 rawnickinfo
proc rawnickinfo {from keyw arg} {

ok to be honest im not sure how i would go about actually grabbing what the raw command sent me and determining whether its saying ison :$nick or not...

thanks
Simon

egghead · Post by **egghead** » Thu Sep 19, 2002 4:22 pm

bind msg - userinfo msg_userinfo
proc msn_userinfo {nick uhost hand arg} {
set nick_requested [lindex $arg 0]
putserv "ISON $nick_requested"
}

[lindex] is a list operation, and $arg is a string. So, [lindex $arg 0] is a list operation on a string. It's a sin! Read up the first question in the TCL FAQ

Besides, prolly a bad copy and paste, but the bind asks for the proc "msg_userinfo". The proc supplied is called "msn_userinfo" however.

bind raw - 303 rawnickinfo
proc rawnickinfo {from keyw arg} {

ok to be honest im not sure how i would go about actually grabbing what the raw command sent me and determining whether its saying ison :$nick or not...

Use a putlog "$from, $keyword and $arg" to view what the server sent back. From there on you can evaluate the $arg.

simonbell · Post by **simonbell** » Thu Sep 19, 2002 4:47 pm

ok thanks, ive got that working, now is it possible to pass the information given back to the msg_userinfo proc so i can give a reply via notice to the nick of the person who made the request?

thx
Simon

egghead · Post by **egghead** » Thu Sep 19, 2002 5:06 pm

simonbell wrote:ok thanks, ive got that working, now is it possible to pass the information given back to the msg_userinfo proc so i can give a reply via notice to the nick of the person who made the request?

thx
Simon

Now, this is the tricky part: the bot receives a reply to an ISON request, but it doesn't know which nick requested that info. A straightforward solution is to append the nick of the requester in a global list. Upon receiving the RAW 303, pick the first element (nick) in the global list and send the RAW 303 to that nick. Then remove that first element from the list. (Note that it is possible to have multiple ISON requests pending. It is assumed here that the RAW 303 are received in the same chronological order the ISON requests were sent out).

A bit smarter solution is as follows: ISON allows multiple nicks. So, you can send out an "ISON $nick $nick_requested" i.e. you always make the first nick after ISON, the nick of the requester. This nick is on IRC for sure, so the first element in the reply always is the nick of the requester.
Then what you do is strip the nick of the requester from the server response, review if there is anything left in the response and send it back to the requester. Perform these actions in your "rawnickinfo" procedure.

Passing back information to msg_userinfo will not work.

Additionally, it is a bit cumbersome too explain here what to do if the requester changes its nick in between the ISON request and the asynchronous RAW 303 server reply. Especially if that nick was not on any of the channels the bot is monitoring.

stdragon · Post by **stdragon** » Thu Sep 19, 2002 7:54 pm

Just a suggestion, why don't you use an easier command like WHOIS?

Also, I don't know if this works on all servers, but you can use the PING command to see if someone is online on dalnet. Watch, if my nick is dbirdy2, and asdf is not online, but stgoat is:

ping asdf
:elysium.ga.us.dal.net PONG elysium.ga.us.dal.net :asdf
ping stgoat
:elysium.ga.us.dal.net PONG elysium.ga.us.dal.net :dbirdy2

If the user is online, it returns your nick. If the user is offline, it returns exactly what you sent.

stdragon · Post by **stdragon** » Thu Sep 19, 2002 7:55 pm

Oh nevermind, the PING thing doesn't fix the basic problem of not knowing who the replies are for (in the case of success).

egghead · Post by **egghead** » Fri Sep 20, 2002 1:43 am

stdragon wrote:Just a suggestion, why don't you use an easier command like WHOIS?

ssstttt... part 2 of the suggestion, once the ISON script is working, is to look at the USERHOST command

stdragon · Post by **stdragon** » Fri Sep 20, 2002 2:33 am

Heh I don't get it.

Papillon · Post by **Papillon** » Fri Sep 20, 2002 4:21 am

just have a look at the babelist.tcl script in the tcl-script section. I think it does almost exactly what u want to do, all u need to do is modify it a bit

darko`` · Post by **darko``** » Fri Sep 20, 2002 12:18 pm

Why not use nick2hand function? It will give you the handle of the user that matches specified nickname and from there on there are a lot of commands available to manipulate userinfo.

egghead · Post by **egghead** » Fri Sep 20, 2002 12:36 pm

stdragon wrote:Heh I don't get it.

Simon wanted to do the following:

and the bot would check whether the user (nick) was online first, then if it is, find the handle in the bot and display some information about it.

That nick can be online, but not necessarily on a channel monitored by the bot. By sending a "USERHOST $nick_requester $nick_requested" to the server, the server will respond with the userhost of the $nick_requester and (possibly) with the userhost of the $nick_requested if that nick is online.

Based on the nick and userhost of $nick_requested, eggdrop's database can be searched through for a matching handle and the associated information of that handle.

Since the USERHOST lookup is asynchronous, it is unknown where to send this information. But by including the $nick_requester in the USERHOST, the nick of the requester is known when the response of the irc server is received by the bot..

egghead · Post by **egghead** » Fri Sep 20, 2002 12:40 pm

darko`` wrote:Why not use nick2hand function? It will give you the handle of the user that matches specified nickname and from there on there are a lot of commands available to manipulate userinfo.

Sure. Now what if the requested nick is not on a channel monitored by the bot?

darko`` · Post by **darko``** » Fri Sep 20, 2002 1:06 pm

If user is not on a channel, there still will be a reply from the bot, providing the bot knows that user IS a real user on the bot and not some person simply matching the someone's hostmask. You question infact prompted me to think in a different light now, cause i couldn't have ever imagined that someone is going to script something purely on the basis of matching hostmasks. Now that i know that such people do exist, i'll have to reconsider the way i give advices, taking into account all possible (no metter how insecure) requests.