POSIXly:
[ "$((hex_string_1))" -eq "$((hex_string_2))" ]
Com versões anteriores de dash
, você precisava:
[ "$(($hex_string_1))" -eq "$(($hex_string_2))" ]
POSIXly, Sobre:
[ "$hex_string_1" -eq "$hex_string_2" ]
A especificação POSIX para a [
aka test
utility diz que os operandos precisam ser inteiros, sem especificar quais formas de inteiros (decimal, octal, hexadecimal ...) devem ser suportadas, mas isso é realmente abordado no ponto 6 no Sintaxe do argumento do utilitário , que determina qual seria o padrão quando não especificado:
6. Unless otherwise specified, whenever an operand or option-argument is, or contains, a numeric value:
- The number is interpreted as a decimal integer.
- Numerals in the range 0 to 2147483647 are syntactically recognized as numeric values.
- When the utility description states that it accepts negative numbers as operands or option-arguments, numerals in the range -2147483647 to 2147483647 are syntactically recognized as numeric values.
- Ranges greater than those listed here are allowed.
Na prática, [ 0x10 -eq 16 ]
só funciona com posh
( [ 0x1 -eq 0x01
] funciona em AT & T ksh
(mas somente porque eles são tratados como 0
, [ 0x2 -eq 0x123 ]
retornaria verdadeiro também) e com exceção de posh
(onde está um bug ), todos [
implementações retornam false em [ 010 -eq 8 ]
(como em 010
é tratado como decimal, não octal)).
Em ksh93
, enquanto você não pode fazer [ 0x10 -eq 16 ]
, você pode fazer [ +0x10 -eq 16 ]
(também com posh
). Em ambas as derivadas AT & T ksh
e pdksh
(incluindo posh
), você também pode fazer [ '16#10' -eq 16 ]
.