Ich verwende auch cat für kleine Dateien und tail -f für log-Dateien (statt watch tail). Für große Dateien verwende ich less für ein schnelles kurzes Betrachten und vim für sonst, da ich mit vim besser an die gewünschten Stellen springen kann und eine Syntax-Einfärbung habe.
Jo hier auch. vi oder emacs sind mir von der Bedienung einfach zu lernintensiv.
Bei kleinen Dateien nehme ich auch cat, oder zum Verfolgen von log-Dateien gerne "tail -f". Manches mache ich dann auch wieder mit MC - gerade wenn dieser ohnehin schon läuft. Speziell beim Programmieren setze ich dann aber auf ne komplette IDE mit Auto-Vervollständigung - gibt ja wohl echt Leute, die Programme nur mit vi und gcc zusammenbasteln.
Das ist auch der Editor meiner Wahl. Ist natürlich nicht so mächtig, wie vim oder emacs aber für meine Zwecke vollkommen ausreichend.
Ich habe zwar mal angefangen den vimtutor zu bearbeiten, aber als ich zum ersten mit vim wirklich eine config bearbeiten wollte artete das in eine Rumprobiererei aus, da ich mir mit den Kürzeln nicht mehr sicher war.
Leute die viel und oft in der Konsole arbeiten sind mit den Kürzeln sicherlich wesentlich effizienter als man es mit nano sein kann, aber für jemanden wie mich, der ab und an mal eine Datei bearbeitet fehlt es dann einfach an Übung um sich die ganzen Kürzel zu merken, da man sie ja nicht ständig benötigt. Und für diese Zielgruppe ist nano wohl auch gedacht. Ich möchte ihn zumindest nicht missen.
Für größere Dateien wie Logs nehme ich meist less. Sollte die Datei klein sein, dann wähle ich cat. Wenn ich ein Diff zu einer anderen Datei brauche wird Vim genommen.
Wenn ich zu einen graphischen Diff-Werkzeug greife, dann nehme ich kdiff3. Trotz des Namens kommt es auch ohne KDE-Abhängigkeiten aus. Ich kann aber jetzt nicht sagen ob es besser oder schlechter als Meld ist. Ich bin bei kdiff3 einfach hängen geblieben weil es gut genug für mich ist.
Meistens benutze ich less, weil cat über Binärdaten die Konsole zerschießt. less zeigt bei mir auch PDFs, Docs und DEB-Pakete an :) "most" ist ziemlich praktisch, weil es auch Hex bietet (jedoch nicht die obrigen Dokumente). Und nano hilft schnell beim Sprung zu einer Zeile oder der Suche ohne erst Emacs etc. zu starten.
...was ich genau vorhabe. Häufig verwende ich cat im Zusammenspiel mit less, wenn ich weiß dass die Datei viel Inhalt hat oder wenn ich mir nicht sicher bin. Wenn ich Sachen in Dateien Suche, um sie zu bearbeiten, verwende ich in der Regel sofort vim. Damit kann ich's ja dann auch gleich bearbeiten.
mc habe ich schon mehrfach ausprobiert, aber so richtig kann ich mich damit auch nicht anfreunden.
Eine absolute Unsitte der man auch ständig in irgendwelchen Scripten begegnet. Was hat cat euch denn getan, dass es ständig unnötigerweise missbraucht wird?
Du musstest noch nie wirklich grottenalte Shell-Scripts debuggen weil sie selbst auf modernster Hardware Ewigkeiten mit sich selbst gespielt haben, stimmts? Wenn du dir die Zeiten mal ansiehst wirst du erkennen, dass die Ausführungsgeschwindigkeit ohne *cat* fast halbiert wurde.
Das war ein aus der Hand geschütteltes Beispiel mit 26 Dateien. Du wirst es nicht glauben, es gibt Systeme mit wesentlich mehr Dateien und zig Loops welche mit solchen Pipe-Orgien den Sauerstoffgehalt der Erde reduzieren. Das wirst du jetzt nicht verstehen. Ist auch nicht schlimm. Es gibt ja Leute die das wieder in Ordnung bringen.
Kannst du auch machen: grep foo bar < bar grep foo
Ich bin kein Shell-Experte, aber es hat halt meines Wissens Nachteile. Zunächst einmal wird durch < nicht cat aufgerufen, sondern es handelt sich typischerweise um eine Shell-Funktion, wobei ich mir vorstellen könnte, dass manche Shells in so einem Fall auch cat aufrufen, wer weiß. Dazu kommt, dass du wesentlich effizienter eine Dateiliste aufbauen. Kannst du mittels < prinzipiell auch, aber das wird tendenziell sehr sehr unübersichtlich.
Dennoch kann es sehr hilfreich sein, da du es mit einer Pipe kombinieren kannst, was bei der "normalen" Dateiübergabe typischerweise nicht möglich ist: ... foo |
Das würde die Ausgabe von ... foo sowie die Datei foo2 nach bar "greppen". Ist sicher nicht der Standardfall, aber ich kann mir schon vorstellen, dass es in der einen oder anderen Situation nützlich sein kann.
Da hast du wohl Recht. Aber wer kann sich schon merken, in welcher Reihenfolge die Parameter von grep stehen müssen. Außerdem ist cat * | grep irgendwas schon ein Unterschied zu grep irgendetwas * . Da bräuchte man schon grep irgendetwas * | sed s/.*:// oder irgendeinen Parameter von grep, den man sich noch viel schwerer merken kann.
Ich sehe wenig Sinn drin, mir die Ausgaben von "rpm", "zypper" oder anderen Programmen in eine Datei schreiben zu lassen, wenn ich nur eine Sache daraus brauche, z.B. wenn ich ein Programm oder eine Datei suche. Da nehme ich less um bei recht einfachen Begriffen auch noch die Übersicht zu behalten. Klar, ich könnte den Puffer meines Terminals vergrößern, aber will ich das? less erfüllt hier seinen Zweck. Ich erachte es also keineswegs als Unsitte an.
Wenn du Performance willst, solltest du vielleicht kein Shellscript verwenden, sondern gleich auf C umsteigen. Die Zeit, die du damit sparst ist so gering, dass es sich nicht lohnt.
Wo stand etwas von der Unsitte *less* zu verwenden? Da stand etwas von *cat* als Paradebeispiel für die teilweise ausufernden Pipe-Orgien in Shell-Scripten. Und diese Pipe-Orgien zu beseitigen bzw. zu minimieren bringt durchaus schon mal Geschwindigkeitgewinne von 80-90%.
Auf C umzusteigen bringt in diesem Falle garnichts. Wer solche Shell-Scripte hinzaubert bekommt auch keine effizienten Programme in C gebacken.
So ähnlich geht es mir auch, auch wenn ich nicht cat im Zusammenspiel mit grep verwenden würde, aber dazu gibt es hier ja schon Kommentare.
Im Endeffekt kommt es einfach darauf an, was man mit den Dateien bzw. mit dem Stream anfangen will.
Wenn ich wirklich "nur" eine Datei betrachten will, dann nutze ich meistens vim und nicht cat o.ä. Grund ist hier einfach, dass vim für fast alle Arten von Dateien Syntax Highlighting bietet, oftmals wird die Ausgabe dadurch eben besser lesbar und zudem bietet vim eben auch bessere Methoden sich in der Ausgabe zu bewegen als eben cat (wobei es hier natürlich mittels screen auch Möglichkeiten gibt, wenn man das nutzt). cat selbst verwende ich nur, wenn ich weiß, dass die Datei nur wenige Zeilen enthält. tail nutze ich eher, wenn ich die Änderungen einer Datei verfolgen will, also mittels -f. Z.B. bei Logdateien. head nutze ich eigentlich fast nur im Zusammenhang mit ls, z.B. um die 10 größten Dateien in einem Verzeichnis anzuzeigen. Gut möglich, dass es hier einfachere Methoden gibt, aber so hab ich es mir eben angewöhnt. ;) less kommt als Pager natürlich häufig zum Einsatz, insbesondere, wenn man Dateien vergleich, allerdings weiche ich hier sehr häufig auf vimpager (bei mir vip um es kurz zu halten) aus, wenn es sich nicht um einen stetigen Stream handelt (da vip erst anzeigt, wenn alle Daten vollständig angekommen sind, less zeigt es "on-the-fly" an). Grund ist auch hier wieder das Syntax Highlighting von vim. Zeitweise hatte ich auch als Pager das Programm most verwendet, aber das wird glaube ich nicht mehr weiterentwickelt. Graphische Editoren wie z.B. kate verwende ich eigentlich nur in Spezialfällen. Für LaTeX verwende ich z.B. kile, da die Integration der Umgebung da sehr gut ist und okular auch als Betrachter gut integriert ist. kate oder kwrite nutze ich manchmal als "Notizblock".
Natürlich nutze ich -S (-r bisher nicht). head oder tail nutze ich im wesentlichen dazu um nur etwa 5 oder 10 dateien anzuzeigen, da ls meines Wissens keinen derartigen Parameter besitzt.
Wenn man diese Beschränkung auf die Anzahl der Dateien nicht will tut es natürlich auch ls -lS oder ls -lSr, das stimmt.
Von Software Entwickler am Fr, 1. Juni 2012 um 22:42 #
cat, less und nano für Textdateien.
Die nutze ich alle, je nach dem was ich vorhabe.
Nano nutze ich z.B., wenn ich suchen muss und dabei gleichzeitig nicht nur eine Zeile geliefert bekommen möchte. Da ist dann grep zu umständlich. Less nutze ich, wenn ich nur lesen möchte. Und cat, wenn die Dateien klein sind und ich auch gleich wieder auf der Konsole landen will, da sind nämlich sowohl less, more als auch nano ein Hindernis, die muss man nämlich erst beenden, bei cat kann man sich das sparen. Solange die Dateien auch klein genug sind, reicht auch PageUp/Down zum Blättern.
Wenn's keine Textdateien sind, dann benutze ich erstmal file.
Für binärdateien für die ich kein passendes Programm zum Darstellen habe, nutze ich bless, ein grafischer Hexeditor.
Den mc installiere ich auch immer als erstes nach, sofern er nicht zum Standardumfang der Distri gehört, und benutze ihn auch häufig im xterm.
Fast 25 Jahre Übung mit dem Norton Commander und seinen clones - nach so viel Gewöhnung weicht man nur widerwilig auf was anderes aus, bei dem man über die Bedienung nachdenken muss. Mc benutzen ist für mich wie Autofahren - die Bedienung erfolgt völlig unbewusst.
Aber cat, less, tail, grep usw. benutze ich schon gelegentlich. Für 'tail -f /var/log/messages' habe ich mir mal einen Einzeiler namens "tf" angelegt, um Tipparbeit zu sparen.
Ich habe selbst MC eine Zeit lang getestet. Konnte aber nicht mit ihm warm werden. Stattdessen greife ich mittlerweile häufig zu Ranger, einem Dateimanager dessen Steuerung stark von Vi inspiriert ist. Ranger kann im Gegensatz zu MC kein Fish und kein FTP, allerdings gefällt mir für beides lftp ohnehin besser.
Mir fehlt ein Programm 'open' das entsprechend konfiguriert werden kann jeden Dateityp mit einen entsprechenden Programm zu öffnen. Das wäre wirklich mal ein Fortschritt in meinen Augen.
Ich verwende 'edit; und 'see' aus dem Paket run-mailcap (siehe http://packages.debian.org/unstable/net/mime-support). Gesteuert wird dies über ~/.mailcap z.B. image/*; geeqie '%s'; edit=gimp --no-data --no-splash '%s'; test=test -n "$DISPLAY" image/*; asciiview '%s'; needsterminal audio/mpeg; mpg123 '%s'
Grund: vi ist auf JEDEM Unix-artigen Betriebssystem schon vorinstalliert. Sogar unter Windows kann man ihn bekommen.
Das ist besonders wichtig, wenn man auf verschiedenen (nicht unbedingt den eigenen) Rechnern arbeitet oder sich per ssh auf remote Systemen einloggt.
Die Bedienung von vi stammt natürlich aus einer anderen Zeit aber der Mensch ist ein Gewohnheitstier. Wenn man sich an vi gewöhnt hat, merkt man, dass es sich bei vi um ein mächtiges Werkzeug handelt, mit dem man sehr gut arbeiten kann.
Bei den vielen Editoren, die ich bereits verwendet habe stechen folgende Editoren für mich besonders hervor.
- vi(m)
- TDS bzw. Origami wegen der besten "Folding Editor"-Umsetzung http://wotug.org/parallel/vendors/inmos/archive-server/origami/origami.txt
- EDT / TPU wegen der besten Unterstützung von Makros http://www.stsci.edu/ftp/documents/system-docs/vms-guide/html/VUG_28.html
dito
An den kann ich mich nicht gewöhnen. Nur um mal einen Blick zu riskieren nehme ich cat & Co, als ernsthaften Editor nutze ich Vim.
Vim und htop sind die ersten Pakete, die ich auf einem frischen Debian nachinstalliere.
dito, fuer nano konnte ich mich noch nie begeistern. Vim und htop sind wirklich super programme
Danke für den tipp, htop kannte ich gar nicht! Ist ja ein tolles Tool!
Für's Dateien anschauen verwende ich je nach dem less, cat, oder watch tail.
also watch bei tail ist nicht wirklich notwendig, versuchs mal mit tail -f
Ich verwende auch cat für kleine Dateien und tail -f für log-Dateien (statt watch tail). Für große Dateien verwende ich less für ein schnelles kurzes Betrachten und vim für sonst, da ich mit vim besser an die gewünschten Stellen springen kann und eine Syntax-Einfärbung habe.
+1
Jo hier auch. vi oder emacs sind mir von der Bedienung einfach zu lernintensiv.
Bei kleinen Dateien nehme ich auch cat, oder zum Verfolgen von log-Dateien gerne "tail -f". Manches mache ich dann auch wieder mit MC - gerade wenn dieser ohnehin schon läuft.
Speziell beim Programmieren setze ich dann aber auf ne komplette IDE mit Auto-Vervollständigung - gibt ja wohl echt Leute, die Programme nur mit vi und gcc zusammenbasteln.
Das ist auch der Editor meiner Wahl.
Ist natürlich nicht so mächtig, wie vim oder emacs aber für meine Zwecke vollkommen ausreichend.
Ich habe zwar mal angefangen den vimtutor zu bearbeiten, aber als ich zum ersten mit vim wirklich eine config bearbeiten wollte artete das in eine Rumprobiererei aus, da ich mir mit den Kürzeln nicht mehr sicher war.
Leute die viel und oft in der Konsole arbeiten sind mit den Kürzeln sicherlich wesentlich effizienter als man es mit nano sein kann, aber für jemanden wie mich, der ab und an mal eine Datei bearbeitet fehlt es dann einfach an Übung um sich die ganzen Kürzel zu merken, da man sie ja nicht ständig benötigt.
Und für diese Zielgruppe ist nano wohl auch gedacht. Ich möchte ihn zumindest nicht missen.
Für größere Dateien wie Logs nehme ich meist less. Sollte die Datei klein sein, dann wähle ich cat. Wenn ich ein Diff zu einer anderen Datei brauche wird Vim genommen.
Wenn ich ein Diff zu einer anderen Datei brauche wird Vim genommen.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 02. Jun 2012 um 13:40.Für ein Diff ziehe ich meld vor. An sonsten sieht es bei mir ähnlich aus.
Wenn ich zu einen graphischen Diff-Werkzeug greife, dann nehme ich kdiff3. Trotz des Namens kommt es auch ohne KDE-Abhängigkeiten aus. Ich kann aber jetzt nicht sagen ob es besser oder schlechter als Meld ist. Ich bin bei kdiff3 einfach hängen geblieben weil es gut genug für mich ist.
Meistens benutze ich less, weil cat über Binärdaten die Konsole zerschießt. less zeigt bei mir auch PDFs, Docs und DEB-Pakete an :)
"most" ist ziemlich praktisch, weil es auch Hex bietet (jedoch nicht die obrigen Dokumente).
Und nano hilft schnell beim Sprung zu einer Zeile oder der Suche ohne erst Emacs etc. zu starten.
Dafür gibt's dann doch reset.
Insofern, wo ist das Problem?
Reset kann man blind tippen.
> Und nano hilft schnell beim Sprung zu einer Zeile oder der Suche ohne erst Emacs etc. zu starten.
Das geht doch auch mit less.
In Zeile 42 springen: 42g
Suchen: /suchbegriff
Weitersuchen: n
Ich benutze meine Augen.
...was ich genau vorhabe. Häufig verwende ich cat im Zusammenspiel mit less, wenn ich weiß dass die Datei viel Inhalt hat oder wenn ich mir nicht sicher bin. Wenn ich Sachen in Dateien Suche, um sie zu bearbeiten, verwende ich in der Regel sofort vim. Damit kann ich's ja dann auch gleich bearbeiten.
mc habe ich schon mehrfach ausprobiert, aber so richtig kann ich mich damit auch nicht anfreunden.
Wie kann man cat sinnvoll im Zusammenspiel mit less verwenden?
cat dateiname | grep suchmuster | less
Eine absolute Unsitte der man auch ständig in irgendwelchen Scripten begegnet. Was hat cat euch denn getan, dass es ständig unnötigerweise missbraucht wird?
cat datei | awk irgendwas -> awk irgendwas < datei
cat datei | grep irgendwas -> grep irgendwas datei
Vielleicht wird es als lesbarer erachtet die Datei zuerst zu schreiben.
Nur werden durch diese Art "lesbaren" Codes Shell-scripte schnarchlangsam.
Gerade mal in einem Verzeichnis mit 26 C-Dateien getestet.
# time for i in *.c; do cat $i|grep -q "for"; done
real 0m0.111s
user 0m0.019s
sys 0m0.095s
# time for i in *.c; do grep -q "for" $i; done
real 0m0.068s
user 0m0.012s
sys 0m0.040s
Skandalös, da muss der User ganze 0,05 Sek länger warten !
Du musstest noch nie wirklich grottenalte Shell-Scripts debuggen weil sie selbst auf modernster Hardware Ewigkeiten mit sich selbst gespielt haben, stimmts? Wenn du dir die Zeiten mal ansiehst wirst du erkennen, dass die Ausführungsgeschwindigkeit ohne *cat* fast halbiert wurde.
Das war ein aus der Hand geschütteltes Beispiel mit 26 Dateien. Du wirst es nicht glauben, es gibt Systeme mit wesentlich mehr Dateien und zig Loops welche mit solchen Pipe-Orgien den Sauerstoffgehalt der Erde reduzieren. Das wirst du jetzt nicht verstehen. Ist auch nicht schlimm. Es gibt ja Leute die das wieder in Ordnung bringen.
Kannst du auch machen:
grep foo bar
< bar grep foo
Ich bin kein Shell-Experte, aber es hat halt meines Wissens Nachteile. Zunächst einmal wird durch < nicht cat aufgerufen, sondern es handelt sich typischerweise um eine Shell-Funktion, wobei ich mir vorstellen könnte, dass manche Shells in so einem Fall auch cat aufrufen, wer weiß.
Dazu kommt, dass du wesentlich effizienter eine Dateiliste aufbauen. Kannst du mittels < prinzipiell auch, aber das wird tendenziell sehr sehr unübersichtlich.
Dennoch kann es sehr hilfreich sein, da du es mit einer Pipe kombinieren kannst, was bei der "normalen" Dateiübergabe typischerweise nicht möglich ist:
... foo |
Das würde die Ausgabe von ... foo sowie die Datei foo2 nach bar "greppen".
Ist sicher nicht der Standardfall, aber ich kann mir schon vorstellen, dass es in der einen oder anderen Situation nützlich sein kann.
Ok, jetzt hat es mir da das Beispiel verhauen. Sollte
... foo | < foo2 grep bar
sein
Da hast du wohl Recht. Aber wer kann sich schon merken, in welcher Reihenfolge die Parameter von grep stehen müssen.
Außerdem ist cat * | grep irgendwas schon ein Unterschied zu grep irgendetwas * . Da bräuchte man schon grep irgendetwas * | sed s/.*:// oder irgendeinen Parameter von grep, den man sich noch viel schwerer merken kann.
Ich sehe wenig Sinn drin, mir die Ausgaben von "rpm", "zypper" oder anderen Programmen in eine Datei schreiben zu lassen, wenn ich nur eine Sache daraus brauche, z.B. wenn ich ein Programm oder eine Datei suche. Da nehme ich less um bei recht einfachen Begriffen auch noch die Übersicht zu behalten. Klar, ich könnte den Puffer meines Terminals vergrößern, aber will ich das? less erfüllt hier seinen Zweck. Ich erachte es also keineswegs als Unsitte an.
Wenn du Performance willst, solltest du vielleicht kein Shellscript verwenden, sondern gleich auf C umsteigen. Die Zeit, die du damit sparst ist so gering, dass es sich nicht lohnt.
Wo stand etwas von der Unsitte *less* zu verwenden? Da stand etwas von *cat* als Paradebeispiel für die teilweise ausufernden Pipe-Orgien in Shell-Scripten. Und diese Pipe-Orgien zu beseitigen bzw. zu minimieren bringt durchaus schon mal Geschwindigkeitgewinne von 80-90%.
Auf C umzusteigen bringt in diesem Falle garnichts. Wer solche Shell-Scripte hinzaubert bekommt auch keine effizienten Programme in C gebacken.
Oh, da war ich mit dem Antworten wohl etwas voreilig. Dann nehme ich zurück was ich gesagt habe.
Heißt "grep" heutzutage nicht "ack"? (oder "ack-grep", je nach System)
So ähnlich geht es mir auch, auch wenn ich nicht cat im Zusammenspiel mit grep verwenden würde, aber dazu gibt es hier ja schon Kommentare.
Im Endeffekt kommt es einfach darauf an, was man mit den Dateien bzw. mit dem Stream anfangen will.
Wenn ich wirklich "nur" eine Datei betrachten will, dann nutze ich meistens vim und nicht cat o.ä. Grund ist hier einfach, dass vim für fast alle Arten von Dateien Syntax Highlighting bietet, oftmals wird die Ausgabe dadurch eben besser lesbar und zudem bietet vim eben auch bessere Methoden sich in der Ausgabe zu bewegen als eben cat (wobei es hier natürlich mittels screen auch Möglichkeiten gibt, wenn man das nutzt). cat selbst verwende ich nur, wenn ich weiß, dass die Datei nur wenige Zeilen enthält.
tail nutze ich eher, wenn ich die Änderungen einer Datei verfolgen will, also mittels -f. Z.B. bei Logdateien.
head nutze ich eigentlich fast nur im Zusammenhang mit ls, z.B. um die 10 größten Dateien in einem Verzeichnis anzuzeigen. Gut möglich, dass es hier einfachere Methoden gibt, aber so hab ich es mir eben angewöhnt. ;)
less kommt als Pager natürlich häufig zum Einsatz, insbesondere, wenn man Dateien vergleich, allerdings weiche ich hier sehr häufig auf vimpager (bei mir vip um es kurz zu halten) aus, wenn es sich nicht um einen stetigen Stream handelt (da vip erst anzeigt, wenn alle Daten vollständig angekommen sind, less zeigt es "on-the-fly" an). Grund ist auch hier wieder das Syntax Highlighting von vim. Zeitweise hatte ich auch als Pager das Programm most verwendet, aber das wird glaube ich nicht mehr weiterentwickelt.
Graphische Editoren wie z.B. kate verwende ich eigentlich nur in Spezialfällen. Für LaTeX verwende ich z.B. kile, da die Integration der Umgebung da sehr gut ist und okular auch als Betrachter gut integriert ist. kate oder kwrite nutze ich manchmal als "Notizblock".
hast mal "ls -lSr" versucht (wegen größte dateien anzeigen)?
Natürlich nutze ich -S (-r bisher nicht). head oder tail nutze ich im wesentlichen dazu um nur etwa 5 oder 10 dateien anzuzeigen, da ls meines Wissens keinen derartigen Parameter besitzt.
Wenn man diese Beschränkung auf die Anzahl der Dateien nicht will tut es natürlich auch ls -lS oder ls -lSr, das stimmt.
cat, less und nano für Textdateien.
Die nutze ich alle, je nach dem was ich vorhabe.
Nano nutze ich z.B., wenn ich suchen muss und dabei gleichzeitig nicht nur eine Zeile geliefert bekommen möchte.
Da ist dann grep zu umständlich.
Less nutze ich, wenn ich nur lesen möchte.
Und cat, wenn die Dateien klein sind und ich auch gleich wieder auf der Konsole landen will, da sind nämlich sowohl less, more als auch nano ein Hindernis, die muss man nämlich erst beenden, bei cat kann man sich das sparen.
Solange die Dateien auch klein genug sind, reicht auch PageUp/Down zum Blättern.
Wenn's keine Textdateien sind, dann benutze ich erstmal file.
Für binärdateien für die ich kein passendes Programm zum Darstellen habe, nutze ich bless, ein grafischer Hexeditor.
Als Standard-Tool nehme ich mc/mcedit, ansonsten less, cat und nano. Die erschlagen bei mir gefühlte 98% der denkbaren Szenarien.
Den mc installiere ich auch immer als erstes nach, sofern er nicht zum Standardumfang der Distri gehört, und benutze ihn auch häufig im xterm.
Fast 25 Jahre Übung mit dem Norton Commander und seinen clones - nach so viel Gewöhnung weicht man nur widerwilig auf was anderes aus, bei dem man über die Bedienung nachdenken muss. Mc benutzen ist für mich wie Autofahren - die Bedienung erfolgt völlig unbewusst.
Aber cat, less, tail, grep usw. benutze ich schon gelegentlich. Für 'tail -f /var/log/messages' habe ich mir mal einen Einzeiler namens "tf" angelegt, um Tipparbeit zu sparen.
Ich habe selbst MC eine Zeit lang getestet. Konnte aber nicht mit ihm warm werden. Stattdessen greife ich mittlerweile häufig zu Ranger, einem Dateimanager dessen Steuerung stark von Vi inspiriert ist. Ranger kann im Gegensatz zu MC kein Fish und kein FTP, allerdings gefällt mir für beides lftp ohnehin besser.
Mir fehlt ein Programm 'open' das entsprechend konfiguriert werden kann jeden Dateityp mit einen entsprechenden Programm zu öffnen. Das wäre wirklich mal ein Fortschritt in meinen Augen.
schon mal was von less gehört? Das in Verbindung mit $LESSOPEN -> /usr/bin/lessopen.sh tut ganz genau das.
Ich verwende 'edit; und 'see' aus dem Paket run-mailcap (siehe http://packages.debian.org/unstable/net/mime-support). Gesteuert wird dies über ~/.mailcap
z.B.
image/*; geeqie '%s'; edit=gimp --no-data --no-splash '%s'; test=test -n "$DISPLAY"
image/*; asciiview '%s'; needsterminal
audio/mpeg; mpg123 '%s'
> das entsprechend konfiguriert werden kann jeden
> Dateityp mit einen entsprechenden Programm zu öffnen.
Das wäre doch eine schöne Möglichkeit den Einstieg in die Programmierung zu bekommen.
Die Problemstellung sollte einfach genug sein.
Versuch es mit einer Scriptsprache oder wenn Du später mehr programmieren möchtest mit C.
Gibt es und heißt xdg-open.
Als Editor in der konsole benutze ich vi.
Grund: vi ist auf JEDEM Unix-artigen Betriebssystem schon vorinstalliert.
Sogar unter Windows kann man ihn bekommen.
Das ist besonders wichtig, wenn man auf verschiedenen (nicht unbedingt den eigenen) Rechnern arbeitet oder sich per ssh auf remote Systemen einloggt.
Die Bedienung von vi stammt natürlich aus einer anderen Zeit aber
der Mensch ist ein Gewohnheitstier.
Wenn man sich an vi gewöhnt hat, merkt man, dass es sich bei vi um ein mächtiges Werkzeug handelt, mit dem man sehr gut arbeiten kann.
Bei den vielen Editoren, die ich bereits verwendet habe stechen folgende Editoren für mich besonders hervor.
- vi(m)
- TDS bzw. Origami wegen der besten "Folding Editor"-Umsetzung
http://wotug.org/parallel/vendors/inmos/archive-server/origami/origami.txt
- EDT / TPU wegen der besten Unterstützung von Makros
http://www.stsci.edu/ftp/documents/system-docs/vms-guide/html/VUG_28.html
Da fehlt doch less.
Was nutzt es mir, wenn ich eine Datei catten kann...
tail ist für logfiles.
Konfig-Dateien sind offengestanden wegen des syntax-highlichts mit vi/vim besser anzusehen.
... aber die Antwort gibt es nicht...
Mal ein grep, mal ein cat, mal ein more, mal ein tail, mal ein Editor... kommt doch darauf an...
Gute Frage, schlechte Anwortmöglichkeiten...
Ciao