Forums Developers managing the user list with /ruser

I'm using version 6.03 and take advantage of the user list to easily identify visitors to my channel according to their roles. For example:

.auser -a 100 $nick 8

then I can discriminate among users by userlevel, either for identification as members of a certain class, or for granting rights to use remote bot commands.

This works well except for two problem area. Address mask form 8 includes nickname, e-mail address, and host name, but(1) users occasionally change their e-mail addresses, and (2) the host name changes if the domain changes, or if the ISP uses IP address instead of DNS name.

After a while, outdated entries clutter the users.ini file. Using /ruser hasn't been as successful as I hoped: the command

/ruser 100 $nick 8

will only remove the entry matching the current user mask, while

/ruser $nick -or- /ruser $nick !

won't match any entry in the users.ini file.

I've specifically chosen address mask form 8 to minimize false matches on visitors who might have the same ISP, especially since the help file entry for /ruser stated that the '$nick !' form would eliminate all entries.

Suggestions will gratefully be accepted on ways to script removal of outdated entries in users.ini.

One way would be to add $ctime to the userlist entry line as "info"
.guser -a 100 $nick 8 $ctime

You could then update the info when the person joins the channel.
on *:join:#channel:{
.iuser $address($nick,8) $ctime
}

Then to flush old entries, check "if $calc($ctime - $ulist().info > X" (seconds), and ruser if it is

that's an interesting idea, but it will only work if the address mask is unchanged, which unfortunately cannot be guaranteed as users change nicknames and ISPs.

The /ruser command seems to be intimately linked with the current value of the user's address -- I'm trying to find a way to match old, outdated entries in the users.ini file and have had no luck so far.

If you use masktype 3 with /guser, there is only a fraction of users who will still have problems.
(type 3 = *!*identd@*.host.domain)
All the variable parts have been wildcarded. The only problem is when a ISP varies more than just one part of the mask, which is not common.

Actually, several dial-up ISPs (notably in the UK) typically vary 2 or 3 parts of the domain name depending on the dial-up pool. Also, perhaps 20% of my users' report an IP address rather than domain name, a significant portion of them being dial-up, so two octets of the IP address typically are different with each iteration.

Nobody ever promised this would be easy.

Thats the point of /iuser and $ctime, it will update entries with $ctime, then you can loop through $ulist() and find old, outdated entries. Then you can create an alias to loop through the $ulist() entries, checking the times since last seen and now. You can either run the alias manually, or set it to execute on some event trigger, such as "on start/on connect/on me:*:join:" or so.

Here is an example. I used 604800 (1 week) for this but you can change that to whatever you like.

It looks like you're adding an unnecessary space before the exclamation mark, and that's why the command is ineffective. Try this:

//auser level nick!*1@*.2.3 | auser level nick!*4@*.5.6 | ruser nick!

You'll notice this time /ruser removes any entry beginning with 'nick!'.

Also I'd like to suggest an alternative authentication system that uses only 1 entry per user at all times, see a sample here.

I have a new grandchild arriving today or tonight, so I won't be able to give your suggestion a try with my users.ini file for a day or so, but thanks for the suggestions!

I already keep a file with join and leave times, indexed by nickname, and will look to that to be a first source of time information, although I do like your suggestion about /iuser and $ctime -- maybe that will turn out to be the best way to deal with outdated entries in users.ini.

I'll let you know what my test results are in a day or so.

I've not had any luck with /ruser nick! <--no space

It had always returned an error when used in a script, but I gave it a try from the status window data entry box just now and it was successful.

Curious -- that probably implies an error in my script that I didn't see earlier. I'll do some more testing in a day or so -- can't get to it sooner because my daughter-in-law is probably giving birth this afternoon or evening and I'm going to be a bit distracted, as you can imagine!

Thanks for the input: once again it looks like what I thought was being sent to the command interpreter (at least in my script) is not quite what I thought it was.

Will let you know in a day or so.

yep! there was an unprintable character in my script that got inserted between the nickname and the exclamation point so that the script fragment

/ruser $nick $+ !

actually produced

/ruser name.! <--where (".") represents the unprintable character

this form of the /ruser command does, indeed, work exactly as advertised.

Thanks to all who commented....