Forums Bug Reports Not a Bug per se

As title says, not really a bug, but an anomaly.

//if !$2 { echo -a $ifmatch }
$true
//if !$1 { echo -a $ifmatch }
$true
//tokenize 32 a | if !$2 { echo -a $ifmatch }
$true
//tokenize 32 | if !$1 { echo -a $ifmatch }
$true

//tokenize 32 | if !$0 { echo -s $ifmatch }
1
//tokenize 32 0 | if !$1 { echo -a $ifmatch }
1

Why are these returning 1 and not $true?

This is probably happening because !<something> is internally translated to the 'opposite' value. The opposite of 0 is 1. So !$1 and !$0 are considered 1, if $1 and $0 are 0. The opposite of $false is also $true, so !$false = $true. $true is also the opposite of $null, which not as obvious at first, but I can't see any better candidate for this.

Is the opposite of N (N being >1) also 0? I can't see how this works when !$0 would be 0 if $0 was 2, 3 etc..

This is so math operators don't break, I'm guessing. You can't > < >= <= $true against other numbers. Though this would be kinda sloppy to code, I suppose ( 1 > !2 ).

The only bug is that ( !0 == $true ) and not ( !0 > 0 ).

- Raccoon

I did say I didn't consider it a bug.. (twice)
IMHO it should return $true if only for consistency.

There is no way to tell what !$0 returns when $0 > 0. That's because $ifmatch is filled only by the last matching statement. You'd need something like $elsematch to test it.

I know that, I'm only guessing. By this logic, it shouldn't return $null nor $false in that case, for example..

I know you said it wasn't a bug, per se.
*I* am. :tongue: heh.

Actually, I wish to change my last statement.
The only bug is that ( !0 == $true ) and not ( !0 > 0 ).

//if ( !0 ) echo -a $ifmatch == !0
//var %n = 0 | if ( !%n ) echo -a $ifmatch == 1

I would say both of these are desired results, and should simply be anticipated when scripting. Any non-zero number is as good as $true... perhaps Khaled should just make IF ( 1 == $true ) && ( 0 == $false ) succeed.

- Raccoon