X-Git-Url: http://git.pk910.de/?a=blobdiff_plain;f=doc%2Freadme.who;h=4a1649e16bf76d1b6286a3392f26b10d47819b9a;hb=refs%2Fheads%2Fupstream-ssl;hp=419abbe7178c3a540970f9d51ef18b2965260e4a;hpb=b70944c4b84fc2b707d0853ddf03975569dac2bd;p=ircu2.10.12-pk.git diff --git a/doc/readme.who b/doc/readme.who index 419abbe..4a1649e 100644 --- a/doc/readme.who +++ b/doc/readme.who @@ -1,62 +1,56 @@ 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 [ []] - 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". + 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 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 o" is exactly the same as -"/who 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 o" is exactly the same as "/who O". + +The "options" part can be as follows: [][%[[,]]] -in wich: +in which: - : can be a sequence of field matching flags, use mode matching - flags and special purpose 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) @@ -65,92 +59,95 @@ in wich: 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[,]]], - is as it has always been since the first who.patch, the 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[,]]], is as it + has always been since the first who.patch, the 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 , 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 , 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 @@ -162,15 +159,15 @@ Note that: 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 @@ -183,63 +180,61 @@ Note that: 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. @@ -268,22 +263,26 @@ Miscellaneous bug fixes / "undocumented feature" changes: 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