cat vs editor (gelöst)

[fischig]

Welche Vorteile hat die Benutzung von cat gegenüber einem Konsoleneditor?

[MSfree]

Welche Vorteile hat die Benutzung von cat gegenüber einem Konsoleneditor?

Welche Vorteile hat die Benutzung eines Staubsaugers gegenüber eines Bügeleisens?

cat und Editor sind zwei so eklatant unterschiedliche Werkzeuge, daß man da kaum Parallelen ziehen kann, die man vergleichen könnte.

[debilian]

mit cat mach ich so Dinge wie:

Code: Alles auswählen

cat dateiname |grep doener

aus Gewohnheit, um bspw. zu schaun, ob ein Wort in einer Datei ist.....
da muss ich mit vi ja dann /Wort reintippen, wenn die Datei offen ist, das ist mir da zu umständlich.....
schlaue Leute machen das nur mit grep (Gewohnheit)

gruss

[MSfree]

Useless use of cat:

Code: Alles auswählen

cat dateiname |grep doener

Ohne cat:

Code: Alles auswählen

grep doener dateiname 

[debilian]

Useless use of cat:

das habe ich ja geschrieben, Gewohnheit....
(schlaue Leute machen das nur mit grep (Gewohnheit))

[hikaru]

Welche Vorteile hat die Benutzung von cat gegenüber einem Konsoleneditor?

Beiden gemeinsam ist, dass man damit Dateiinhalte anschauen kann.
Die wesentlichen Vorteile von cat sind dabei, dass man:
1. mit cat nicht versehentlich Dateien kaputtmachen kann ( Es sei denn natürlich, man wird "kreativ": cat DATEI >! DATEI )
2. cat sich in Pipes einbauen lässt (s. debilians UUoC-Beispiel )

die wesentlichen Nachteile sind, dass man:
1. mit cat keine Dateien bearbeiten kann
2. cat kein Syntaxhighlighting hat

[MSfree]

Beiden gemeinsam ist, dass man damit Dateiinhalte anschauen kann.

Wenn man sehr schnelle Augen hat

Eine Datei mit hunderttausend Zeilen huscht dermassen schnell mit cat über den Bildschirm, daß man von "schauen" eigentlich nicht sprechen kann.

2. cat sich in Pipes einbauen lässt (s. debilians UUoC-Beispiel )

Useless use of cat?

Code: Alles auswählen

cat Datei | less

[Meillo]

Muesste die Frage nicht `cat' (plus Scrollen im Terminal) vs. `less' sein?


Ein relevanter Aspekt aus meiner Sicht: `cat' gibt Binaerzeichen unveraendert aus (wodurch man sich das Terminal zerschiessen kann), waehrend Pager und Editoren ueblicherweise Ersatzdarstellungen haben.

[MSfree]

`cat' gibt Binaerzeichen unveraendert aus (wodurch man sich das Terminal zerschiessen kann)

Gegen zerbröselte Terminals hilft

Code: Alles auswählen

stty sane

[fischig]

Danke debilian, danke hikaru, danke Meillo!

Auslöser meiner Frage war, dass ich hier häufig lese, dass Dateien, die ich unbedarfter Mensch mit einem Editor öffnen würde, von Leuten, die ich für deutlich kompetenter halte, häufig mit cat (ohne pipe) geöffnet werden. cat benutze ich eigentlich nie. Und da dachte ich mir: Vielleicht ist da ja noch was zu lernen

Gibt's weitere Anwendungsfälle/Vor- und Nachteile?

[hikaru]

Eine Datei mit hunderttausend Zeilen huscht dermassen schnell mit cat über den Bildschirm, daß man von "schauen" eigentlich nicht sprechen kann.

Dein Monitor ist einfach zu klein.

Ernsthaft:
Ich ging davon aus, dass fischig hier eher "einfache" Dateien betrachtet, wie z.B. die fstab oder die sources.list.

Useless use of cat?

Manchmal ist das gar nicht so useless. Wenn ich z.B. lange Pipe-Konstrukte baue, dann schiebe ich da zu Testzwecken schon mal mit cat einen definierten Input rein, um zu schauen, ob die Pipe das macht was ich erwarte, bevor ich das eigentliche Input-Kommando davor setze.
Ja, ich könnte auch dem ersten Kommando der Pipe die Inputdatei als Argument übergeben, aber dann muss ich am Ende wieder daran denken, das rückgängig zu machen.

Gibt's weitere Anwendungsfälle/Vor- und Nachteile?

Ein cat-Output lässt sich einfacher in einem Forenpost verwurten, als der "Screenshot" (ob nun als Bild oder in ASCII) eines Editors. Es spart z.B. langatmige Erklärungen in Prosa.
Wenn ich z.B. ein Problem habe und gebeten werde, meine sources.list zu zeigen, dann kann ich entweder das posten und werde möglicherweise gefragt, ob das Alles ist:

Code: Alles auswählen

deb http://deb.debian.org/debian/ bookworm main contrib non-free-firmware
deb http://security.debian.org/debian-security bookworm-security main contrib non-free-firmware
deb http://deb.debian.org/debian/ bookworm-updates main contrib non-free-firmware
deb http://deb.debian.org/debian/ bookworm-backports main contrib non-free-firmware

oder ich poste das und beseitige alle Zweifel:

Code: Alles auswählen

hikaru@t430:~$ cat /etc/apt/sources.list
deb http://deb.debian.org/debian/ bookworm main contrib non-free-firmware
deb http://security.debian.org/debian-security bookworm-security main contrib non-free-firmware
deb http://deb.debian.org/debian/ bookworm-updates main contrib non-free-firmware
deb http://deb.debian.org/debian/ bookworm-backports main contrib non-free-firmware

hikaru@t430:~$

[Meillo]

Auslöser meiner Frage war, dass ich hier häufig lese, dass Dateien, die ich unbedarfter Mensch mit einem Editor öffnen würde, von Leuten, die ich für deutlich kompetenter halte, häufig mit cat (ohne pipe) geöffnet werden.

Das liegt vielleicht auch einfach an einer Abweichung zwischen dem was die Leute beim Arbeiten machen und das was sie zur Demonstration im Forum posten.

Im Normalfall weiss ich nicht wie gross/lange Textdateien sind, darum mache ich sie fast immer mit `less' auf, wenn ich sie anschauen will. (Selbst wenn ich sie spaeter ggf. bearbeiten will, da man aus `less' mit `v' direkt in den Editor/vi wechseln kann.)

Wenn ich aber eine Anleitung im Forum poste, dann kann ich `less' dabei nicht darstellen. Falls moeglich, verwende ich dann also `cat', weil ich dort die Terminalsession 1:1 posten kann. Das ist insbesondere bei Scriptingaufgaben der Fall, die oft kleine Test-Input-Dateien haben.

Ich denke, dass dieses Phaenomen der Hauptgrund fuer deine Wahrnehmung ist.


Edit: Ach, ich sehe gerade, dass hikaru das auch schon gepostet hat.

[hikaru]

Edit: Ach, ich sehe gerade, dass hikaru das auch schon gepostet hat.

Aber du hast es verständlicher ausgedrückt.

[MSfree]

Ich ging davon aus, dass fischig hier eher "einfache" Dateien betrachtet, wie z.B. die fstab oder die sources.list.

Und ich dachte an Logfiles, die durchaus sehr lang werden können. Daher ja auch die Bemerkung, daß cat und ein Editor zwei völlig unterschiedliche Dinge sind, die man kaum vergleichen kann.

Im Normalfall weiss ich nicht wie gross/lange Textdateien sind, darum mache ich sie fast immer mit `less' auf

Zumindest die Anzahl Bytes kann man leicht ermitteln, was einem eine grobe Einschätzung der Länge erlaubt. less wäre aber auch das Mittel meiner Wahl, mit dem man durch Dateien blättern, zum Anfang/Ende springen und nach Strings suchen kann, ohne deren Inhalt zu manipulieren.

Nur, wenn ich weiß, daß eine Datei sehr kurz ist (sources.list, fstab, /ec/default/grub...) nutze ich auch mal cat oder zum Pipen in andere Programme. Einen Editor werfe ich nur an, wenn ich die Datei bearbeiten will.

[fischig]

Ich ging davon aus, dass fischig hier eher "einfache" Dateien betrachtet, wie z.B. die fstab oder die sources.list.

Stimmt!
Und der Eindruck verstärkt sich, dass cat vor allem genutzt wird von Leuten, die ziemlich kompetent AN ihrem System arbeiten. Ich zähle mich nicht dazu und benutze cat auch nach über 20 Jahren Debian eigentlich nie. Und wenn ich dann in einem Beitrag sinngemäß lese: Poste mal „cat /etc/fstab“ und ich den TE erst mal so einschätze: „Oha, das wird langwierig, wenn's denn überaupt zu einer Lösung kommt,“ dann frage ich mich, ob's nicht für den leichter verständlich wäre, wenn er aufgefordert würde: „Mach mal mal nano /etc/fstab“. Ob der je schon von cat gehört/gelesen hat?

Vielleicht schließe ich, was die Einschätzung des skizzierten Fragestellers betrifft, aber auch zu sehr von mir auf andere. Vielleicht gilt auch: „Wenn der mit cat nichts anzufangen weiß, wird das eh nichts.“ Eure Ausführungen finde ich aufschlussreich, vielleicht erinnere ich mich gelegentlich daran, hier noch mal nachzugucken.

[cosinus]

Und ich dachte an Logfiles, die durchaus sehr lang werden können.

Hat hier jemand ernsthaft einem TO vorgeschlagen, er solle mit cat z.B. auf /var/log/syslog gehen und die Ausgabe posten?
Da ich erst letztens einem TO was mit cat vorschlug: das bezog sich auf die sources.list; mit cat den Inhalt ausgeben und dann eben die Ausgabe aus dem Terminal kopieren und ins Forum einfügen. @hikaru hat es ganz genau wiedergegeben

[Meillo]

Und wenn ich dann in einem Beitrag sinngemäß lese: Poste mal „cat /etc/fstab“ und ich den TE erst mal so einschätze: „Oha, das wird langwierig, wenn's denn überaupt zu einer Lösung kommt,“ dann frage ich mich, ob's nicht für den leichter verständlich wäre, wenn er aufgefordert würde: „Mach mal mal nano /etc/fstab“.

- cat ist auf jedem System installiert, nano nicht.
- cat beendet sich automatisch, bei nano muss man irgendwas eingeben, um wieder rauszukommen.
- Fuer Personen, die beide Programme nicht kennen ist cat einfacher zu verstehen und lernen als nano.
- Personen, die cat nicht kennen, verwenden meist auch nicht nano, sondern einen grafischen Editor.
- Wie kopiert man bei nano die Ausgabe wenn sie nicht auf eine Bildschirmseite passt? Bei cat ist das in der Regel kein Problem.

Ich denke, dass deine Sichtweise speziell fuer deine Situation ist, im Allgemeinen aber der Ansatz mit cat sinnvoller ist.

[MSfree]

Ob der je schon von cat gehört/gelesen hat?

Das Äquivalent unter DOS/Windows heißt type, kennen aber vermnutlich genauso wenige.

[hikaru]

„Mach mal mal nano /etc/fstab“. Ob der je schon von cat gehört/gelesen hat?

Bei deinem hypothetischen TE hätte ich neben der bereits genannten Punkte die "Befürchtung", einen Screenshot in Form eines Bildes von nano zu bekommen, während ich mir bei cat höhere Chancen ausmalen würde, ein ASCII-Zitat der Ausgabe zu kriegen.

[cosinus]

Das Äquivalent unter DOS/Windows heißt type, kennen aber vermnutlich genauso wenige.

Das hier

Code: Alles auswählen

copy datei.txt con

ginge auch

[fischig]

- cat ist auf jedem System installiert, nano nicht.

Soweit mir bekannt, wird nano bei jeder Debian-Installation installiert.

- Wie kopiert man bei nano die Ausgabe wenn sie nicht auf eine Bildschirmseite passt?

Guter Punkt! Deswegen musste ich mich in der Anfangszeit mit vi* beschäftigen und war heilfroh als es neben mcedit auch nano gab.

Ich denke, dass deine Sichtweise speziell fuer deine Situation ist

Das stimmt auch, soweit es um mich geht. Aber mein Auslöser für diesen Thread war eher der Versuch, mich in einen Anfänger hineinzudenken, der aufgefordert wird, eine der zentralen - und in der Regel nicht allzu langen config-Dateien zu posten.

- Fuer Personen, die beide Programme nicht kennen, ist cat einfacher zu verstehen und lernen als nano.

Das bezweifle ich, zumindest wenn ich „nano“ durch „Konsoleneditor“ ersetze. Wer ernsthaft mit Debian arbeiten will, wird, auch wenn er nicht tiefer am Debian arbeiten will, um einen Konsoleneditor nicht herumkommen. Und ich denke, das ist auch gut so, weil's für mich Debian ausmacht.
Skeptischer bin ich was die Förderung der Bewältigung administrativer Probleme mittels grafischem Editor durch Dinge wie pkexec, polickit, etc. angeht. Aber das ist ein neues Fass und da fühle ich mich auch nicht sonderlich kompetent.

Eher abschließend: Ob man einem Anfänger gegenüber durch die Ersetzung von cat durch nano viel gewinnt, weiß ich auch nicht. Ich wollt's halt mal angedacht haben.

edit2: Streichung

[cosinus]

Vorschlag:
Man könnte den TOs ja auch sagen, sie sollen ihre sources.list da hochladen und im Beitrag verlinken. Allerdings müsste der Admin dann Dateien mit der Endung .list erlauben

[debilian]

Eine Datei mit hunderttausend Zeilen huscht dermassen schnell mit cat über den Bildschirm, daß man von "schauen" eigentlich nicht sprechen kann.

dafür nehme ich:

Code: Alles auswählen

cat dateiname |more

[cosinus]

Und wenn du nur das Ende der Datei sehen willst nimmst du bestimmt

Code: Alles auswählen

cat $FILE | tail

richtig?

[debilian]

nö, dann

Code: Alles auswählen

tail -n 100

z.B.



- aber grundsätzlich hast du recht, falsche Nutzung von cat und more bei mir.....