2016-06-23 56 views
5

wierzę obydwa z następujących fragmentów kodu jest ważny POSIX powłoki zgodnej:Czy powinienem używać "test" lub "[" "]" w powłoce POSIX?

Opcja 1:

if [ "$var" = "dude" ] 
then 
    echo "Dude, your var equals dude." 
fi 

Opcja 2:

if test "$var" = "dude" 
then 
    echo "Dude, your var equals dude." 
fi 

co jest korzystne formułowanie i czemu? Czy w pewnych sytuacjach jest jakiś powód do używania jednego z drugim?

+0

Tak, oba są prawidłowe. Nie, nie ma konkretnego powodu, aby preferować jeden nad drugim - jest to wybór stylistyczny. –

+0

'test' prawdopodobnie spowoduje rozwidlenie procesu, a tym samym będzie mniej wydajne. –

+3

@WillemVanOnsem, w powłoce, w której 'test' nie jest wbudowany, to będzie również używać zewnętrznego'/usr/bin/["szukaj tego, twój system operacyjny * nie * wysyła to jako zewnętrzny plik binarny (często twardy link do tego samego i-węzła, jak '/ usr/bin/test', który analizuje jego' argv [0] ', aby zobaczyć, jak został wywołany i zdecydować, czy odrzucić końcowe'] 'z jego argumentu lista). –

Odpowiedz

6

Nie ma żadnej różnicy funkcjonalnej, co czyni ten wybór czysto stylistycznym bez powszechnie akceptowanych wytycznych. The bash-hackers wiki ma rozszerzoną sekcję klasycznej (zgodnej z POSIX) test, z dużą dbałością o najlepsze praktyki i pułapki, i nie zajmuje stanowiska, które preferowałoby.

Ponadto the POSIX specification for test - podczas gdy robi znak sporo funkcjonalności przestarzałych - określa ani formy jako preferowany nad innymi.

To powiedziawszy, jedną z korzyści dla test jest to, że jest mniej sprzyjający dla ludzi, którzy wywołują oczekiwania z innych języków, co skutkuje uszkodzeniem lub błędnym kodem. Na przykład częstym błędem jest pisanie [$foo=1], a nie poprawnego [ "$foo" = 1 ], ale ludzie nie są powszechnie postrzegani jako piszący test$foo=1: Bardziej wizualnie oczywiste jest, że test "$foo" = 1 przestrzega tych samych reguł parsowania, co inne polecenia powłoki i dlatego wymaga tej samej opieki dotyczące cytowania i białych znaków.


[1] taki jak -a, -o, ( i ) i jakiegokolwiek zastosowania z więcej niż czterema argumentów (z wyjątkiem tylnego ] na wystąpienie rozpoczęto pod nazwą [).

+0

Powłoka POSIX nie uważa, że ​​'-a' lub' -o' jest przestarzałe. [** POSIX Podręcznik programisty (test) **] (http://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html#tag_20_128) Wierzę, że argumentem przeciwko ich użyciu jest * brak jasności * po Bash wprowadzono '-a' (* true, jeśli plik istnieje *). Ale test POSIX nie wspomina o '&&' lub '||'. –

+2

@ DavidC.Rankin, ... jeśli klikniesz na "[OB XSI]" gdziekolwiek podano w tej specyfikacji - do której podłączyłeś - otwiera się następująca, która wyjaśnia te kody (a stąd "OB" oznacza przestarzałe): http://pubs.opengroup.org/onlinepubs/9699919799/help/codes.html. Aby zacytować: "Opisana funkcjonalność może zostać usunięta w przyszłej wersji tego tomu POSIX.1-2008. Ściśle zgodne aplikacje POSIX i ściśle zgodne aplikacje XSI nie powinny używać funkcji przestarzałych." –

+0

@ DavidC.Rankin, ...i istnieją ku temu dobre powody: w przypadkach więcej niż czterech argumentów za pomocą "-a" i "-o" istnieją niejasności, w których może być konieczne użycie idiomu "x $ foo" w celu ujednoznacznienia interpretacji między wartościami i przetestuj składnię (szczególnie gdy ten zestaw wartości może zawierać '(' lub ')'). –