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 ] .