Back Ticks vs doppelte Anführungszeichen

Ich habe mich schon lange gefragt, aber nicht herausgefunden, wie ich es nachschlagen soll -

ist das:

x=`command -v r2g`

das gleiche wie das:

x="$(command -v r2g)"

oder ist es dasselbe wie folgt:

x=$(command -v r2g)

... wenn es das letztere ist, sollte ich das tun, um es zu beheben?

x="`command -v r2g`"

Alle Beispiele beziehen sich auf die Variablenzuweisung aus der Befehlssubstitution, daher sind sie äquivalent. Gemäß Gilles ' Antwort ist ein Zitieren auf der rechten Seite der Zuordnung zur Variablen nicht erforderlich, da dort keine Wortaufteilung stattfindet. Also sind alle vier in Ordnung.

Wenn sie eigenständig wären, dh nicht im Auftrag, dann müssten Sie zitieren. Das $(...)Formular hat im Vergleich zu Backticks den Vorteil, dass Anführungszeichen verschachtelt und in mehrere Zeilen unterteilt werden können, weshalb dieses Formular heutzutage im Allgemeinen bevorzugt wird. Mit anderen Worten, Sie können "$( echo "$var" )" mit diesem Formular sowohl die innere $varals auch die äußere Erweiterung von $(...)vor Wortteilung und Dateinamen-Globbing schützen .

Wie in den POSIX Shell Command Language- Spezifikationen gezeigt, funktionieren eingebettete mehrzeilige Skripte nicht mit Backticks (links), sondern mit $()Formularen (rechts).

echo `                         echo $(
cat <<\eof                     cat <<\eof
a here-doc with `              a here-doc with )
eof                            eof
`                              )


echo `                         echo $(
echo abc # a comment with `    echo abc # a comment with )
`                              )


echo `                         echo $(
echo '`'                       echo ')'
`                              )

Die vier Beispiele sind funktional äquivalent.

Backticks sind veraltet, und wenn Sie keine 1970-Shell wie eine Bourne-Shell (wie Heirloom) verwenden, benötigen Sie sie nicht. Das Hauptproblem ist, dass sie ziemlich schwer zu verschachteln sind. Versuchen Sie:

$ echo $(uname | $(echo cat))
Linux

$ echo `uname | `echo cat``
bash: command substitution: line 2: syntax error: unexpected end of file
echo cat

Auf der rechten Seite einer Befehlszeile mit nur einer Zuweisung ist es nicht erforderlich (aber harmlos), die Erweiterung zu zitieren, da die Erweiterung ohnehin als zitiert betrachtet wird:

$ var=$(uname)

Dies ist jedoch nicht immer der Fall. Eine Zuweisung für den Befehlsexport wird als Argument angesehen und in einigen Shells (nicht in Bash) aufgeteilt und globalisiert:

$ dash -c 'export MYVAR=`echo a test`;echo "$MYVAR"'
a

Die gleichen Überlegungen gelten für local( Werden Anführungszeichen für die Zuweisung lokaler Variablen benötigt? ) Und declare(und einige andere).

Was Sie tun sollten, um "es zu beheben", ist:

x=$(command -v r2g)

Und manchmal (für tragbare Skripte):

export x="$(command -v r2g)"

Ja, die Backticks sollten auch zitiert werden.

Dies kann eine Frage des bevorzugten Bash-Stils sein, wenn die Befehlsausgabe keine Leerzeichen enthält. Hier ist ein Zitat des Autors des shellhardenDienstprogramms aus " Wie man Dinge sicher in Bash macht ":

Should I use backticks?
Command substitutions also come in this form:

Correct: "`cmd`"
Bad: `cmd`
While it is possible to use this style correctly, it looks even more awkward in quotes and is less readable when nested. The consensus around this one is pretty clear: Avoid.

Shellharden rewrites these into the dollar-parenthesis form.

Ich glaube auch, dass es eine gute Form ist, Backticks entweder zu zitieren "oder (besser) neu zu schreiben, um sie zu verwenden $(). Wenn die Befehlsausgabe bei Verwendung von Backticks Leerzeichen oder spezielle Zeichen enthält, kann dies problematisch sein, wenn der Ausdruck nicht in Anführungszeichen gesetzt wird.

Ja, meine Vermutung sieht laut diesem Dokument richtig aus: https://github.com/anordal/shellharden/blob/master/how_to_do_things_safely_in_bash.md

Es sagt:

# Should I use backticks?
# Command substitutions also come in this form:

Correct: "`cmd`"
Bad: `cmd`