Sind doppelte eckige Klammern [[ ]] gegenüber einfachen eckigen Klammern [ ] in der Bash vorzuziehen?

Question

Ein Kollege behauptete kürzlich bei einer Codeüberprüfung, dass die [[ ]] Konstrukt ist zu bevorzugen gegenüber [ ] in Konstrukten wie

if [ "`id -nu`" = "$someuser" ] ; then
     echo "I love you madly, $someuser"
fi

Er konnte es nicht begründen. Gibt es eine?

Answer 1

Bei einer Frage mit dem Stichwort "Bash", die ausdrücklich "in Bash" im Titel hat, bin ich ein wenig überrascht von all den Antworten, die besagen, dass Sie Folgendes vermeiden sollten [[ ... ]] weil es nur in der Bash funktioniert!

Es stimmt, dass die Portabilität der primäre Einwand ist: Wenn Sie ein Shell-Skript schreiben wollen, das in Bourne-kompatiblen Shells funktioniert, auch wenn es sich nicht um Bash handelt, sollten Sie [[ ... ]] . (Und wenn Sie Ihre Shell-Skripte in einer strengeren POSIX-Shell testen wollen, empfehle ich dash Obwohl es eine unvollständige POSIX-Implementierung ist, da ihm die vom Standard geforderte Unterstützung für die Internationalisierung fehlt, fehlt ihm auch die Unterstützung für die vielen Nicht-POSIX-Konstrukte, die in bash, ksh, zsh usw. zu finden sind).

Der andere Einwand, den ich sehe, ist zumindest innerhalb der Annahme der Bash anwendbar: dass [[ ... ]] hat seine eigenen speziellen Regeln, die Sie lernen müssen, während [ ... ] verhält sich wie ein weiterer Befehl. Auch das ist wahr (und Herr Santilli hat die Belege für die Unterschiede vorgelegt), aber es ist ziemlich subjektiv, ob die Unterschiede gut oder schlecht sind. Ich persönlich finde es befreiend, dass ich mit dem Konstrukt der doppelten Klammer ( ... ) für die Gruppierung, && y || für boolesche Logik, < y > zum Vergleich, und nicht zitierte Parametererweiterungen. Es ist wie eine eigene kleine, abgeschlossene Welt, in der Ausdrücke eher wie in traditionellen, nicht auf der Kommandozeile basierenden Programmiersprachen funktionieren.

Ein Punkt, den ich noch nicht angesprochen habe, ist, dass dieses Verhalten der [[ ... ]] ist völlig konsistent mit dem Konstrukt der arithmetischen Erweiterung $(( ... )) die ist von POSIX spezifiziert, und erlaubt auch nicht in Anführungszeichen gesetzte Klammern sowie boolesche und Ungleichheitsoperatoren (die hier numerische statt lexikalische Vergleiche durchführen). Im Wesentlichen erhalten Sie jedes Mal, wenn Sie die doppelten Klammerzeichen sehen, den gleichen Anführungszeichen-Schutz-Effekt.

(Die Bash und ihre modernen Verwandten verwenden auch (( ... )) - ohne den führenden $ - entweder als eine C-Stil for Schleifen-Header oder eine Umgebung für die Durchführung von arithmetischen Operationen; keine der beiden Syntaxen ist Teil von POSIX).

Es gibt also einige gute Gründe, die dafür sprechen [[ ... ]] Es gibt auch Gründe, sie zu vermeiden, die in Ihrem Umfeld zutreffen können, aber nicht müssen. Was Ihren Kollegen betrifft, so ist "unser Styleguide sagt das so" eine gültige Rechtfertigung, soweit es geht, aber ich würde auch die Hintergründe von jemandem erfragen, der versteht, warum der Styleguide empfiehlt, was er tut.

Answer 2

Eine typische Situation, in der Sie Folgendes nicht verwenden können [[ ist in einem autotools configure.ac Skript. Dort haben die Klammern eine besondere und andere Bedeutung, so dass Sie Folgendes verwenden müssen test 代わりに [ o [[ -- Beachten Sie, dass Test und [ sind das gleiche Programm.

Answer 3

[[ ]]-Doppelklammern werden unter bestimmten Versionen von SunOS und innerhalb von Funktionsdeklarationen völlig ununterstützt durch:

GNU Bash, Version 2.02.0(1)-Release (sparc-sun-solaris2.6)

Answer 4

Kurz gesagt, [[ ist besser, weil es keinen weiteren Prozess aufspaltet. Keine Klammern oder eine einzelne Klammer ist langsamer als eine doppelte Klammer, weil sie einen anderen Prozess forkt.