New /WHO command which allows to specify a format.
NOTES ABOUT THE NEW /WHO COMMAND - 1997 AUGUST 20
m_who() has been rewritten, now the /who command is much more flexible
and provides new options that (I hope) scripters and client coders will
love. Many CPU suckers in there have been shot in the meanwhile.
TOTAL compatibility has been kept with the existing command,
except for the query size limit you can live without reading this, but
if you are a client/script coder you'll miss something interesting :).
Format of the new /who query:
:source WHO "masklist" ["flaglist"[,"quertype"]] ["masklist"]
"masklist" ::= "nowildlist" | "wildmask"
"wildmask" ::= "mask" (matched against all the fields)
"nowildlist" ::= ( channel | nick ) [ , ( channel | nick ) ]...
"flaglist" ::= [(filterflag)]... ['%' (formatflag)... ]
"filterflag" ::= o
"formatflag" ::= c | u | i | h | s | n | f | d | r | t
"querytype" ::= Any number in the range 0-999 (defaults to 0)
Where the 'o' in filterflag has the known "/who 0 o" usage and what comes
after the '%' specifies the fields to be included (order and case is not
significant)
c : Include (first) channel name
d : Include "distance" in hops (hopcount)
f : Include flags (all of them)
h : Include hostname
i : Include IP
n : Include nick
r : Include real name
s : Include server name
t : Include the querytype in the reply
u : Include userID with eventual ~
The default is a %cuisnfr that reports all the standard fields (it
does NOT report the hopcount since it is no more included into the real
name)
The reply can be in two forms:
If now %flags are specified the reply is exactly the same as
has always been, numeric 352, same fields, same order.
If one or more %flags are specified the reply uses a new numeric, since
an out-of-standard 352 crashes EPIC and confuses several other clients.
I used 354.
:"source" 354 "target" ["querytype"] ["channel"] ["user"]
["IP"] ["host"] ["server"] ["nick"]
["flags"] ["hops"] [:"realname"]
Where only the fields specified in the %flags are present.
"querytype" is the same value passed in the /who command, it is provided
to simplify scripting, in example one could pass a certain value in the
query and have that value "signal" back what is to be done with those replies.
Note that:
-
An user doing a "/who whatever" or a "/who whatever o" will not see any
change (except for the anti-flood limit)
-
An user doing a "/who #wasteland %n" will get just a list of nicks (lame,
very lame way of doing it :-)
-
An user doing a "/who 0 o%nuhs" will get a list of the opers with Nick,
userID, server and hostname like:
:Amst* 354 Nemesi #wasteland nbakker pc73.a.sn.no Oslo-2...org
Niels
-
An user doing a "/who 0 o %nuhs,166" will get a list of the opers with
Nick, userID, server and hostname like the above but with a request type
field of 166 like:
:Amst* 354 Nemesi 166 #wasteland nbakker pc73.a.sn.no Oslo-R.NO.EU.Undernet.org Niels
So that he can have in example a script that does "on 354 * 166" display
"There is an oper ..."
The client will have to sort/format the fields by itself, the order
in which flags are passed is not significant, the fields in the reply will
always have the same order.
The maximum number of lines reported as reply for a query is 2048/(n+4)
where 'n' is the number of flags "enabled" that is the number of fields
included in each reply.
Actually: 1 field returned = maximum 409 replies
2 fields returned = maximum 341 replies
3 fields returned = maximum 292 replies
4 fields returned = maximum 256 replies
5 fields returned = maximum 227 replies
6 fields returned = maximum 204 replies
7 fields returned = maximum 186 replies (default query)
8 fields returned = maximum 170 replies
9 fields returned = maximum 157 replies
10 fields returned = maximum 146 replies
You can manage to have even less lines if you care to specify a flag more
than once and/or specify non-existing flags ;-)
If the limit is reached before completing the query the reply is truncated
and a new numeric message is issued after the "End of WHO", anyway the
"end of" numeric is always sent.
The actual query to match can have one of the two following forms:
-
A comma separated list of elements: in this case each element is treated
as a flat channel or nick name and is not matched to the other elements.
Nicks do count in the limit of output lines (they should not be that many
anyway), channels count if who asks the query is not on the channel. (That
is: a /who #channel gives unlimited output if you are in there).
-
A single mask: in this case (no commas, only one element) the mask
is first checked to be a full channel or nickname, then it is matched against
all relevant files as already known. These happens in different steps with
replicates removal so that if one has (?) something like "#wasteland" as
"real name" or is on a channel named "#***MyChan***" it all works nicely.
Miscellaneous bug fixes / "undocumented feature" changes:
-
/who NickName did not show the user with nick = NickName when it was invisible,
even if the nick was given completely (without wildcards) now it does,
since one could always see him as /whois NickName.
It does not report him twice if he also has in example the userID ==
NickName.
-
":source WHO :The Black Hacker" did not report an user having "The Black
Hacker" as real name, now it does. Since this can only be done without
the flags/format specificator because that would become the "last parameter"
an escape has been provided: if you pass to m_who 3 parameters the
first one will be ignored and the last one used for matching, like in example
":source WHO foo %nuh :*Black Hacker*" where "foo" will not be used and
the match will happen on "*Black Hacker*". (It was passed through clean_channelname()
that prevented the mask from containing spaces and such...)
-
When one user was umode -i he was shown or not depending on the fact he
was on a +p or +s channel... since we are doing a lookup on the user
this makes no sense to me, example:
Neme1 : umode -i, on no channels, was SEEN with a /who 0
Neme2 : umode -i, on channel #p with chmode +p, was NOT SEEN by /who
0
Neme3 : umode -i, on channel #s with chmode +s, was NOT SEEN by /who
0
Now all users "-i" are matched with a "/who mask", the +i users instead
must bee on a common channel to be seen.
Basically being on "one" +s|p channel "forced" a +i status while one
might want to be on #secret (mode +s) and have nobody know that he is in
there but on the other side stay -i so others can find him. Of course a
+s|p channel is never shown in the reply unless who asks the query is in
there, if no "visible" channels are available for a -i user he is shown
on "channel *".
-
When one user is +i is shown only if there is a common channel,
the first common channel found is shown in the reply.
-
As requested by many persons an escape has been provided for opers, when
#defined SHOW_ALL_CHANNELS opers can /who #channel from outside and see
users in there even if the channel is +s|+p Admins will have to decide
if remove this feature, enable it or let each admin decide locally.
-
As requested by many admins an escape from the query size limit has been
provided for opers, by #defining UNLIMIT_OPER_QUERY opers can do unlimited
sized /who-s (until they get disconnected by max SendQ exceeded ;)
Again admins will decide if enable or not this feature.
-
A /who a,c,b,d,e,f used to return as many *** END OF WHO as there were
elements in the list, since now the command is supposed to be efficient
for /who nick1,nick2,nick3 .. I return a single end of query message.
(This might be discussed but is quite easy to revert it if the majority
doesn't like it..)
-
/who did not work for a channel named in example #**StarWars** now it does
handle it properly (the mask was passed through collapse() and then.. did
not find that channel, fixed).
-
"/who #John" did not report an user having '#John' as "Real name", now
it does (and does NOT report him twice if he is ALSO on a channel named
#John, strange but true: this can happen).
-
"/who a,b,c,d" where a b c and d are channelnames/nicks now uses an hash
lookup and therefore is extremely efficient, if only one field is
specified it is looked in all the fields; who really wants only
users on a specific channel or a single nick (without looking for a match
in the other fields) can force the server to consider the parameter as
a list adding a comma somewhere, like:
"/who #Italia," or "/who ,Nemesi"
Or even better to avoid misbehavior with other servers:
"/who #Italia %... #Italia," or "/who Nemesi %... Nemesi,"
This will make old servers act properly and new ones and should be the
recommended way for GUI based clients to get a channel's user list and
all the info's they want about users on the channel.
Regards, Andrea aka Nemesi
Questions and comments about this page should go to the maintainer:
Carlo Wood
(Run @ IRC).