I consistently use the following regexp in my scripts to validate a nick entered with a command, for example !op <nick> to trigger a PUB bind that ops channel users.
bind PUB o !op procname
proc procname {nick uhost hand chan text} {
set target [string trim $text]
if {[regexp -- {^[\x41-\x7D][-\d\x41-\x7D]*$} $target]} {
# normal code here
} else {
# error code here
}
}
This seems to work fine on the network I frequent but I have never really considered whether it is generally true for a wide range of IRC networks and, as a consequence, my scripts would not function as expected in other circumstances.
Is the regexp generally true or are there common networks that have other rules regarding the characters allowed in a nick?
Fair point. Sorry, I seem to have elicited that response due to using an overly simplistic example, though for completeness it would still be reasonable to use both onchan and a nick checking regexp since they communicate to the command user the exact nature of an error.
Suppose I wanted to use a public command to send a network /WHOIS. In this case the target nick does not need to be in the command source channel. The target nick doesn't even need to be online since this would return a RAW 401 or 402 depending on the syntax of the /WHOIS command. In this case it might be useful to validate the target entered by the command user using the regexp.
Same question. Is it generally valid for common IRC networks?
rfc2812 wrote:nickname = ( letter / special ) *8( letter / digit / special / "-" )
...
letter = %x41-5A / %x61-7A ; A-Z / a-z
digit = %x30-39 ; 0-9
...
special = %x5B-60 / %x7B-7D
; "[", "]", "", "`", "_", "^", "{", "|", "}"
As such, your regular expression permits more characters than either rfcs. Mainly, you allow characters such as "; : ? @" in your expression, which are not allowed within a nickname.
Darn, you're right!
Must've overlooked that \d in there.. (and way too little coffee today)
As such, your regular expression should be in line with rfc2812 (although not rfc1459). Being rfc2812 the most common standard these days, I'd say it'll work well with most networks (might be worth adding note as to being rfc2812-compliant, if you're worried users will have issues on non-standard servers)