Ich musste als erstes lernen, dass manpages das A und O sind, wenn man mit Linux/Unix vernünftig arbeiten will. Unter Windows 95 konnte man die mitgelieferte Hilfe getrost vergessen. Heute ist die manpage meist meine erste Anlaufstelle.
Nicht nur zu den einfachen Shell-Werkzeugen, sondern auch zu System-Calls oder Bibliotheksfunktionen..
Unter Windows 95 konnte man die mitgelieferte Hilfe getrost vergessen.
Dafür gabs' doch im Supermarkt die zeitschriften mit den 100 besten hochgeheimen Windows-Tricks.
Hat sich auch wenig dran geändert. Ich muss mich manchmal noch mit Windows rumärgern, und wenn man auf einer Windows7-Kiste die vielen unnötigen Dienste abschalten will, um den Angriffsvektor zu verkleinern (das erspart das Antivirus-Programm), kann man die Hilfefunktionen getrost vergessen; da kauft man dann wieder eine PC-Zeitschrift mit 100 hochgeheimem Tricks....
Ich musste als erstes lernen, dass manpages das A und O sind, wenn man mit Linux/Unix vernünftig arbeiten will.
Ja, wenn man das Programm schon kennt. Ich für meinen Teil hab's noch nicht geschafft, mich nur anhand der Manpage in ein Programm einzuarbeiten (Ausnahme: hwclock), dazu sind die einfach zu schlecht bzw. abstrakt geschrieben. Gerade die Manpage von less ist ein schönes Beispiel (wenn nicht das schönste): Wissenschaftlich korrekt geschrieben, aber selbst wenn man sich in diese abstrakte wissenschaftliche Schreibweise hineindenken kann, muss man die Manpage ggf. mehrmals lesen, damit man sie versteht. Das sind Unzugänglichkeiten, die in einer Manpage -- welche ja eigentlich dazu da sind, dass man sich als Benutzer durch ihre Hilfe selbst einarbeiten kann -- nichts verloren haben.
Von Idiotenpfleger am So, 13. Oktober 2013 um 15:05 #
so ist es. Manpages sind außerdem völlig unverständlich geschrieben ("--help" ebenso) und decken nur irgendwelche unnormalen Use-cases ab, dass man sich die Mühe sparen kann, sie zu lesen. Das Ganze hat was von der "Hilfe" in Windows. Wird aber von irgendwelchen Freetards als das Ultimative und Killerfeature Nummer eins in den Himmel gelobt.
Außerdem kann man aus Google etc. meist gleich die fertigen Befehle kopieren. Warum? Weil ich als normaler User überhaupt keine Lust habe, erst stundenlang irgendwelche Befehlsmasturbation zu lesen, sondern einfach nur mein Ziel erreichen will.
Verstehe das Problem nicht, genau das verrät dir die Hilfe doch. Kenne nur wenige Fälle, in denen --help keine Erklärung liefert.
Siehe wget:
$ wget wget: URL fehlt Syntax: wget [OPTION]... [URL]... »wget --help« gibt weitere Informationen.
$ wget --help GNU Wget 1.12, ein nicht-interaktives Netz-Werkzeug zum Download von Dateien. Syntax: wget [OPTION]... [URL]... Erforderliche Argumente zu langen Optionen sind auch bei kurzen Optionen erforderlich. Beim Start: -V, --version Programmversion anzeigen und beenden -h, --help diese Hilfe anzeigen [..snip]
Es klingt bei dir, als ob man hier vor einem großen Problem steht. Aber wo soll das sein?
Es klingt bei dir, als ob man hier vor einem großen Problem steht.
Ich stehe vor keinem Problem sondern stelle nur fest, dass man $cmd oft schneller zum Ziel führt als das Erraten des helf-Flags, welches ev. gar nicht existiert.
Das man --help oder "man befehl" aufruft, wenn man eine bestimmte Kommandozeilenoption nicht weiß, ist doch klar. Eine Suche mit der Suchmaschine würde dafür viel zu lange dauern.
Viel interessanter wäre daher die Frage, was ihr tut, wenn ihr ein Problem per kleines Shellscript lösen wollt, das nicht nur aus einem einzigen Kommandozeilenbefehl besteht, sondern Pipes bis hin zu komplexeren Formen durch Scripte nutzt? Was macht ihr dann?
Versucht ihr dann das Problem durch studieren von man Pages und --help Ausgaben irgendwie zu lösen oder schaut ihr erstmal im Internet mit einer Suchmaschine nach einem Eintrag von jemandem, der schon ein ähnliches Problem hatte und dafür er oder andere eine fertige Lösung gepostet haben? Oder geht ihr sogar so weit und fragt andere User im Internet um Hilfe?
was ihr tut, wenn ihr ein Problem per kleines Shellscript lösen wollt, das nicht nur aus einem einzigen Kommandozeilenbefehl besteht, sondern Pipes bis hin zu komplexeren Formen durch Scripte nutzt? Was macht ihr dann?
Ich frage mich zuerst, ob es wirklich, wirklich, wirklich nötig ist ein Skript zu schreiben. Ein Skript ist schnell mal gekritzelt aber ebenso schnell wieder vergessen.. dann geschieht nach einer Weile folgendes: Keiner merkt, dass Fehler X durch Skript Y behindert wird oder warum Skript Y genau Fehler X verursacht bzw. begünstigt. Anschliessend fragen sich alle, warum Skript Y überhaupt geschrieben wurde und/oder wer Skript Y in Zukunft warten soll (der ursprüngliche Autor arbeitet leider nicht mehr hier).
Wenn das Skript trotzdem sein muss:
Alles in Funktionen packen, wobei main() den Anfang sowie getopts macht. Das restliche Ausprogrammieren sollte die gewöhnlichen Programmierstandards nicht unterschreiten.
Anschliessend fragen sich alle, warum Skript Y überhaupt geschrieben wurde
Also ich schreibe immer in der Scriptdatei ganz oben hin, wofür das Script da ist. Ansonsten nutze ich aussagekräftige Dateinamen.
Aber wie sieht es denn für geringfügig komplexere Kommandos aus? Schon wenn die nur aus drei Befehle mit ein paar Optionen bestehen kann das schon recht komplex werden, dafür schreibt man trotzdem noch kein Script, aber man braucht es und ein bloßer Nachschlag in die man pages, welche Optionen es denn so gibt, reicht dann oft auch nicht mehr aus. Hier muss man das ganze quasi aus einem Baukasten dann zu einem Ganzen zusammenfügen können.
Die meisten manpages sind als reine Beschreibung aller vorhandenen Optionen eines Befehls gestaltet.
Leider gibt es nur wenige manpages, die am Ende der umfangreichen Beschreibung auch mal ein paar Beispiele anführen. In vielen Fällen würde das reichen und man müsste sich nicht mühsam durch das komplette Dokument quälen.
Ich habe mir daher wie der Kollege weiter oben angewöhnt, solche Sachen, die ich mühsam aus den manpages herausgepopelt habe, in (m)eine eigene FAQ-Datei zu schreiben.
Da man pages auch zu den Open Source Projekten gehören, könntest du aber auch mal die man pages erweitern. Denn wenn jeder seine eigene FAQ macht, was sicher irgendwo auch seine Berechtigung hat, mahen viele diese Arbeit dennoch unnötig redundant.
Das sehe ich nicht so. Ich brauche als "FAQ" kein Kompendium aller möglichen Funktionen, die ein Tool leisten kann. Im Gegenteil, das ist ein lebendes Dokument, das heißt von mir nicht mehr benötigte Informationen fliegen dort auch wieder raus. Ich sehe da keine unnötige Redundanz darin, sondern eher eine Art Cache, für Informationen die ich aus Man-Pages extrahiert habe ;)
Die Redundanz ist die, dass andere sich die gleiche Arbeit machen. Bei n Usern, also n FAQs.
Das sehe ich nicht so. Ich brauche als "FAQ" kein Kompendium aller möglichen Funktionen,
Gerade dann, wenn du nur Kleinigkeiten ab und zu in deine FAQ schreibst, bietet sich sich an, bestehende man Pages um Kleinigkeiten zu erweitern. Es sagt ja niemand, dass du alle man pages von vorne an neu schreiben sollst. Es geh darum, etwas zu Ergänzen, wenn man meint das es fehlt und wenn es für eine man page sinnvoll ist.
Mich wundert sowieso, warum noch niemand die man pages auf eine Wiki gepackt hat und zukünftige man page Versionen dann aus den Wikieinträgen generiert werden. Das würde die Entwicklung sicherlich stark beschleunigen.
Ich weiß, was du mit Redundanz meinst. Worauf ich hinaus will, ist dass diese Redundanz in einem persönlichen FAQ nicht unnötig ist, sondern durchaus ihren Zweck erfüllt. Wenn auch nur für den Autor.
Es geh darum, etwas zu Ergänzen, wenn man meint das es fehlt und wenn es für eine man page sinnvoll ist.
Da kann man nur zustimmen. Manchmal fehlt die Information im Manual nicht wirklich, sie ist implizit vorhanden, der Leser wird nur nicht direkt mit der Nase darauf gestoßen, wie durch ein konkretes Beispiel. Man muss abwägen, wie relevant die eigenen Anwendungsfälle für Andere sind. Die gleichen Maßstäbe legst du letzten Endes auch für einen Wiki Artikel an.
Ich finde, hier kann so eine FAQ sogar helfen die Relevanz besser einzustufen. Nämlich gemessen daran, wie lange eine Information in der FAQ bleibt.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 14. Okt 2013 um 19:14.
Ich finde, hier kann so eine FAQ sogar helfen die Relevanz besser einzustufen. Nämlich gemessen daran, wie lange eine Information in der FAQ bleibt.
Ein wichtiger Befehl mit entsprechenden Optionsparametern, den man häufig benutzt, weil er wichtig ist, lernt man irgendwann durch häufige Benutzung auswendig, dann fliegt er aus der FAQ obwohl er für Anfänger weiterhin wichtig sein wird.
Die Dauer wie lange etwas in einer FAQ ist, ist somit meiner Meinung nach kein Kriterium für dessen Relevanz. In einer FAQ würden bei mir so nur noch Spezialfälle übrig bleiben, die man nur ganz selten benötigt und so etwas gehört dann doch nicht in eine man page, da es zu speziell ist.
Daher hätte ich einen anderen Vorschlag. Die Linux Communityseitenabklappern und schauen, nach welchen Shellbefehlen und Kommandooptionen am häufigsten gefragt wird und wenn das dann nicht in den man pages als Beispiel drin steht, dann gehört es rein, weil es offensichtlich für viele Relevanz hat.
Sicher kann man Skripte auch irgendwie zusammenklicken, jedoch kann ja gerade in Schriftform ein Problem exakt und reproduzierbar ausgedrückt werden. Ja, Piktogramme und Pfeile weisen den Weg zum Ausgang oder zum Klo, aber sie können niemals einen komplexen Sachverhalt ausdrücken. Manchmal ist das aber im Gegensatz zu aller Microsoft Propaganda notwendig z.B. eine kuschlige Umgebung für ein Programm zu schaffen und es mit anderen zur Zusammenarbeit zu bewegen. Und dann bin ich froh, daß es Shell Skripte gibt (und daß ich mir damals die Zeit genommen habe, es zu lernen)
Mit info habe ich mich nie richtig angefreundet. Die Umfrage hier ist sicher nicht repräsentativ für alle Nutzer, aber das scheint ja auch anderen so zu gehen (derzeit 0% bei 80 Stimmen), woran liegt das eigentlich?
Ich persönlich habe nie gelernt in dem Tool zu navigieren und die Informationen dann auf anderem Weg auch gefunden, also war es für mich unnötig.
Wenn ich dann wirklich mal auf die Shell muss und einen Parameter nicht weiß, dann starte ich Befehl -h . Zum Glück ist das zwischenzeitlich aber recht selten der Fall. Viele Programme auf dem GUI setzen doch häufig beim Aufruf von Shell-Programmen die korrekten Schalter und Parameter
... und ich wage zu behaupten dass ein Linux- / unixoid-User der keine manpages liest auch kein User ist.
Ich musste als erstes lernen, dass manpages das A und O sind, wenn man mit Linux/Unix vernünftig arbeiten will. Unter Windows 95 konnte man die mitgelieferte Hilfe getrost vergessen.
Heute ist die manpage meist meine erste Anlaufstelle.
Nicht nur zu den einfachen Shell-Werkzeugen, sondern auch zu System-Calls oder Bibliotheksfunktionen..
Ich lese keine Manpages, ich finde den Begriff zu sexistisch.
Ich benutze auch keine Befehle, ich bin gegen Militarismus.
Du schubst bestimmt auch keine Maus, weil du Tierfreund bist?
Besteht die Alternative dann im sanften Streicheln per Touchscreen oder ist das schon sexuelle Belästigung?
$> man woman
Segmentation fault (core dumped)
BTW: Es gibt natürlich auch eine weibliche Form des Befehls für die Womanpages ;P
Seit dem ich so eine Fernbedienung habe, muss ich keine man pages mehr lesen, ein Knopfdruck genügt und das Problem wird gelöst:
http://www.caddywampusstore.com/media/catalog/product/cache/1/image/9df78eab33525d08d6e5fb8d27136e95/W/4/W4342.jpg
um die Manpages zu betrachten.
Unter Windows 95 konnte man die mitgelieferte Hilfe getrost vergessen.
Dafür gabs' doch im Supermarkt die zeitschriften mit den 100 besten hochgeheimen Windows-Tricks.
Hat sich auch wenig dran geändert. Ich muss mich manchmal noch mit Windows rumärgern, und wenn man auf einer Windows7-Kiste die vielen unnötigen Dienste abschalten will, um den Angriffsvektor zu verkleinern (das erspart das Antivirus-Programm), kann man die Hilfefunktionen getrost vergessen; da kauft man dann wieder eine PC-Zeitschrift mit 100 hochgeheimem Tricks....
Ja, wenn man das Programm schon kennt. Ich für meinen Teil hab's noch nicht geschafft, mich nur anhand der Manpage in ein Programm einzuarbeiten (Ausnahme: hwclock), dazu sind die einfach zu schlecht bzw. abstrakt geschrieben. Gerade die Manpage von less ist ein schönes Beispiel (wenn nicht das schönste): Wissenschaftlich korrekt geschrieben, aber selbst wenn man sich in diese abstrakte wissenschaftliche Schreibweise hineindenken kann, muss man die Manpage ggf. mehrmals lesen, damit man sie versteht. Das sind Unzugänglichkeiten, die in einer Manpage -- welche ja eigentlich dazu da sind, dass man sich als Benutzer durch ihre Hilfe selbst einarbeiten kann -- nichts verloren haben.
Grueße
Ignatz
user nicht aber admin ;o)
Herr Google hat meist umfangreichere und weiterführende Bleistfifte als Manpages.
so ist es. Manpages sind außerdem völlig unverständlich geschrieben ("--help" ebenso) und decken nur irgendwelche unnormalen Use-cases ab, dass man sich die Mühe sparen kann, sie zu lesen. Das Ganze hat was von der "Hilfe" in Windows. Wird aber von irgendwelchen Freetards als das Ultimative und Killerfeature Nummer eins in den Himmel gelobt.
Außerdem kann man aus Google etc. meist gleich die fertigen Befehle kopieren. Warum? Weil ich als normaler User überhaupt keine Lust habe, erst stundenlang irgendwelche Befehlsmasturbation zu lesen, sondern einfach nur mein Ziel erreichen will.
--help tuts auch
google; manpages; irc; etc...
und das ergebnis mit einem minimalbeispiel in eine "tipps.txt" welche online verfügbar ist. die "tipps.txt" wird seit jahren fortgeführt.
... wo ist'n die verfügbar? *liebguck*
sie ist individuell auf mich und meine bedürfnisse der letzten zugeschnitten; und daher nicht offen im netz aufrufbar.
gern kann ich heute im laufe des abends einen nopaste eintrag hier einstellen.
Tipps:
http://nopaste.info/09d7b17053_nl.html
Debian-Setup:
http://nopaste.info/e11a183db7_nl.html
Settings (Home, etc):
http://nopaste.info/66b9ac4b2b_nl.html
Viel spass beim herausfinden, ob es jeweils "", -?, -h, -help oder --help ist.
Meistens ist es -? und --help
In den wenigen Fällen, wo dies nicht stimmt, ist es nun wirklich kein Problem, kurz -h zu testen.
Klar. Sache ist, man $cmd stimmt öfters und man kommt sowieso auch nach einem -?/-h nicht darum herum.
Beispiel:
$ gpt
usage: gpt [-rv] [-p nparts] command [options] device ...
Was genau macht -r? Oder -p? Was verbirgt sich hinter [options]?
Verstehe das Problem nicht, genau das verrät dir die Hilfe doch. Kenne nur wenige Fälle, in denen --help keine Erklärung liefert.
Siehe wget:
$ wget
wget: URL fehlt
Syntax: wget [OPTION]... [URL]...
»wget --help« gibt weitere Informationen.
$ wget --help
GNU Wget 1.12, ein nicht-interaktives Netz-Werkzeug zum Download von Dateien.
Syntax: wget [OPTION]... [URL]...
Erforderliche Argumente zu langen Optionen sind auch bei kurzen Optionen erforderlich.
Beim Start:
-V, --version Programmversion anzeigen und beenden
-h, --help diese Hilfe anzeigen
[..snip]
Es klingt bei dir, als ob man hier vor einem großen Problem steht. Aber wo soll das sein?
$ gpt -?
gpt: illegal option -- ?
usage: gpt [-rv] [-p nparts] command [options] device ...
$ gpt -h
gpt: illegal option -- h
usage: gpt [-rv] [-p nparts] command [options] device ...
$ gpt -help
gpt: illegal option -- h
usage: gpt [-rv] [-p nparts] command [options] device ...
$ gpt --help
gpt: illegal option -- -
usage: gpt [-rv] [-p nparts] command [options] device ...
Es klingt bei dir, als ob man hier vor einem großen Problem steht.
Ich stehe vor keinem Problem sondern stelle nur fest, dass man $cmd oft schneller zum Ziel führt als das Erraten des helf-Flags, welches ev. gar nicht existiert.
Das man --help oder "man befehl" aufruft, wenn man eine bestimmte Kommandozeilenoption nicht weiß, ist doch klar. Eine Suche mit der Suchmaschine würde dafür viel zu lange dauern.
Viel interessanter wäre daher die Frage, was ihr tut, wenn ihr ein Problem per kleines Shellscript lösen wollt, das nicht nur aus einem einzigen Kommandozeilenbefehl besteht, sondern Pipes bis hin zu komplexeren Formen durch Scripte nutzt?
Was macht ihr dann?
Versucht ihr dann das Problem durch studieren von man Pages und --help Ausgaben irgendwie zu lösen oder schaut ihr erstmal im Internet mit einer Suchmaschine nach einem Eintrag von jemandem, der schon ein ähnliches Problem hatte und dafür er oder andere eine fertige Lösung gepostet haben?
Oder geht ihr sogar so weit und fragt andere User im Internet um Hilfe?
was ihr tut, wenn ihr ein Problem per kleines Shellscript lösen wollt, das nicht nur aus einem einzigen Kommandozeilenbefehl besteht, sondern Pipes bis hin zu komplexeren Formen durch Scripte nutzt?
Was macht ihr dann?
Ich frage mich zuerst, ob es wirklich, wirklich, wirklich nötig ist ein Skript zu schreiben. Ein Skript ist schnell mal gekritzelt aber ebenso schnell wieder vergessen.. dann geschieht nach einer Weile folgendes: Keiner merkt, dass Fehler X durch Skript Y behindert wird oder warum Skript Y genau Fehler X verursacht bzw. begünstigt. Anschliessend fragen sich alle, warum Skript Y überhaupt geschrieben wurde und/oder wer Skript Y in Zukunft warten soll (der ursprüngliche Autor arbeitet leider nicht mehr hier).
Wenn das Skript trotzdem sein muss:
Alles in Funktionen packen, wobei main() den Anfang sowie getopts macht. Das restliche Ausprogrammieren sollte die gewöhnlichen Programmierstandards nicht unterschreiten.
dass Fehler X durch Skript Y behindert wird
..dass Anwendung X durch Skript Y behindert wird..
Also ich schreibe immer in der Scriptdatei ganz oben hin, wofür das Script da ist.
Ansonsten nutze ich aussagekräftige Dateinamen.
Aber wie sieht es denn für geringfügig komplexere Kommandos aus?
Schon wenn die nur aus drei Befehle mit ein paar Optionen bestehen kann das schon recht komplex
werden, dafür schreibt man trotzdem noch kein Script, aber man braucht es und ein bloßer Nachschlag in die man pages, welche Optionen es denn so gibt, reicht dann oft auch nicht mehr aus.
Hier muss man das ganze quasi aus einem Baukasten dann zu einem Ganzen zusammenfügen können.
Die meisten manpages sind als reine Beschreibung aller vorhandenen Optionen eines Befehls gestaltet.
Leider gibt es nur wenige manpages, die am Ende der umfangreichen Beschreibung auch mal ein paar Beispiele anführen. In vielen Fällen würde das reichen und man müsste sich nicht mühsam durch das komplette Dokument quälen.
Ich habe mir daher wie der Kollege weiter oben angewöhnt, solche Sachen, die ich mühsam aus den manpages herausgepopelt habe, in (m)eine eigene FAQ-Datei zu schreiben.
Da man pages auch zu den Open Source Projekten gehören, könntest du aber auch mal die man pages erweitern.
Denn wenn jeder seine eigene FAQ macht, was sicher irgendwo auch seine Berechtigung hat, mahen viele diese Arbeit dennoch unnötig redundant.
Das sehe ich nicht so. Ich brauche als "FAQ" kein Kompendium aller möglichen Funktionen, die ein Tool leisten kann. Im Gegenteil, das ist ein lebendes Dokument, das heißt von mir nicht mehr benötigte Informationen fliegen dort auch wieder raus. Ich sehe da keine unnötige Redundanz darin, sondern eher eine Art Cache, für Informationen die ich aus Man-Pages extrahiert habe ;)
Die Redundanz ist die, dass andere sich die gleiche Arbeit machen. Bei n Usern, also n FAQs.
Gerade dann, wenn du nur Kleinigkeiten ab und zu in deine FAQ schreibst, bietet sich sich an, bestehende man Pages um Kleinigkeiten zu erweitern. Es sagt ja niemand, dass du alle man pages von vorne an neu schreiben sollst.Es geh darum, etwas zu Ergänzen, wenn man meint das es fehlt und wenn es für eine man page sinnvoll ist.
Mich wundert sowieso, warum noch niemand die man pages auf eine Wiki gepackt hat und zukünftige man page Versionen dann aus den Wikieinträgen generiert werden.
Das würde die Entwicklung sicherlich stark beschleunigen.
Ich weiß, was du mit Redundanz meinst. Worauf ich hinaus will, ist dass diese Redundanz in einem persönlichen FAQ nicht unnötig ist, sondern durchaus ihren Zweck erfüllt. Wenn auch nur für den Autor.
Da kann man nur zustimmen. Manchmal fehlt die Information im Manual nicht wirklich, sie ist implizit vorhanden, der Leser wird nur nicht direkt mit der Nase darauf gestoßen, wie durch ein konkretes Beispiel. Man muss abwägen, wie relevant die eigenen Anwendungsfälle für Andere sind. Die gleichen Maßstäbe legst du letzten Endes auch für einen Wiki Artikel an.
Ich finde, hier kann so eine FAQ sogar helfen die Relevanz besser einzustufen. Nämlich gemessen daran, wie lange eine Information in der FAQ bleibt.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 14. Okt 2013 um 19:14.Ein wichtiger Befehl mit entsprechenden Optionsparametern, den man häufig benutzt, weil er wichtig ist, lernt man irgendwann durch häufige Benutzung auswendig, dann fliegt er aus der FAQ obwohl er für Anfänger weiterhin wichtig sein wird.
Die Dauer wie lange etwas in einer FAQ ist, ist somit meiner Meinung nach kein Kriterium für dessen Relevanz. In einer FAQ würden bei mir so nur noch Spezialfälle übrig bleiben, die man nur ganz selten benötigt und so etwas gehört dann doch nicht in eine man page, da es zu speziell ist.
Daher hätte ich einen anderen Vorschlag.
Die Linux Communityseitenabklappern und schauen, nach welchen Shellbefehlen und Kommandooptionen am häufigsten gefragt wird und wenn das dann nicht in den man pages als Beispiel drin steht, dann gehört es rein, weil es offensichtlich für viele Relevanz hat.
Gab es nicht mal die Möglichkeit, für Shell-Scripte einfach ein GUI zusammenzuklicken?
ano
Sicher kann man Skripte auch irgendwie zusammenklicken, jedoch kann ja gerade in Schriftform ein Problem exakt und reproduzierbar ausgedrückt werden. Ja, Piktogramme und Pfeile weisen den Weg zum Ausgang oder zum Klo, aber sie können niemals einen komplexen Sachverhalt ausdrücken. Manchmal ist das aber im Gegensatz zu aller Microsoft Propaganda notwendig z.B. eine kuschlige Umgebung für ein Programm zu schaffen und es mit anderen zur Zusammenarbeit zu bewegen. Und dann bin ich froh, daß es Shell Skripte gibt (und daß ich mir damals die Zeit genommen habe, es zu lernen)
Fuer schnelle Hilfe nutze ich das Internet. Zum stoebern die man.
Mit info habe ich mich nie richtig angefreundet. Die Umfrage hier ist sicher nicht repräsentativ für alle Nutzer, aber das scheint ja auch anderen so zu gehen (derzeit 0% bei 80 Stimmen), woran liegt das eigentlich?
Ich persönlich habe nie gelernt in dem Tool zu navigieren und die Informationen dann auf anderem Weg auch gefunden, also war es für mich unnötig.
ich verwende 'pinfo' da kann man mit den cursortasten navigieren.
Alternativ: in der address zeile vom konqueror "info:" tippen
Danke. pinfo kannte ich noch nicht.
Ich wünschte, ich hätte eher gefragt
Wenn ich dann wirklich mal auf die Shell muss und einen Parameter nicht weiß, dann starte ich Befehl -h .
Zum Glück ist das zwischenzeitlich aber recht selten der Fall. Viele Programme auf dem GUI setzen doch häufig beim Aufruf von Shell-Programmen die korrekten Schalter und Parameter
Die braucht man spätestens, wenn man mal via SSH auf irgendeinen Rechner zugreifen will.
Oder wenn man vgaswitcheroo bemühen will, um die Grafikchips im Notebook umzuschalten.
Grueße
Ignatz
Deshalb schreibe ich ja ausdrücklich "wenn ich mal auf die Shell muss" Kommt bei mir eher selten vor.
Die braucht man spätestens, wenn man mal via SSH auf irgendeinen Rechner zugreifen will.
Oder wenn man vgaswitcheroo bemühen will, um die Grafikchips im Notebook umzuschalten.
Grueße
Ignatz
Die braucht man einfach wenn man Cool ist und nicht so eine Mausschubse wie du sein möchte
Sag bitte vorher bescheid, wenn du wieder solch einen coolen Spruch absonderst, dann dreh ich die Heizung höher....
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 14. Okt 2013 um 11:46.Mal ehrlich, jeden Tag.