Verwenden von _< anstelle von < für stdin mit bash

Verwenden von _< anstelle von < für stdin mit bash

Was ist der Unterschied zwischen der Verwendung von _<und <für stdin bei der Verwendung der Prozesssubstitution? Dies erfolgt mit Bash.

Beispiel:

read bytes _< <(du -bcm random_iso.iso | tail -1); echo $bytes

Antwort1

Dies ist kein _<Operator, sondern ein _an read und den <Umleitungsoperator zu übergebendes Argument. <(cmd)Es handelt sich selbst um eine Prozesssubstitution (die zu einem Dateinamen erweitert wird, der auf eine Pipe verweist).

Folgendes wird ausgeführt:

read bytes _  < /proc/self/fd/x

Wobei fd x das lesende Ende einer Pipe ist.

Am anderen (Schreib-)Ende der Pipe wird ein Subshell-Prozess im Hintergrund ausgeführt, du -bcm random_iso.iso | tail -1dessen Standardausgabe auf diese Pipe umgeleitet wird.

Daher wird in der Variablen das erste Wort der letzten Zeile der Ausgabe und der Rest der Zeile in der Variablen readgespeichert .$bytesdu -bcm$_

Nun weiß ich nicht, wo das du -bcmSinn ergibt. Weder die -b, -cnoch -mdie Optionen sind Standard. Während -crecht üblich ist und zur Angabe der Gesamtgröße dient, dient bei GNU dudie -bAngabe der Dateigröße (nicht der Festplattennutzung) in Bytes, während -mdie Angabe der Größe auf das nächste Mebibyte aufgerundet wird, wären dies widersprüchliche Optionen (obwohl sie vielleicht -bwegen des Nebeneffekts der Aktivierung von verwendet wurden --apparent-size). FreeBSD hat du -m(für Mebibyte), kein -b, Solaris hat weder das eine noch das andere...

Es scheint, als wäre es als komplizierte Schreibweise gedacht gewesen:

wc -c < random_iso.iso

Oder:

du --apparent-size -cm random_iso.iso | awk 'END{print $1}'

Wenn sie tatsächlich wollten, dass die Dateigröße auf einem GNU-System auf das nächste Mebibyte aufgerundet wird.

Antwort2

Wie erwähnt _<handelt es sich nicht um eine Umleitung. Dies wird _als letztes Argument an übergeben read. Dies <wird dann als separater Umleitungsoperator interpretiert, der die Ausgabe der Prozesssubstitution an stdin umleitet.

In Bash-Skripten ist es üblich geworden, _in Verbindung mit dem integrierten Befehl eine „Wegwerfvariable“ zu verwenden read. In Bash _ist eine spezielle Variable, die nach der Ausführung jedes Befehls auf das letzte Argument eines Befehls gesetzt wird. In diesem Fall bedeutet dies, dass bytesdas erste Feld zugewiesen wird und die verbleibenden Felder in die _Variable verworfen werden, anstatt alle verbleibenden Felder zuzuweisen bytes.

Obwohl es sich hierbei um eine Konvention handelt, gibt es eine Reihe guter Gründe, einen _solchen Missbrauch zu vermeiden.

  • Dieses Verhalten _ist von POSIX nicht spezifiziert. Die meisten Shells machen damit nichts Besonderes.
  • In hat das Attribut zsh, und seine Verwendung führt dazu, dass die Shell einen Fehler ausgibt._readonly
  • In hat mkshnur _im interaktiven Modus das Verhalten von Bash. In einem nicht interaktiven Skript _wird für einen anderen Zweck verwendet und ihm wird nach jedem Befehl nichts zugewiesen.
  • in wird nur auf das letzte Argument des letzten Befehls in einer Zeile gesetzt. Befehle müssen physisch in separaten Codezeilen angeordnet sein, um verwenden zu können ksh93. Darüber hinaus ist in ksh93 überladen, um viele, viele andere Verwendungsmöglichkeiten in verschiedenen Kontexten zu haben, daher wird die Zuweisung zu diesem Zweck nicht empfohlen und führt je nach Kontext zu unterschiedlichen Ergebnissen.____

Ich empfehle, vor einer Weiterleitung ein Leerzeichen zu setzen, um die Dinge klarer zu machen. Ich habe einige Richtlinien für einen guten Weiterleitungsstil inDieser Artikel.

verwandte Informationen