some_search | eval this_is_a_bool="TRUE" | eval is_it_a_bool=if(isbool(this_is_a_bool),"yes","no")
Ultimately I am trying to do this
some_search | eval flag="TRUE" | eval is_flag=if(flag,"flag is on","flag is off")
I have tried
$TRUE and I scoured the documentation.
What value should I give to
this_is_a_bool to be able to evaluate it as a boolean?
You're doing two different things in your examples. The first is testing a field's type while the second is testing a field's value.
The docs conflict in little in what value a boolean field contains with TRUE being most common and "True" the output of
That said, it really doesn't matter what the value is as long as you use the appropriate methods.
isbool() to find out if a field is a boolean; and
if (field = someExpectedValue, whatIfItIs, whatIfItIsnt) to test if a condition is true or not.
I don't think you can have a field containing a boolean value.
| stats count | eval bool = isnotnull(1) Error in 'eval' command: Fields cannot be assigned a boolean result. Instead, try if([bool expr], [expr], [expr]).
So this almost forces the developer to use magic values as a proxy for a true boolean in the case where a boolean value needs to be manually defined, or when it is a field in an event. It would be nice if there was a "global magic string" that would evaluate to a boolean... maybe Splunk devs have this in the works? :fingers crossed:
Right. But I would expect that if
isbool(someBooleanField) evaluated to true, then I could pass
someBooleanField directly to
if() without having to evaluate it a la
eval is_flag=if(flag,"flag is on","flag is off")
Is this not possible?
The reason for doing it this way is to be able to use
isbool() as a native validation check rather than have magic strings and custom validation function.
isbool(someBooleanField) is true then it's valid to say
if(someBooleanField, "On", "Off").
As I intended to say in my answer, one should not be counting on magic strings or values to determine if something is boolean or if that boolean is true or not. Use the proper constructs and the underlying values don't matter.
I see what you are saying. I was interested in the underlying value to be able to set a field as that value, but it seems this is not exposed.
I guess you can only interface with booleans as the result of a function and while passing that to another function, but not store them in fields or variables. martin_mueller has illustrated this pretty succinctly.
Does this seem accurate?