Ich habe ein Tutorial durchgearbeitet und sowohl cat myfile.txt
als auch verwendet cat < myfile.txt
. Gibt es einen Unterschied zwischen diesen beiden Befehlsfolgen? Es scheint, dass beide den Inhalt einer Datei in die Shell drucken.
Ich habe ein Tutorial durchgearbeitet und sowohl cat myfile.txt
als auch verwendet cat < myfile.txt
. Gibt es einen Unterschied zwischen diesen beiden Befehlsfolgen? Es scheint, dass beide den Inhalt einer Datei in die Shell drucken.
Antworten:
Im ersten Fall wird cat
die Datei geöffnet, und im zweiten Fall wird die Datei von der Shell geöffnet und als cat
Standardeingabe übergeben.
Technisch könnten sie unterschiedliche Auswirkungen haben. Zum Beispiel wäre es möglich, eine Shell-Implementierung zu haben, die mehr (oder weniger) privilegiert ist als das cat
Programm. In diesem Szenario kann es sein, dass einer die Datei nicht öffnet, während der andere dies könnte.
Das ist nicht das übliche Szenario, aber erwähnt, dass die Shell und cat
nicht das gleiche Programm sind.
sudo cat myfile.txt
. Funktioniert sudo cat < myfile.txt
jedoch nicht, wenn Sie keine Berechtigungen zum Lesen der Datei haben.
ksh93
ist cat
(standardmäßig nicht aktiviert, es sei denn, Sie haben bereits /opt/ast/bin
früh daran gearbeitet $PATH
).
wc
den Dateinamen vor der Anzahl aus, wenn ein Argument angegeben wird.
Es gibt keinen wesentlichen sichtbaren Unterschied in Ihrem Testfall. Die offensichtlichste ist die Fehlermeldung, die Sie erhalten, wenn myfile.txt
im aktuellen Verzeichnis keine Datei mit dem Namen vorhanden ist oder wenn Sie sie nicht lesen dürfen.
Im ersteren Fall cat
wird sich die Shell beschweren und im letzteren Fall wird deutlich, welcher Prozess versucht, die Datei zu öffnen, cat
im ersteren und in der Shell im letzteren.
$ cat myfile.txt
cat: myfile.txt: No such file or directory
$ cat < myfile.txt
ksh93: myfile.txt: cannot open [No such file or directory]
In einem allgemeineren Fall besteht ein wesentlicher Unterschied darin, dass Umleitungen nicht zum Drucken des Inhalts mehrerer Dateien verwendet werden können, was schließlich dem ursprünglichen Zweck des Befehls cat
(dh cat enate) entspricht. Beachten Sie, dass die Schale trotzdem versuchen , alle Dateien zu öffnen , wie umgeleitet Eingabe übergeben, aber nur passieren tatsächlich die letzte zu , cat
es sei denn Sie verwenden zsh
und seine multios
„zshism“.
$ echo one > one
$ echo two > two
$ cat one two # cat opens one, shows one, opens two, shows two
one
two
$ cat < one < two # sh opens one then opens two, cat shows stdin (two)
two
$ rm one two
$ echo one > one
$ cat one two # cat opens and shows one, fails to open two
one
cat: two: No such file or directory
$ cat < one < two # the shell opens one then opens two, fails and
# displays an error message, cat gets nothing on stdin
# so shows nothing
ksh93: two: cannot open [No such file or directory]
Auf einem Standardsystem haben die Shell und cat
die Dateizugriffsrechte keinen Unterschied, sodass beide gleichermaßen fehlschlagen. Die Verwendung sudo
der cat
Rechte von raise wird einen großen Unterschied im Verhalten bewirken, wie Thomas Dickey und die beigefügten Kommentare bereits angedeutet haben.
ksh
Ihren eigenen Willen, und wenn ja, warum ?
bash
, ksh93
ist bei weitem die bessere Schale. es ist fast die Muschel.
cat < file1 > file2
wirkt sich dies ganz anders aus, cat file1 > file2
als wenn file1
es nicht lesbar oder nicht vorhanden ist. (Das letztere Formular wird abgeschnitten file2
, das erstere nicht.)
cat myfile.txt
Liest die Datei myfile.txt
und druckt sie dann auf die Standardausgabe.
cat < myfile.txt
cat
Da hier keine zu öffnenden Dateien angegeben sind, werden - wie bei vielen Unix-Befehlen - die Daten von der Standardeingabe gelesen, die file.txt
von der Shell an diese geleitet wird, und auf die Standardausgabe gedruckt.
@Thomas Dickeys Antwort ist brillant.
Ich möchte nur einige offensichtliche Fakten über den Fall des Lesens mehrerer Dateien hinzufügen (die mit Ihrer Frage in Zusammenhang stehen, aber immer noch):
cat <file1 <file2 <file3
liest nur file3, zumindest in bash. (Tatsächlich hängt es von Shell, aber die meisten Schalen werden dup jede angegebene Datei stdin, die die letzte zu Effekt verursacht.)cat file1 file2 file3
liest alle angegebenen Dateien nacheinander (tatsächlich ist cat eine verkürzte Form des Wortes verketten ).cat file1 file2 file3 <file4 <file5 <file6
liest nur Datei1, Datei2, Datei3 (da cat stdin ignoriert, wenn Dateinamenargumente übergeben werden).
cat file1 file2 - file3 <file4 <file5 <file6
liest file1, file2, file6, file3 (als Bindestrich zwingt cat, stdin nicht zu ignorieren).Und über Fehler. Wenn einige der als Argumente angegebenen Dateien nicht geöffnet werden können (ohne <
), überspringt cat fehlgeschlagene Dateien (mit der Ausgabe der entsprechenden Nachricht an stderr), liest jedoch noch andere Dateien. Wenn mindestens eine der als Umleitungen (mit <
) angegebenen Dateien nicht geöffnet werden kann , startet die Shell cat nicht (dies gilt auch für Umleitungen, die von cat nicht verwendet werden). In beiden Fällen wird ein fehlerhafter Beendigungscode zurückgegeben.
cat
trotzdem file1
und geöffnet wird file2
, genau file4
wie file5
in und in Ihrem dritten Beispiel. Es wird nur angezeigt file3
, resp. file6
Inhalt, wenn diese vorherigen offenen Anweisungen erfolgreich sind.
Mit einem anderen Befehl können wir den Unterschied feststellen zwischen:
wc –w food2.txt
.
Mögliche Ausgabe:
6 food2.txt
.
Der Befehl gibt den Dateinamen an, da er ihn kennt (als Argument übergeben).
wc –w < food2.txt
.
Mögliche Ausgabe:
6
.
Die Standardeingabe wird in die Datei food2.txt umgeleitet, ohne dass der Befehl davon Kenntnis hat.