Czy jest jakaś istotna różnica przy porównywaniu zmiennej jako łańcucha lub jako wartości int

Z ciekawości, porównując zmienną bash (jej wartość jest an integer), można przetestować ją na pewnej predefiniowanej wartości zadeklarowanej jako intlub string.

Przykładowy skrypt :

#!/bin/bash
f1()
{
        [ "$1" == "1" ] && echo "$FUNCNAME: \"1\" compared as string"
}

f2()
{
        [[ "$1" -eq 1 ]] && echo "$FUNCNAME: \"1\" compared as int"
}

f1 $1
f2 $1

Wyjście :

$  ./param.sh 1
f1: "1" compared as string
f2: "1" compared as int

i

$  ./param.sh blah
$

Obie funkcje zachowują się w ten sam sposób, więc zastanawiam się, czy istnieje preferowany sposób sprawdzania zmiennej całkowitej? Wybrałbym sprawdzanie intkontra intbardziej rygorystyczne, ale zastanawiam się, czy robią to jakieś wady string?

W tym przypadku f2()jest również bardziej rygorystyczny w porównaniu, tzn. Przekazanie wartości dziesiętnej spowoduje jej uszkodzenie f1(), ale nie spowoduje problemu.

Tak, wiele różnic. Na przykład =sprawdza dokładność równości łańcucha, ale -eqocenia arytmetycznie oba wyrażenia przed sprawdzeniem równości:

$ [ " 1 " -eq 1 ] && echo equal || echo not
equal
$ [ " 1 " = 1 ] && echo equal || echo not
not

$ [ +1 -eq 1 ] && echo equal || echo not
equal
$ [ +1 = 1 ] && echo equal || echo not
not

$ [ "0+1" -eq 1 ] && echo equal || echo not
equal
$ [ "0+1" = 1 ] && echo equal || echo not
not

Ponadto pusty ciąg znaków jest liczbowo równy zero:

$ [ "" -eq 0 ] && echo equal || echo not
equal
$ [ "" = 0 ] && echo equal || echo not
not

Zupełnie inna klasa różnic pojawia się, gdy weźmiesz operatory porównania - biorąc pod uwagę <vs -lt, na przykład:

$ [[ 2 -lt 10 ]] && echo less || echo not
less
$ [[ 2 < 10 ]] && echo less || echo not
not

Wynika to z faktu, że ciąg „2” jest alfabetycznie po ciągu „10” (ponieważ 1 występuje przed 2), ale liczba „2” jest liczbowo mniejsza niż liczba „10”.

Porównanie liczb całkowitych i ciągów staje się najbardziej znaczące, gdy porównujesz większe lub mniejsze niż:

#!/bin/bash

eleven=11
nine=9

[[ $nine < $eleven ]] && echo string   # fail

[[ "$nine" -lt "$eleven" ]] && echo integer # pass

Pierwszy nie powiedzie się, ponieważ 9 pojawia się po 11, gdy jest posortowane leksykograficznie.

Zauważ, że użycie cudzysłowów nie określa, czy porównujesz ciągi, czy liczby, operator tak. Możesz dodać lub usunąć powyższe cytaty, nie robi to żadnej różnicy. Bash przechwytuje niezdefiniowane zmienne w podwójnych nawiasach, więc cudzysłowy nie są konieczne. Używanie cudzysłowów z pojedynczymi nawiasami do testów numerycznych nie uratuje cię, ponieważ:

[ "" -lt 11 ]

i tak jest błędem („wymagane wyrażenie całkowite”). Cytaty są skutecznym zabezpieczeniem przy porównywaniu ciągów w nawiasach pojedynczych:

[ "" \< 11 ]

Uwaga w podwójnych nawiasach, ale nie ""będzie .-eq 0== 0

Oprócz tego, co zostało powiedziane.
Porównywanie pod kątem równości jest szybsze z liczbami, chociaż w skryptach powłoki rzadko zdarza się potrzeba szybkich obliczeń.

$ b=234
$ time for ((a=1;a<1000000;a++)); do [[ $b = "234" ]]; done

real    0m13.008s
user    0m12.677s
sys 0m0.312s

$ time for ((a=1;a<1000000;a++)); do [[ $b -eq 234 ]]; done

real    0m10.266s
user    0m9.657s
sys 0m0.572s