Login
Newsletter

Thema: Was ist ihr Standardwerkzeug zur Dateibetrachtung auf der Konsole?

47 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von lucas am Fr, 1. Juni 2012 um 15:16 #

:up:

  • 0
    Von glasen am Fr, 1. Juni 2012 um 15:26 #

    dito ;-)

    0
    Von inta am Fr, 1. Juni 2012 um 15:41 #

    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. :)

    0
    Von Nasenbaer am Fr, 1. Juni 2012 um 19:04 #

    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. :D

    0
    Von mdosch am Sa, 2. Juni 2012 um 17:55 #

    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.

0
Von Unerkannt am Fr, 1. Juni 2012 um 15:35 #

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.

  • 0
    Von jjsa am Sa, 2. Juni 2012 um 13:39 #

    Wenn ich ein Diff zu einer anderen Datei brauche wird Vim genommen.
    Für ein Diff ziehe ich meld vor. An sonsten sieht es bei mir ähnlich aus.

    Dieser Beitrag wurde 1 mal editiert. Zuletzt am 02. Jun 2012 um 13:40.
    • 0
      Von Unerkannt am Sa, 2. Juni 2012 um 14:27 #

      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.

0
Von Kai am Fr, 1. Juni 2012 um 15:40 #

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.

1
Von erwin mepurzke am Fr, 1. Juni 2012 um 15:48 #

Ich benutze meine Augen.

0
Von christianw am Fr, 1. Juni 2012 um 17:07 #

...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.

  • 0
    Von tntnet am Fr, 1. Juni 2012 um 19:41 #

    Wie kann man cat sinnvoll im Zusammenspiel mit less verwenden?

    • 0
      Von dertisch17 am Fr, 1. Juni 2012 um 20:24 #

      cat dateiname | grep suchmuster | less

      • 1
        Von Rettet cat am Fr, 1. Juni 2012 um 21:19 #

        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

        • 0
          Von Lesbarer Code am Fr, 1. Juni 2012 um 22:03 #

          Vielleicht wird es als lesbarer erachtet die Datei zuerst zu schreiben.

          • 1
            Von Tendenz Rot am Fr, 1. Juni 2012 um 22:15 #

            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

            • 0
              Von Andre am Sa, 2. Juni 2012 um 00:10 #

              Skandalös, da muss der User ganze 0,05 Sek länger warten !

              • 0
                Von Tendenz Rot am Sa, 2. Juni 2012 um 00:36 #

                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.

            0
            Von blubb am Sa, 2. Juni 2012 um 09:58 #

            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. ;)

          0
          Von dertisch17 am Fr, 1. Juni 2012 um 22:06 #

          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.

          1
          Von christianw am Sa, 2. Juni 2012 um 00:34 #

          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.

          • 0
            Von Rettet cat am Sa, 2. Juni 2012 um 20:43 #

            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.

        0
        Von gserger am Sa, 2. Juni 2012 um 17:06 #

        Heißt "grep" heutzutage nicht "ack"? (oder "ack-grep", je nach System)

    0
    Von blubb am Sa, 2. Juni 2012 um 09:50 #

    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".

    • 0
      Von Alan Smithee am Sa, 2. Juni 2012 um 14:15 #

      hast mal "ls -lSr" versucht (wegen größte dateien anzeigen)?

      • 0
        Von blubb am Sa, 2. Juni 2012 um 19:00 #

        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.

0
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.

0
Von weichwurst am Sa, 2. Juni 2012 um 06:53 #

Als Standard-Tool nehme ich mc/mcedit, ansonsten less, cat und nano. Die erschlagen bei mir gefühlte 98% der denkbaren Szenarien.

  • 0
    Von Anonymous am Sa, 2. Juni 2012 um 10:09 #

    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.

    • 0
      Von Unerkannt am Sa, 2. Juni 2012 um 14:32 #

      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.

0
Von Ravenbird am Sa, 2. Juni 2012 um 08:29 #

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.

1
Von pvb am So, 3. Juni 2012 um 08:46 #

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

1
Von cornelinux am So, 3. Juni 2012 um 19:31 #

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.

0
Von Martiniclan am Mo, 4. Juni 2012 um 11:37 #

... 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

Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten