View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002434 | unreal | ircd | public | 2005-03-20 17:42 | 2007-04-27 06:07 |
| Reporter | Int21h | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | wont fix | ||
| Summary | 0002434: An idea for /WHOIS command | ||||
| Description | I think it would be good if an user could specify a pattern using the whois command, I mean: /whois *a -> would make a whois to all "a" ending users /whois *badword* /whois *c*h*a*n*s*e*r*v* I think it could ve useful in some cases :P | ||||
| 3rd party modules | |||||
|
|
This can be done already with /who. /who -n *a /who -n *badword* /who -n *c*h*a*n*s*e*r*v* You can even make a script that makes it output the infoemation in a whois-like format: Nick: Stealth ([email protected]) Real Name: - Server: irc.moocows.dk (0) Flags: Not away, Registered, IRCop (Hr*) |
|
|
When I do: /who -n *a, I get a who of all users on the net, although they don't match the expr.; the same with the other two WHOs. But that was not what I was thinking. An user can set the +i umode and the command wouldn't have the function that I mean. For example an user connects to some net and he/she wants to find someone with an subexpr. in his/her nick, because the expr. matches a hobby or whatever... typing /whois *expr* would make a whois to everyone and would have info about him/her, and then maybe could make him/her a query, etc. etc. With a /who there maybe wouldn't be all the users matching it. |
|
|
Oops, those should be +n /who +n *a /who +n *badword* /who +n *c*h*a*n*s*e*r*v* -> An user can set the +i umode and the command wouldn't have the function that I mean. If implimented, +i would affect it the same way as it affects /who. If you have any reason to /whois a wildcard mask, you would be an oper. If you were a regular user, there would be no use except to find someone that has changed their nick so they wouldn't be bugged, or to /whois a broad mask and spam the channels returned. There simply is no reason for this. |
|
|
In my opinion if someone would use that for spamming or some other bad thing, he/she would use /list command before a /whois *, for example. I really don't think someone would use this for some malicious action; there are a lot of "better" ways of doing this, and although it happened, there are a lot of possible solutions: bans, kills or maybe glines. Just another thing: "If implimented, +i would affect it the same way as it affects /who." I see no reason for that; when you whois an user, you get info about that user, although he has +i mode or not. Well, that's only my opinion, maybe some people will find this useful and some other won't. |
|
|
-> I see no reason for that; when you whois an user, you get info about that user, although he has +i mode or not. If wildcards are implimented into /whois, +i will be pointless anyway! +i is there to keep users from being found in /who searches. How would +i work if you cant be seen in /who *, but you CAN in /whois *?! (Correct me if I am wrong, but *DUH*) |
|
|
You'll probably know much more than me about the implementation of the commands, I'm talking from an user perspective, so assume I know "nothing" :) I thought /who and /whois commands worked independently, I mean one had something to do with +i mode (/who), and the other hadn't. Well, if you're right it would really be the same effect than a /who and would be uselless... :S so, dunno... it's only an idea... :P |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2005-03-20 17:42 | Int21h | New Issue | |
| 2005-03-20 18:15 | Stealth | Note Added: 0009633 | |
| 2005-03-20 19:26 | Int21h | Note Added: 0009634 | |
| 2005-03-20 19:45 | Stealth | Note Added: 0009635 | |
| 2005-03-20 20:34 | Int21h | Note Added: 0009636 | |
| 2005-03-20 20:42 | Stealth | Note Added: 0009637 | |
| 2005-03-20 21:16 | Int21h | Note Added: 0009638 | |
| 2007-04-27 06:07 |
|
Status | new => closed |
| 2007-04-27 06:07 |
|
Resolution | open => wont fix |
