This is more a sysadmin question, but is IPMI useful for a single individual managing a single computer? I've never used it. Opinions?

@Kusalananda any idea why bash considers an empty string to be numerically equal to 0?

$ var="" && [[ "$var" -eq 0 ]] && echo yes
yes

@terdon not Kusalananda, but "A null value evaluates to 0"

and next time, If you have a question, see unix.stackexchange.com/questions/ask ;)

@JeffSchaller heh, fair. I was going to, but I was discussing this witj @Kusalananda in a comment thread.

carry on! I was just kind of surprised that we didn't have a question worded like that already

@JeffSchaller is that it though? The empty string is treated as arithmetically equal to 0 even when not in a variable

$ [[ "" -eq 0 ]] && echo true
true

@terdon seems like it to me. either "" or "$var" both eval to 0 because they're both null

Yeah, and the reference you gave nicely explains the "$var" example, but not the "" one

Sounds like I should indeed post a Q

... The value of a variable is evaluated as an arithmetic expression when it is referenced ...

Sorry guys, I missed the conversitain here.

maybe it takes a little bit mind-reading on the part of the user here, but I see: empty variable --> referenced --> 0

Zero is what anything that is'nt a number is converted to when you use it in an arithmetic contecxt.

Spelling does nat happen today, it seems.

If the variable's value was that flakey (basically random), I would probably use a string comparison rather than an arithmetic comparison though, as the arithmetic comparison would error out if the string was something like "12abc".

@Kusalananda yes, apparently, but why and where is that documented? @JeffSchaller found a good reference (the bash manual) that explains why a variable that evaluates to an empty string is treated as 0, or at least a reference mentioning that it happens, if not why.

I really only do arithmetic comparisons on variables that have values that I control.

But I haven't found a reference for why the empty string itself, with no variable involved, also is evaluated as 0

$ [[ "" -eq 0 ]] && echo true
true

$ [[ "" -lt 10 ]] && echo true
true
$ [[ "" -gt -10 ]] && echo true
true

The POSIX test does not like empty strings in arithmetic comparisons. So it must be a bash thing.

Ah is it being treated as a NUL? So it is then comparing the ASCII value which is indeed 0?

Bash does not do NULs

Hence treated as. Maybe?

Argh! Sorry, @JeffSchaller I was looking at the wrong quote! I was reading this:

> A shell variable that is null or unset evaluates to 0 when referenced by name without using the parameter expansion syntax.

But you were referring to this, a couple of sentences down:

> A null value evaluates to 0.

That covers me nicely.

Oh, I just realized what my expamle actually does (var="hello" && [[ "$var" -eq 0 ]]). It compares the value of the variable hello with zero.

@Kusalananda You mean it compares the value of the string hello, right?

It isn't dereferencing and looking for a variable named hello, is it?

It does. If you have a variable called hello with the value 1, the test fails because it's not zero.

Whaaaa?! It is dereferencing!

terdon@oregano ~ $ var="hello" && [[ "$var" -eq 0 ]] && echo y
y
terdon@oregano ~ $ var="hello" && hello=1 && [[ "$var" -eq 0 ]] && echo y
terdon@oregano ~ $ var="hello" && hello=100 && [[ "$var" -gt 10 ]] && echo y
y

That... is surprising.

:64475568... aand a reason to switch to doing string comparisons for simple equality comparisons, possibly. At least if you don't have control over the data.