WHO documentation, updated on 02 Jan 1999.
-Since ircu2.10.02 the WHO command had been changed from what
-described in RFC1459, while still keeping backward compatibility,
-actually it has been changed again in u2.10.05 so that since this
-release the format of the who query is now:
+Since ircu2.10.02 the WHO command had been changed from what described in
+RFC1459, while still keeping backward compatibility, actually it has been
+changed again in u2.10.05 so that since this release the format of the who
+query is now:
[:source] WHO <mask1> [<options> [<mask2>]]
-<mask2> is optional, if mask2 is present it's used for matching and
-mask1 is ignored, otherwise mask1 is used for matching, since mask2
-is the last parameter it *can* contain a space and this can help
-when trying to match a "realname".
+<mask2> is optional, if mask2 is present it's used for matching and mask1 is
+ignored, otherwise mask1 is used for matching, since mask2 is the last
+parameter it *can* contain a space and this can help when trying to match a
+"realname".
When matching IP numbers the <mask> can be in 3 forms:
- The old and well known IRC masks using * and ? as wanted
- The IPmask form a.b.c.d/e.f.g.h as used in most firewalls and
- system configurations, where what is before the / are the bits
- we expect in the IP number and what is after the / is the
- "filter mask" telling wich bits whould be considered and wich
- should be ignored.
-- The IPmask form a.b.c.d/bitcount where bitcount is an integer
- between 0 and 31 (inclusive), the matching will be for the IPs
- whose first "bitcount" bits are equal to those in a.b.c.d
+ system configurations, where what is before the / are the bits we expect
+ in the IP number and what is after the / is the "filter mask" telling wich
+ bits whould be considered and wich should be ignored.
+- The IPmask form a.b.c.d/bitcount where bitcount is an integer between 0
+ and 31 (inclusive), the matching will be for the IPs whose first
+ "bitcount" bits are equal to those in a.b.c.d
Note that:
. The bitcount must be between 0 and 31, 32 is NOT good (and
- makes no sense to use it... just match against the static IP
- a.b.c.d)
-. The missing pieces of both the bitmask and the ipnumber in
- the forms ipnumber/bitmask and ipnumber/bitcount default to
- zero from right to left, this is NOT what inet_aton and most
- tools do but makes more sense here IMO, in example /who 194.243/16
- is taken as /who 194.243.0.0/255.255.0.0 (inet_aton whould
- take 194.243 as 194.0.0.243).
-. For the above reason and specified validity limits 1.2.3.4/31
- becomes 1.2.3.4/255.255.255.254 while 1.2.3.4/32 becomes
- 1.2.3.4/32.0.0.0 :)
-
-For all the other fields th match happens as has always been,
-i.e. it's only considered the IRC mask with * and ? (that is:
-don't expect to catch an user with "realname" = "1.2.3.4" when
-doing "/who 1.2/16 h" :)
-
-For both the masks and the options (and thus for all flags) case is
-NOT significative (so "/who <any> o" is exactly the same as
-"/who <ANY> O".
-
-The "options2 part can be as follows:
+ makes no sense to use it... just match against the static IP a.b.c.d)
+. The missing pieces of both the bitmask and the ipnumber in the forms
+ ipnumber/bitmask and ipnumber/bitcount default to zero from right to left,
+ this is NOT what inet_aton and most tools do but makes more sense here
+ IMO, in example /who 194.243/16 is taken as /who 194.243.0.0/255.255.0.0
+ (inet_aton whould take 194.243 as 194.0.0.243).
+. For the above reason and specified validity limits 1.2.3.4/31 becomes
+ 1.2.3.4/255.255.255.254 while 1.2.3.4/32 becomes 1.2.3.4/32.0.0.0 :)
+
+For all the other fields th match happens as has always been, i.e. it's only
+considered the IRC mask with * and ? (that is: don't expect to catch an user
+with "realname" = "1.2.3.4" when doing "/who 1.2/16 h" :)
+
+For both the masks and the options (and thus for all flags) case is NOT
+significative (so "/who <any> o" is exactly the same as "/who <ANY> O".
+
+The "options" part can be as follows:
[<flags>][%[<fields>[,<querytype>]]]
-in wich:
+in which:
- <flags>: can be a sequence of field matching flags, use mode matching
- flags and special purpose flags
+ <flags>: can be a sequence of field matching flags, use mode matching flags
+ and special purpose flags
- Field matching flags, when one of these is specified the field in
+ Field matching flags, when one of these is specified the field in
question is matched against the mask, otherwise it's not matched.
n Nick (in nick!user@host)
i Numeric IP (the unresolved host)
s Servername (the canonic name of the server the guy is on)
r Info text (formerly "Realname")
+ a Account name
- If no field-matching flags are specified they default to what
- old servers used to do: nuhsr (= everything except the numeric IP)
+ If no field-matching flags are specified they default to what old servers
+ used to do: nuhsr (= everything except the numeric IP)
- User mode matching flags (specifying one of these means that only
- clients with that umode are considered, what is not specified
- is always matched):
+ User mode matching flags (specifying one of these means that only clients
+ with that umode are considered, what is not specified is always matched):
+ d Join-delayed channel members
o Irc operator
[In the future more flags will be supported, basically all
usermodes plus the +/- specificators to revert the filtering]
Special purpose flags:
- x If this is specified the extended visibility of information
- for opers is applied, what this means depends on the fact that
- you are local or global operator and on how the admin configured
- the server (global and eventually local irc opers might be
- allowed with this flag to see +i local users, to see all +i users,
- to see users into +p and/or +s channels, and so on). Using the 'x'
- flag while not beeing irc operator is meaningless (it will be
- ignored), using it while oper'd means that the query is almost
- certainly logged and the admin might (rightfully) ask you an
- explanation on why you did.
-
- The rest, what follows the %, that is [%[fields[,<querytype>]]],
- is as it has always been since the first who.patch, the <fields> part
- specifies wich fields to include in the output as:
+ x If this is specified the extended visibility of information for opers
+ is applied, what this means depends on the fact that you are local or
+ global operator and on how the admin configured the server (global
+ and eventually local irc opers might be allowed with this flag to see
+ +i local users, to see all +i users, to see users into +p and/or +s
+ channels, and so on). Using the 'x' flag while not being an irc
+ operator is meaningless (it will be ignored), using it while oper'd
+ means that the query is almost certainly logged and the admin might
+ (rightfully) ask you an explanation on why you did.
+
+ The rest, what follows the %, that is [%[fields[,<querytype>]]], is as it
+ has always been since the first who.patch, the <fields> part specifies
+ wich fields to include in the output as:
c : Include (first) channel name
d : Include "distance" in hops (hopcount)
f : Include flags (all of them)
h : Include hostname
i : Include IP
+ l : Include idle time (0 for remote users) [2.10.11+]
n : Include nick
r : Include real name
s : Include server name
t : Include the querytype in the reply
u : Include userID with eventual ~
+ a : Include account name
+ o : Include oplevel (shows 999 to users without ops in the channel)
-And the ,<querytype> final option can be used to specify what you want
-the server to say in the querytype field of the output, useful to
-filter the output in scripts that do a kind of "on 354 ..."
+And the ,<querytype> final option can be used to specify what you want the
+server to say in the querytype field of the output, useful to filter the
+output in scripts that do a kind of "on 354 ..."
-If no %fields are specified the reply is _exactly_ the same as
-has always been, numeric 352, same fields, same order.
+If no %fields are specified the reply is _exactly_ the same as has always
+been, numeric 352, same fields, same order.
-If one or more %fields are specified the reply uses a new numeric,
-since an out-of-standard 352 crashes EPIC and confuses several other
-clients. I used 354.
+If one or more %fields 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"]
+ ["flags"] ["hops"] ["idle"] ["account"]
+ [:"realname"]
Where only the fields specified in the %fields options 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.
-
-The number of lines in the reply is still limited to avoid self-flooding
-and sooner or later another limitation will be added: you will be forced
-to do no more than one /who query every 'n' seconds where 'n' depends
-on the number of fields you actually match (the field-match flags specified
-before % in the option, defaulting to 6 if you don't specify an option
-at all), infact matching against many fields as the default query does
-severely affects the CPU usage of the server and is *much* better to
-specify with the field-atching flags what you are looking for, in example
-when you are looking for all french users a "/who *.fr h" is A LOT
-better than just "/who *.fr" (and actually you want users that have the
+"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.
+
+The number of lines in the reply is still limited to avoid self-flooding and
+sooner or later another limitation will be added: you will be forced to do
+no more than one /who query every 'n' seconds where 'n' depends on the
+number of fields you actually match (the field-match flags specified before
+% in the option, defaulting to 6 if you don't specify an option at all),
+infact matching against many fields as the default query does severely
+affects the CPU usage of the server and is *much* better to specify with the
+field-matching flags what you are looking for, in example when you are
+looking for all french users a "/who *.fr h" is A LOT better than just "/who
+*.fr" (and actually you want users that have the
_hostname_ matching *.fr, you wouldn't want to match a japanese user
that has the realname "ku fung-kay aj.fr" in example...)
Note that:
- An user doing a "/who whatever" or a "/who whatever o"
- will not see any change (except for the anti-flood limit
- and sooner or later the CPU usage limit)
+ will not see any change (except for the anti-flood limit and sooner or
+ later the CPU usage 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 #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:
+- 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*.org Niels
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 ..."
+ on ^354 "% 166" display "There is an oper ..."
- The client will have to sort/format the fields by itself,
- the _order_ in wich flags are passed is not significant,
- the fields in the reply will always have the same order.
+ 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.
+ 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
9 fields returned = maximum 157 replies
10 fields returned = maximum 146 replies
- If the limit is reached before completing the query the
- reply is truncated and a new numeric error is issued after
- the "End of WHO", anyway the "end of" numeric is _always_
- sent (otherwise some scripts and clients get crazy).
+ If the limit is reached before completing the query the reply is truncated
+ and a new numeric error is issued after the "End of WHO", anyway the "end
+ of" numeric is _always_ sent (otherwise some scripts and clients go
+ crazy).
The actual "mask" 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 fiels 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.
+ 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 fiels 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
- wildchars) 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 and is -i.
-
-- ":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...)
+- /who NickName did not show the user with nick = NickName when it was
+ invisible, even if the nick was given completely (without wildchars) 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 and is
+ -i.
+
+- ":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:
+ 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.
+ Now all users "-i" are matched with a "/who mask", the +i users instead
+ must be on a _common_ channel to be seen.
- Basically beeing 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 *".
+ 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.
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 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 misbehaviour with other servers:
"/who #Italia %... #Italia," or "/who Nemesi %... Nemesi,"
- This will make old servers act properly and new ones and should
- be the reccomended way for GUI based clients to get
- a channel's userlist and all the infos they want about users
- on the channel.
+ This will make old servers act properly and new ones and should be the
+ recomended way for GUI based clients to get a channel's userlist and all
+ the infos they want about users on the channel.
+
+- If you use the new numeric, flags will contain all the information about
+ a user on a channel. @ for op'd, + for voiced, and ! for zombie. eg:
+ Isomer #coder-com H@+, where the old behavor of just displaying one of
+ them has been preserved for the old numeric. [2.10.11+]
Regards, Andrea aka Nemesi
projects / ircu2.10.12-pk.git / blobdiff