eval Befehl in Bash und seine typischen Verwendungen

Nach dem Lesen der Bash-Manpages und in Bezug auf diesen Beitrag .

Ich habe immer noch Probleme zu verstehen, was genau der evalBefehl tut und welche typischen Verwendungen dies sind. Zum Beispiel, wenn wir Folgendes tun:

bash$ set -- one two three  # sets $1 $2 $3
bash$ echo $1
one
bash$ n=1
bash$ echo ${$n}       ## First attempt to echo $1 using brackets fails
bash: ${$n}: bad substitution
bash$ echo $($n)       ## Second attempt to echo $1 using parentheses fails
bash: 1: command not found
bash$ eval echo \${$n} ## Third attempt to echo $1 using 'eval' succeeds
one

Was genau passiert hier und wie hängen das Dollarzeichen und der Backslash mit dem Problem zusammen?

evalNimmt eine Zeichenfolge als Argument und wertet sie aus, als hätten Sie diese Zeichenfolge in einer Befehlszeile eingegeben. (Wenn Sie mehrere Argumente übergeben, werden diese zuerst mit Leerzeichen zwischen ihnen verbunden.)

${$n}ist ein Syntaxfehler in bash. Innerhalb der geschweiften Klammern können Sie nur einen Variablennamen mit einigen möglichen Präfixen und Suffixen haben, aber Sie können keine willkürliche Bash-Syntax haben und insbesondere können Sie keine Variablenerweiterung verwenden. Es gibt jedoch eine Möglichkeit zu sagen: "Der Wert der Variablen, deren Name in dieser Variablen enthalten ist:"

echo ${!n}
one

$(…)führt den in den Klammern angegebenen Befehl in einer Subshell aus (dh in einem separaten Prozess, der alle Einstellungen wie Variablenwerte von der aktuellen Shell erbt) und sammelt seine Ausgabe. So echo $($n)läuft $nals Shell - Befehl und zeigt seinen Ausgang. Da wird $nausgewertet 1, $($n)versucht, den Befehl auszuführen 1, der nicht existiert.

eval echo \${$n}führt die an übergebenen Parameter aus eval. Nach der Erweiterung sind die Parameter echound ${1}. Also eval echo \${$n}läuft der Befehl echo ${1}.

Beachten Sie, dass Sie die meiste Zeit doppelte Anführungszeichen für Variablensubstitutionen und Befehlssubstitutionen verwenden müssen (dh immer dann, wenn es eine gibt $) : "$foo", "$(foo)". Setzen Sie Variablen- und Befehlsersetzungen immer in doppelte Anführungszeichen , es sei denn, Sie wissen, dass Sie sie weglassen müssen. Ohne doppelte Anführungszeichen führt die Shell eine Feldaufteilung durch (dh sie teilt den Wert der Variablen oder die Ausgabe des Befehls in separate Wörter auf) und behandelt dann jedes Wort als Platzhaltermuster. Beispielsweise:

$ ls
file1 file2 otherfile
$ set -- 'f* *'
$ echo "$1"
f* *
$ echo $1
file1 file2 file1 file2 otherfile
$ n=1
$ eval echo \${$n}
file1 file2 file1 file2 otherfile
$eval echo \"\${$n}\"
f* *
$ echo "${!n}"
f* *

evalwird nicht sehr oft verwendet. In einigen Shells wird am häufigsten der Wert einer Variablen ermittelt, deren Name erst zur Laufzeit bekannt ist. In Bash ist dies dank der nicht notwendig${!VAR} Syntax . evalist immer noch nützlich, wenn Sie einen längeren Befehl erstellen müssen, der Operatoren, reservierte Wörter usw. enthält.

Stellen Sie sich eval einfach als "Bewertung Ihres Ausdrucks ein weiteres Mal vor der Ausführung" vor.

eval echo \${$n}wird echo $1nach der ersten Bewertungsrunde. Drei Änderungen zu beachten:

• Das \$wurde $(Der Backslash wird benötigt, andernfalls versucht es auszuwerten ${$n}, was bedeutet, dass eine Variable namens benannt ist {$n}, was nicht erlaubt ist)
• $n wurde ausgewertet 1
• Die evalverschwanden

In der zweiten Runde kann es grundsätzlich echo $1direkt ausgeführt werden.

Also eval <some command>wird zuerst ausgewertet <some command>(mit hier meine ich Ersatzvariablen meinen, maskierte Zeichen durch die richtigen ersetzen usw.) und dann den resultierenden Ausdruck erneut ausführen.

evalwird verwendet, wenn Sie dynamisch Variablen erstellen oder Ausgaben von Programmen lesen möchten, die speziell für das Lesen auf diese Weise entwickelt wurden. Beispiele finden Sie unter http://mywiki.wooledge.org/BashFAQ/048 . Der Link enthält auch einige typische evalVerwendungsmöglichkeiten und die damit verbundenen Risiken.

Nach meiner Erfahrung besteht eine "typische" Verwendung von eval darin, Befehle auszuführen, die Shell-Befehle zum Festlegen von Umgebungsvariablen generieren.

Vielleicht haben Sie ein System, das eine Sammlung von Umgebungsvariablen verwendet, und Sie haben ein Skript oder Programm, das festlegt, welche festgelegt werden sollen und welche Werte sie haben. Wenn Sie ein Skript oder Programm ausführen, wird es in einem gegabelten Prozess ausgeführt, sodass alles, was es direkt mit Umgebungsvariablen tut, beim Beenden verloren geht. Dieses Skript oder Programm kann jedoch die Exportbefehle an stdout senden.

Ohne eval müssten Sie stdout in eine temporäre Datei umleiten, die temporäre Datei als Quelle bereitstellen und dann löschen. Mit eval können Sie einfach:

eval "$(script-or-program)"

Beachten Sie, dass die Anführungszeichen wichtig sind. Nehmen Sie dieses (erfundene) Beispiel:

# activate.sh
echo 'I got activated!'

# test.py
print("export foo=bar/baz/womp")
print(". activate.sh")

$ eval $(python test.py)
bash: export: `.': not a valid identifier
bash: export: `activate.sh': not a valid identifier
$ eval "$(python test.py)"
I got activated!

Die eval-Anweisung weist die Shell an, die Argumente von eval als Befehl zu verwenden und sie über die Befehlszeile auszuführen. Es ist nützlich in einer Situation wie der folgenden:

Wenn Sie in Ihrem Skript einen Befehl in eine Variable definieren und später diesen Befehl verwenden möchten, sollten Sie eval verwenden:

/home/user1 > a="ls | more"
/home/user1 > $a
bash: command not found: ls | more
/home/user1 > # Above command didn't work as ls tried to list file with name pipe (|) and more. But these files are not there
/home/user1 > eval $a
file.txt
mailids
remote_cmd.sh
sample.txt
tmp
/home/user1 >

_{Update: Einige Leute sagen, man sollte niemals eval verwenden. Ich bin nicht einverstanden. Ich denke, das Risiko entsteht, wenn korrupte Eingaben an weitergegeben werden können eval. Es gibt jedoch viele häufige Situationen, in denen dies kein Risiko darstellt, und daher lohnt es sich zu wissen, wie man eval auf jeden Fall verwendet. Diese Stackoverflow-Antwort erklärt die Risiken der Bewertung und Alternativen zur Bewertung. Letztendlich ist es Sache des Benutzers, zu bestimmen, ob / wann die Bewertung sicher und effizient ist.}

Mit der Bash- evalAnweisung können Sie Codezeilen ausführen, die von Ihrem Bash-Skript berechnet oder erfasst wurden.

Das vielleicht einfachste Beispiel wäre ein Bash-Programm, das ein anderes Bash-Skript als Textdatei öffnet, jede Textzeile liest und verwendet eval, um sie der Reihe nach auszuführen. Dies ist im Wesentlichen das gleiche Verhalten wie bei der Bash- sourceAnweisung, die verwendet wird, es sei denn, es ist erforderlich, eine Art Transformation (z. B. Filtern oder Ersetzen) für den Inhalt des importierten Skripts durchzuführen.

Ich habe es selten gebraucht eval, aber ich fand es nützlich, Variablen zu lesen oder zu schreiben, deren Namen in Zeichenfolgen enthalten waren, die anderen Variablen zugewiesen wurden. Zum Beispiel, um Aktionen für Variablensätze auszuführen, während der Code-Footprint klein gehalten und Redundanz vermieden wird.

evalist konzeptionell einfach. Die strenge Syntax der Bash-Sprache und die Parsing-Reihenfolge des Bash-Interpreters können jedoch nuanciert werden und evalkryptisch und schwer zu verwenden oder zu verstehen erscheinen. Hier sind die wesentlichen Punkte:

1. Das übergebene Argument evalist ein Zeichenfolgenausdruck , der zur Laufzeit berechnet wird. evalführt das endgültige analysierte Ergebnis seines Arguments als tatsächliche Codezeile in Ihrem Skript aus.

2. Syntax und Analysereihenfolge sind streng. Wenn das Ergebnis keine ausführbare Zeile mit Bash-Code ist, stürzt das Programm im Rahmen Ihres Skripts bei der evalAnweisung ab, wenn es versucht, Müll auszuführen.

3. Beim Testen können Sie die evalAnweisung durch ersetzen echound sehen, was angezeigt wird. Wenn es sich im aktuellen Kontext um legitimen Code handelt, evalfunktioniert das Durchlaufen .

Die folgenden Beispiele können helfen, die Funktionsweise von eval zu verdeutlichen ...

Beispiel 1:

eval Anweisung vor 'normalem' Code ist ein NOP

$ eval a=b
$ eval echo $a
b

Im obigen Beispiel haben die ersten evalAussagen keinen Zweck und können beseitigt werden. evalist in der ersten Zeile sinnlos, da der Code keinen dynamischen Aspekt aufweist, dh er wurde bereits in die letzten Zeilen des Bash-Codes analysiert, sodass er mit einer normalen Code-Anweisung im Bash-Skript identisch wäre. Der zweite evalist ebenfalls sinnlos, da es zwar einen Parsing-Schritt gibt, der $ain sein Literal-String-Äquivalent konvertiert , aber keine Indirektion (z. B. keine Referenzierung über den String-Wert eines tatsächlichen Bash-Substantivs oder einer Bash-gehaltenen Skriptvariablen) erfolgt, sodass er sich identisch verhält als Codezeile ohne evalPräfix.

Beispiel 2:

Führen Sie die Variablenzuweisung mit Variablennamen durch, die als Zeichenfolgenwerte übergeben werden.

$ key="mykey"
$ val="myval"
$ eval $key=$val
$ echo $mykey
myval

Wenn Sie echo $key=$valwären, wäre die Ausgabe:

mykey=myval

Das , das endgültige Ergebnis der String - Parsing ist, ist das, was von eval ausgeführt werden, damit das Ergebnis der Echo - Anweisung am Ende ...

Beispiel 3:

Hinzufügen von mehr Indirektion zu Beispiel 2

$ keyA="keyB"
$ valA="valB"
$ keyB="that"
$ valB="amazing"
$ eval eval \$$keyA=\$$valA
$ echo $that
amazing

Das Obige ist etwas komplizierter als das vorherige Beispiel und stützt sich stärker auf die Parsing-Reihenfolge und die Besonderheiten von Bash. Die evalZeile wird intern grob in der folgenden Reihenfolge analysiert (beachten Sie, dass die folgenden Anweisungen Pseudocode und kein echter Code sind, nur um zu zeigen, wie die Anweisung intern in Schritte unterteilt wird, um zum Endergebnis zu gelangen) .

 eval eval \$$keyA=\$$valA  # substitution of $keyA and $valA by interpreter
 eval eval \$keyB=\$valB    # convert '$' + name-strings to real vars by eval
 eval $keyB=$valB           # substitution of $keyB and $valB by interpreter
 eval that=amazing          # execute string literal 'that=amazing' by eval

Wenn die angenommene Analysereihenfolge nicht erklärt, was eval genug tut, beschreibt das dritte Beispiel das Parsen möglicherweise detaillierter, um zu klären, was vor sich geht.

Beispiel 4:

Ermitteln Sie, ob Vars, deren Namen in Zeichenfolgen enthalten sind, selbst Zeichenfolgenwerte enthalten.

a="User-provided"
b="Another user-provided optional value"
c=""

myvarname_a="a"
myvarname_b="b"
myvarname_c="c"

for varname in "myvarname_a" "myvarname_b" "myvarname_c"; do
    eval varval=\$$varname
    if [ -z "$varval" ]; then
        read -p "$varname? " $varname
    fi
done

In der ersten Iteration:

varname="myvarname_a"

Bash analysiert das Argument evalund evalsieht dies zur Laufzeit buchstäblich:

eval varval=\$$myvarname_a

Der folgende Pseudocode versucht zu veranschaulichen, wie bash die obige Zeile des realen Codes interpretiert , um zu dem endgültigen Wert zu gelangen, der von ausgeführt wird eval. (Die folgenden Zeilen beschreiben den nicht genauen Bash-Code):

1. eval varval="\$" + "$varname"      # This substitution resolved in eval statement
2. .................. "$myvarname_a"  # $myvarname_a previously resolved by for-loop
3. .................. "a"             # ... to this value
4. eval "varval=$a"                   # This requires one more parsing step
5. eval varval="User-provided"        # Final result of parsing (eval executes this)

Sobald das gesamte Parsen abgeschlossen ist, wird das Ergebnis ausgeführt, und seine Wirkung ist offensichtlich. Dies zeigt, dass an sich nichts besonders Geheimnisvolles evalist und die Komplexität im Parsen des Arguments liegt.

varval="User-provided"

Der verbleibende Code im obigen Beispiel testet einfach, ob der $ varval zugewiesene Wert null ist, und fordert den Benutzer in diesem Fall auf, einen Wert anzugeben.

Ich habe ursprünglich absichtlich nie gelernt, wie man Eval benutzt, weil die meisten Leute empfehlen werden, sich wie die Pest davon fernzuhalten. Allerdings habe ich kürzlich einen Anwendungsfall entdeckt, der mich dazu brachte, ihn nicht früher zu erkennen.

Wenn Sie Cron-Jobs haben, die Sie interaktiv zum Testen ausführen möchten, können Sie den Inhalt der Datei mit cat anzeigen und den Cron-Job kopieren und einfügen, um ihn auszuführen. Leider geht es darum, die Maus zu berühren, was in meinem Buch eine Sünde ist.

Nehmen wir an, Sie haben einen Cron-Job unter /etc/cron.d/repeatme mit dem Inhalt:

*/10 * * * * root program arg1 arg2

Sie können dies nicht als Skript mit dem gesamten Junk davor ausführen, aber wir können cut verwenden, um den gesamten Junk zu entfernen, ihn in eine Subshell zu wickeln und den String mit eval auszuführen

eval $( cut -d ' ' -f 6- /etc/cron.d/repeatme)

Der Befehl cut druckt nur das 6. Feld der Datei aus, das durch Leerzeichen begrenzt ist. Eval führt diesen Befehl dann aus.

Ich habe hier einen Cron-Job als Beispiel verwendet, aber das Konzept besteht darin, Text aus stdout zu formatieren und diesen Text dann auszuwerten.

Die Verwendung von eval ist in diesem Fall nicht unsicher, da wir genau wissen, was wir vorab bewerten werden.

Ich musste kürzlich evalerzwingen, dass mehrere Klammererweiterungen in der von mir benötigten Reihenfolge ausgewertet werden. Bash führt also mehrere Klammererweiterungen von links nach rechts durch

xargs -I_ cat _/{11..15}/{8..5}.jpg

erweitert sich auf

xargs -I_ cat _/11/8.jpg _/11/7.jpg _/11/6.jpg _/11/5.jpg _/12/8.jpg _/12/7.jpg _/12/6.jpg _/12/5.jpg _/13/8.jpg _/13/7.jpg _/13/6.jpg _/13/5.jpg _/14/8.jpg _/14/7.jpg _/14/6.jpg _/14/5.jpg _/15/8.jpg _/15/7.jpg _/15/6.jpg _/15/5.jpg

aber ich brauchte die zweite Klammererweiterung, die zuerst durchgeführt wurde und nachgab

xargs -I_ cat _/11/8.jpg _/12/8.jpg _/13/8.jpg _/14/8.jpg _/15/8.jpg _/11/7.jpg _/12/7.jpg _/13/7.jpg _/14/7.jpg _/15/7.jpg _/11/6.jpg _/12/6.jpg _/13/6.jpg _/14/6.jpg _/15/6.jpg _/11/5.jpg _/12/5.jpg _/13/5.jpg _/14/5.jpg _/15/5.jpg

Das Beste, was ich mir dazu einfallen lassen konnte, war

xargs -I_ cat $(eval echo _/'{11..15}'/{8..5}.jpg)

Dies funktioniert, weil die einfachen Anführungszeichen den ersten Satz von Klammern während des Parsens der evalBefehlszeile vor einer Erweiterung schützen und sie durch die von aufgerufene Unterschale erweitert werden können eval.

Es mag ein listiges Schema geben, das verschachtelte Klammererweiterungen beinhaltet, die dies in einem Schritt ermöglichen, aber wenn es welche gibt, bin ich zu alt und dumm, um es zu sehen.

Sie haben nach typischen Verwendungszwecken gefragt.

Eine häufige Beschwerde über Shell-Skripte ist, dass Sie (angeblich) nicht als Referenz übergeben können, um Werte aus Funktionen zurückzugewinnen.

Aber eigentlich über "eval" Sie können als Verweis übergeben. Der Angerufene kann eine Liste von Variablenzuweisungen zurückgeben, die vom Anrufer ausgewertet werden sollen. Es wird als Referenz übergeben, da der Aufrufer die Namen der Ergebnisvariablen angeben kann (siehe Beispiel unten). Fehlerergebnisse können Standardnamen wie errno und errstr zurückgegeben werden.

Hier ist ein Beispiel für die Übergabe als Referenz in Bash:

#!/bin/bash
isint()
{
    re='^[-]?[0-9]+$'
    [[ $1 =~ $re ]]
}

#args 1: name of result variable, 2: first addend, 3: second addend 
iadd()
{
    if isint ${2} && isint ${3} ; then
        echo "$1=$((${2}+${3}));errno=0"
        return 0
    else
        echo "errstr=\"Error: non-integer argument to iadd $*\" ; errno=329"
        return 1
    fi
}

var=1
echo "[1] var=$var"

eval $(iadd var A B)
if [[ $errno -ne 0 ]]; then
    echo "errstr=$errstr"
    echo "errno=$errno"
fi
echo "[2] var=$var (unchanged after error)"

eval $(iadd var $var 1)
if [[ $errno -ne 0 ]]; then
    echo "errstr=$errstr"
    echo "errno=$errno"
fi  
echo "[3] var=$var (successfully changed)"

Die Ausgabe sieht folgendermaßen aus:

[1] var=1
errstr=Error: non-integer argument to iadd var A B
errno=329
[2] var=1 (unchanged after error)
[3] var=2 (successfully changed)

In dieser Textausgabe ist die Bandbreite nahezu unbegrenzt ! Und es gibt mehr Möglichkeiten, wenn mehrere Ausgabezeilen verwendet werden: z. B. könnte die erste Zeile für variable Zuweisungen verwendet werden, die zweite für einen kontinuierlichen „Gedankenstrom“, aber das würde den Rahmen dieses Beitrags sprengen.

Ich mag die Antwort "Bewerten Sie Ihren Ausdruck ein weiteres Mal vor der Ausführung" und möchte dies anhand eines anderen Beispiels verdeutlichen.

var="\"par1 par2\""
echo $var # prints nicely "par1 par2"

function cntpars() {
  echo "  > Count: $#"
  echo "  > Pars : $*"
  echo "  > par1 : $1"
  echo "  > par2 : $2"

  if [[ $# = 1 && $1 = "par1 par2" ]]; then
    echo "  > PASS"
  else
    echo "  > FAIL"
    return 1
  fi
}

# Option 1: Will Pass
echo "eval \"cntpars \$var\""
eval "cntpars $var"

# Option 2: Will Fail, with curious results
echo "cntpars \$var"
cntpars $var

Die merkwürdigen Ergebnisse in Option 2 sind, dass wir 2 Parameter wie folgt übergeben hätten:

• Erster Parameter: "value
• Zweiter Parameter: content"

Wie ist das für kontraintuitiv? Das zusätzlicheeval wird das beheben.

Angepasst von https://stackoverflow.com/a/40646371/744133

In der Frage:

who | grep $(tty | sed s:/dev/::)

gibt Fehler aus, die behaupten, dass die Dateien a und tty nicht vorhanden sind. Ich habe dies so verstanden, dass tty nicht vor der Ausführung von grep interpretiert wird, sondern dass bash tty als Parameter an grep übergeben hat, der es als Dateinamen interpretiert hat.

Es gibt auch eine Situation verschachtelter Umleitung, die von übereinstimmenden Klammern behandelt werden sollte, die einen untergeordneten Prozess angeben sollten. Bash ist jedoch primitiv ein Worttrennzeichen, das Parameter erstellt, die an ein Programm gesendet werden sollen. Daher werden Klammern nicht zuerst abgeglichen, sondern als interpretiert gesehen.

Ich wurde spezifisch mit grep und gab die Datei als Parameter an, anstatt eine Pipe zu verwenden. Ich habe auch den Basisbefehl vereinfacht und die Ausgabe eines Befehls als Datei übergeben, damit die E / A-Piping nicht verschachtelt wird:

grep $(tty | sed s:/dev/::) <(who)

funktioniert gut.

who | grep $(echo pts/3)

ist nicht wirklich erwünscht, beseitigt aber das verschachtelte Rohr und funktioniert auch gut.

Zusammenfassend scheint Bash kein verschachteltes Pipping zu mögen. Es ist wichtig zu verstehen, dass bash kein rekursiv geschriebenes New-Wave-Programm ist. Stattdessen ist bash ein altes 1,2,3-Programm, an das Funktionen angehängt wurden. Um die Abwärtskompatibilität sicherzustellen, wurde die ursprüngliche Interpretationsweise nie geändert. Wenn bash so umgeschrieben würde, dass es zuerst mit Klammern übereinstimmt, wie viele Fehler würden in wie viele bash-Programme eingeführt? Viele Programmierer lieben es, kryptisch zu sein.