checking if a number is double digit or not

hi there, i am making a script to send my logs to people who request them....and i need to know how to check if someone doesnt enter a double digit into the PM. like here is my trigger:

!daylog m 1

!daylog tells me its for the logs, m tells what channel its for, and the 1 is the day of the month they want, and THAT is the number i need double digitized. cause it wont work with single digits and i need it to send a message to the nick who requested it that they need to use double digits.

make any sense?

$len to check $len() == 2, or pad it..

$str(0, $calc(2 - $len($$3))) $+ $$3

$base(%n,10,10,2) will zero-pad %n for you.
$iif($len(%n) == 2,%n,0 $+ %n) will work too.
$right(00 $+ %n,2) is also an option.

- Raccoon

What if they enter a number more than 2 digits? Only $right($+(00,%n),2) covers that eventuality. The first two don't handle that. Indeed, the second one will ADD a 0 to a number that's 3 digits or more already! None of them handle negative numbers correctly.

Code:


  if $regex(%n, /^[-]{0}([0-9]{2})$/) == 0 $&amp;
    msg $nick You must use 02 digits for this function to work correctly.
  else $&amp;
    /do.whatever
 
  ;  or, even simpler (but several more steps, therefore slower):
 
  if $len(%n) != 2 || %n !isnum 0-99 $&amp;
    msg $nick You must use 02 digits for this function to work correctly.
  else $&amp;
    /do.whatever

Not to get of topic, but i was looking at your code and just realised mirc doesn't allow a new line for if's without { } 's.. Wonder why. That would be so handy if it were allowed. Alteast it would save you three characters (including space bar) >:F

Code:


alias is2digit {
  if $regex($1, /^[-]{0}([0-9]{2})$/) == 0 $&amp;
    echo -a * $1 is either negative or not 02 digits
  else $&amp;
    echo -a * $1 is both positive and 02 digits
}

Here is the response I got in my Status Window using /is2digit N:

Code:


* 1 is either negative or not 02 digits
* 100 is either negative or not 02 digits
* 01 is both positive and 02 digits
* -01 is either negative or not 02 digits
* -1 is either negative or not 02 digits
* 0 is either negative or not 02 digits
* 00 is both positive and 02 digits
* 95 is both positive and 02 digits

Seems to work just fine on my mIRC.

Heh, touche.

While I do appreciate solid bounds checking as much as the next guy... I looked at his problem and sought a simple solution that best suited it.

Taking into consideration that this is user input, it would probably be best to handle it a little more securely in order to prevent someone from entering strings that might grant them access to other files or directories. So in practice, I would probably go with a regular expression myself to confirm the input is valid. But in building that number, I'd probably still use one of the 3 methods I posted.

... On third thought, I'd probably use this instead.

var %n = $$1
if ( %n isnum 1-9 ) %n = 0 $+ %n
elseif ( %n !isnum 10-12 ) return
dcc send $nick %n $+ .log

- Raccoon
The possibilities are infinite.

Just out of curiosity... why are you using [-]{0} ? This matches "-" zero times, ie an empty string, so I don't see its purpose. On a sidenote, [0-9]{2} doesn't need to be enclosed in brackets, but even if it did, it is more "politically correct" to enclose it in non-capturing brackets (ie (?:<subpattern>)), since you don't need to capture it (you don't use $regml() anywhere). According to the PCRE manual, capturing brackets are slower than non-capturing ones (and it seems that the speed gain from non-capturing brackets is slightly bigger than the speed loss from mirc parsing two more characters, ie the "?:"). All in all, I'd use $regex($1,/^\d\d$/)

Simple. I'm no $regex guru, by anyone's estimation, least of all my own. I was trying to ensure that it didn't match a - (making the number negative), when, as you pointed out, I didn't need to at all. I didn't think of using the \d's because I can never remember the letters so I resorted to my limited knowledge to make something workable. As for the capturing parentheses, that was merely an oversight on my part ... I'm too used to trying to capture a valid match so I just included them like I normally would. Your final solution is much more elegant than mine; I'd go with that version.