@Wolfgang Du willst den Shell-Workshop jetzt wohl zu deiner Lebensaufgabe ausbauen? Dann schliess dich wenigstends gleich mit O'Reilly oder Addison kurz, das sie das ganze als Buch rausbringen (immerhin sollte deine Mühe mit klingender Münze z.B. für einen schönen Australienurlaub belohnt werden) ;)
Ich finde find, xargs und Co mächtig prächtig und prächtig mächtig!
Wenn ich mehrere Dateien einer gleichartigen Behandlung unterziehen möchte, dann baue ich mit Befehlen, die letztlich nur als Ausgabe erzeugen, was ich zu tun gedenke erstmal etwas zusammen, was ich nochmal prüflesen kann.
Hierzu eignet sich zB find mit -printf hervorzüglichst! Ab und zu stolpere ich dabei dann z.B. darüber, daß ich mal wieder vergaß, daß Filenamen mit "üblen Zeichen" drin Probleme machen, aber es ist ja nichts Schlimmes passiert, ich hab ja nur eine Ausgabe erzeugt und noch nix laufen lassen...
Wenn mir der Output des "Probelaufes" zusagt, wird er je nach Struktur dann in "xargs entgültiges_kommando" oder "bash" hineingepiped...
So entstehen "inkrementell-interaktiv" und auf eine für die Nerven eines Hasenfußes brauchbare Art recht komplexe Commandlines...
Und wenn ich sowas dann doch lieber von einer einzigen Commandline in ein Skript jagen will, dann wird halt das Ende der History in 'ne Datei gejagt und nachbearbeitet.
Und wenn's mal ganz komplex wird und ich in so einem Einzeiler auch noch Kommentare brauche, um den Überblick zu behalten, dann kommt mein BASH-Lieblingskonstrukt zum Einsatz: $(# kommentar)
Also: HCuSP ist bestens geeignet, wenn's mal komplexer wird *und* schnell gehen muss, aber man nicht zuviel riskieren mag *und* zum Beschleunigen des Skripte-Schreibens...
Vielleicht ein lohnendes Thema für einen Kurztipp? ...aber Zeit ist meine knappste Ressource, zumindest in den nächsten 3-4 Wochen...
Ich hoffe du hast nicht den screenshot selber gemacht und es als gif abgespeichert. Es gibt jpg und png, wieso da gif verwenden :) ( /work/shell/jpgs/bild1.gif ) Ansonsten freu ich mich schon auf die nächsten Teile deines Artikels...
Zunächst einmal ist das GIF-Format an sich nicht patentverseucht, nur der bekannteste (aber nicht einzige) Kompressionsalgorithmus dafür. Und solange zum Erstellen ausschließlich Freie Software verwendet wurde, wie es hier der Fall war, sehe ich wenig Gründe für ein schlechtes Gewissen. Das GIF-Bild hat eine einfache Ursache: Den Artikel hatte ich ursprünglich für etwas geschrieben, wo ich gezwungen war, GIF zu verwenden. Seitdem ist es halt in dem Format geblieben.
Wenn ich mich recht erinnere war aber eben dieser am häufigsten gebräuchliche Algo nicht Kostenlos und dürfte garnicht in Open Source Software vorkommen. Ich habe mal gehört die Lizenz k9ostet so um die 25000$.
Ja, das ist richtig. Aber was macht das? Nicht nur, dass man andere Kompressionsmethoden verwenden kann, man kann auch Freie Software verwenden, in der das patentierte Verfahren implementiertn ist, obwohl es das nicht sein dürfte. Bei nichts von beidem hätte ich ein schlechtes Gewissen. ;-)
ich hatte das posting als dezenten Hinweis gedacht keine gifs zu verwenden, da mir Wolfgang als einer erscheint, der darauf achtet.(Im Gegensatz zu PL ;P ) Siehe http://www.gnu.org/philosophy/gif.html ab dem Abschnitt wo gesagt wird, das sie (nicht patent behaftene) gifs benutzt _hatten_.
Nichts für ungut schliessen wir das Thema hier ab. $ apt-cache search gif2png gif2png - GIF -> PNG conversions $
Ja, ich bevorzuge normal auch andere Formate (auf meiner eigenen Homepage habe ich ausschließlich jpeg benutzt). Da es halt schon als GIF vorlag, hatte ich es einfach beibehalten, weil ja genau genommen das Format an sich nicht problematisch ist, nur der LZW-Algorithmus. Wenn Frontpage einen patentierten Algorithmus in JavaScript in Webseiten eincodieren würde, wäre das für mich auch kein Grund, auf HTML zu verzichten ;-). Im zweiten Teil sind auch zwei GIFs drin und der liegt schon bei HJB. In folgenden Teilen werde ich PNG verwenden.
Aber biete zu jedem PNG auch ein Link auf ein JPG. Dann gibt es keine Probleme mit Netscape 4 User.
Das zeigt diesen Browser Dinos das ihr Browser echt mackig ist ("Hey, warum sieht das BIld so doof aus?"), auf der anderen Seite werden sie aber dafür nicht bestaft, manche haben ja auch garnicht die Wahl.
nicht uebel. Wenn jmd. die haeufigsten Linuxbefehle und dessen Funktionen erklaert haben will kann ich Linux in a Nutshell (Oreilly) empfehlen. Es enthaelt auch Buildin Dinge zu bash,csh,tcsh. vi commands, rpm, dpkg uvm.
Mit der Veröffentlichung des Shell-Workshops hättet Ihr auch noch etwas warten können, bis einiges mehr zusammengetragen wurde. Ich fände aber beim Thema Workshop eine Beispielsammlung ohne viel Text sinnvoller. Jeder könnte einige interessante Kommandos dazu beitragen oder allgemeine Konzepte, die im Workshop noch nicht beschrieben wurden, beisteuern, oder Skripts die einiges zustande bringen...
Du weißt doch gar nicht, wie umfangreich der Workshop werden soll. ;)
Cheers,
GNU/Wolfgang
Du willst den Shell-Workshop jetzt wohl zu deiner Lebensaufgabe ausbauen? Dann schliess dich wenigstends gleich mit O'Reilly oder Addison kurz, das sie das ganze als Buch rausbringen (immerhin sollte deine Mühe mit klingender Münze z.B. für einen schönen Australienurlaub belohnt werden) ;)
shell[tm] :))
Wenn ich mehrere Dateien einer gleichartigen Behandlung unterziehen möchte, dann baue ich mit Befehlen, die letztlich nur als Ausgabe erzeugen, was ich zu tun gedenke erstmal etwas zusammen, was ich nochmal prüflesen kann.
Hierzu eignet sich zB find mit -printf hervorzüglichst! Ab und zu stolpere ich dabei dann z.B. darüber, daß ich mal wieder vergaß, daß Filenamen mit "üblen Zeichen" drin Probleme machen, aber es ist ja nichts Schlimmes passiert, ich hab ja nur eine Ausgabe erzeugt und noch nix laufen lassen...
Wenn mir der Output des "Probelaufes" zusagt, wird er je nach Struktur dann in "xargs entgültiges_kommando" oder "bash" hineingepiped...
So entstehen "inkrementell-interaktiv" und auf eine für die Nerven eines Hasenfußes brauchbare Art recht komplexe Commandlines...
Und wenn ich sowas dann doch lieber von einer einzigen Commandline in ein Skript jagen will, dann wird halt das Ende der History in 'ne Datei gejagt und nachbearbeitet.
Und wenn's mal ganz komplex wird und ich in so einem Einzeiler auch noch Kommentare brauche, um den Überblick zu behalten, dann kommt mein BASH-Lieblingskonstrukt zum Einsatz: $(# kommentar)
Also: HCuSP ist bestens geeignet, wenn's mal komplexer wird *und* schnell gehen muss, aber man nicht zuviel riskieren mag *und* zum Beschleunigen des Skripte-Schreibens...
Vielleicht ein lohnendes Thema für einen Kurztipp? ...aber Zeit ist meine knappste Ressource, zumindest in den nächsten 3-4 Wochen...
Ich hoffe du hast nicht den screenshot selber gemacht und es als gif abgespeichert.
Es gibt jpg und png, wieso da gif verwenden :)
( /work/shell/jpgs/bild1.gif )
Ansonsten freu ich mich schon auf die nächsten Teile deines Artikels...
Zunächst einmal ist das GIF-Format an sich nicht patentverseucht, nur der bekannteste (aber nicht einzige) Kompressionsalgorithmus dafür. Und solange zum Erstellen ausschließlich Freie Software verwendet wurde, wie es hier der Fall war, sehe ich wenig Gründe für ein schlechtes Gewissen. Das GIF-Bild hat eine einfache Ursache: Den Artikel hatte ich ursprünglich für etwas geschrieben, wo ich gezwungen war, GIF zu verwenden. Seitdem ist es halt in dem Format geblieben.
Cheers,
GNU/Wolfgang
Wenn ich mich recht erinnere war aber eben dieser am häufigsten gebräuchliche Algo nicht Kostenlos und dürfte garnicht in Open Source Software vorkommen.
Ich habe mal gehört die Lizenz k9ostet so um die 25000$.
Ja, das ist richtig. Aber was macht das? Nicht nur, dass man andere Kompressionsmethoden verwenden kann, man kann auch Freie Software verwenden, in der das patentierte Verfahren implementiertn ist, obwohl es das nicht sein dürfte. Bei nichts von beidem hätte ich ein schlechtes Gewissen. ;-)
Cheers,
GNU/Wolfgang
Ich eigentlich schon.
Und vor allem da es Alternativen in Form von JPG und PNG gibt.
Wie ich zu GIF stehe hat ja mein Kylix bericht gezeigt
ich hatte das posting als dezenten Hinweis gedacht keine gifs zu verwenden, da mir Wolfgang als einer erscheint, der darauf achtet.(Im Gegensatz zu PL ;P )
Siehe http://www.gnu.org/philosophy/gif.html ab dem Abschnitt wo gesagt wird, das sie (nicht patent behaftene) gifs benutzt _hatten_.
Nichts für ungut schliessen wir das Thema hier ab.
$ apt-cache search gif2png
gif2png - GIF -> PNG conversions
$
Ja, ich bevorzuge normal auch andere Formate (auf meiner eigenen Homepage habe ich ausschließlich jpeg benutzt). Da es halt schon als GIF vorlag, hatte ich es einfach beibehalten, weil ja genau genommen das Format an sich nicht problematisch ist, nur der LZW-Algorithmus. Wenn Frontpage einen patentierten Algorithmus in JavaScript in Webseiten eincodieren würde, wäre das für mich auch kein Grund, auf HTML zu verzichten ;-). Im zweiten Teil sind auch zwei GIFs drin und der liegt schon bei HJB. In folgenden Teilen werde ich PNG verwenden.
Cheers,
GNU/Wolfgang
Aber biete zu jedem PNG auch ein Link auf ein JPG. Dann gibt es keine Probleme mit Netscape 4 User.
Das zeigt diesen Browser Dinos das ihr Browser echt mackig ist ("Hey, warum sieht das BIld so doof aus?"), auf der anderen Seite werden sie aber dafür nicht bestaft, manche haben ja auch garnicht die Wahl.
nicht uebel. Wenn jmd. die haeufigsten Linuxbefehle und dessen Funktionen erklaert haben will kann ich Linux in a Nutshell (Oreilly) empfehlen. Es enthaelt auch Buildin Dinge zu bash,csh,tcsh. vi commands, rpm, dpkg uvm.
Michael