nicht mehr das neuste aber ... schön dokumentiert ... und online http://www.linux-ag.de/linux/LHB/ http://www.linux-ag.de/linux/LHB/node22.html#SECTION00400000000000000000
Derartige Bücher, die in die Linux-Befehle einführen, finde ich mal grundsätzlich gut.
Gleichzeitig zeigen sie jedoch eine Schwäche von Linux: die mitgelieferte Dokumentation. Da haben wir Man-Pages und Tex-Info Dokumente, die einen in die Benutzung eines Programms einführen. Man-Pages sind leicht zu lesen, enthalten jedoch oft kaum nützliche Infos (man sed). Tex-Info Dokumente können recht ausführlich sein, sind aber schwierig zu bedienen. Man muss also erst `info info` aufrufen, um das Doku-Programm zu verstehen und wird dann lediglich auf die informationslose man-Page verwiesen (KUbuntu).
Für den Entwickler eines Programms, der Dokumentation zur Verfügung stellen möchte ergibt sich eine Schwierigkeit, er muss zwei Doku-Dateiformate beherrschen, um ein Programm zu dokumentieren, kann sich dann fast sicher sein, dass diese Tex-Info Doku nie gelesen wird.
Es geht aber auch anders: Unter OpenBSD habe ich Man-Pages, die sind so lang wie die Seite von bash (man bash) und enthalten vielfach Beispiele und tiefergehende Erklärungen. Vorbildlich gemacht. So was wünsche ich mir.
Ich denke, dass solche Bücher wie das hier vorgestellte genau eine solche Dokumentationslücke ausfüllen, die von den Softwareentwicklern hinterlassen wird.
Gleichzeitig zeigen sie jedoch eine Schwäche von Linux: die mitgelieferte Dokumentation.
Mal wieder das übliche haltlose Blabla, was hier schon oft genug widerlegt wurde.
Man-Pages sind leicht zu lesen
Man-Pages sind höchstens leicht zu bedienen, vor allem wenn man ungeduldig ist und schnell etwas nachschlagen möchte. Sie sind aber von ihrem Inhalt her in den allermeisten Fällen als Referenz gestaltet, also um etwas nachzuschlagen, wenn man sich schon in Materie auskennt. Dementsprechend kann man sie eher als schwer zu lesen bezeichnen.
enthalten jedoch oft kaum nützliche Infos (man sed).
Dann schau Dir mal die Info-Page zu sed an, und Du wirst staunen (Debian).
Man muss also erst `info info` aufrufen, um das Doku-Programm zu verstehen
Das ist in der Tat am Anfang eine ziemlich große Hürde, vor allem wenn man die einfach zu bedienenden Man-Pages gewohnt ist. Zudem wirkt der originale Info-Browser auch noch ziemlich unübersichtlich. Aber es gibt ja auch noch andere Browser, wie z.B. das schon genannte pinfo, oder tkinfo, oder tkman und yelp soll wohl auch Info-Seiten anzeigen können. Ziemlich praktisch am Info-System ist auch, dass es out-of-the-box eine globale Suche mitbringt.
Für den Entwickler eines Programms, der Dokumentation zur Verfügung stellen möchte ergibt sich eine Schwierigkeit, er muss zwei Doku-Dateiformate beherrschen
Es gibt Konverter.
Es geht aber auch anders: Unter OpenBSD habe ich Man-Pages, die sind so lang wie die Seite von bash (man bash) und enthalten vielfach Beispiele und tiefergehende Erklärungen.
Das ist allerdings sehr schade, dass solche Sachen nicht einfach von den BSD-Manpages übernommen werden. Aber bei GNU wird halt Info präferiert, und wenn man sich erst dran gewöhnt hat, ist es sehr hilfreich.
Das größte Problem der man Pages ist meiner Meinung nach die fehlenden Bespiele! Einige Man-Pages habe zwar welche, aber leider bei weitem nicht allen. Gerade für Programmierneulinge ist es schwer aus den recht verschlüsselt geschriebenen Man-Pages einen Konkreten Befehl abzuleiten. Es sollte Sitte werden mindestens Drei Beispiele anzugeben.
Mal wieder das übliche haltlose Blabla Ich verwende GNU/Linux schon seit 10 Jahren, habe selber Info-Seiten und Man-Pages geschrieben. Ich weiß, wovon ich spreche.
hatte das gleiche problem mit info und das obwohl ich seit 9 Jahren fast ausschließlich Linux verwende. Die man-page zu vielen Befehlen sind nun mal etwas "abstrakt" (technologisch sicherlich sinnvoll). Manche möchten trotzdem nur ein paar einfache Beispiele zum anpassen ohne sich mit regulären Ausdrücken auseinandersetzen zu müssen (wenn jemand Blut geleckt hat tut er das dann eh).
"haltlos" ist ein ziemlich starkes Wort dafür und beschreibt das, was ich in letzter Zeit immer mehr in diesen Foren vermisse: Einfühlungsvermögen und Freundlichkeit.
"haltlos" ist ein ziemlich starkes Wort dafür und beschreibt das, was ich in letzter Zeit immer mehr in diesen Foren vermisse: Einfühlungsvermögen und Freundlichkeit.
>>"haltlos" ist ein ziemlich starkes Wort dafür und beschreibt das, was ich in letzter Zeit immer mehr >>in diesen Foren vermisse: Einfühlungsvermögen und Freundlichkeit.
in letzter Zeit? Das ist schon seit mehr als 10 Jahren so.
> > Gleichzeitig zeigen sie jedoch eine Schwäche von Linux: die mitgelieferte Dokumentation.
> Mal wieder das übliche haltlose Blabla, was hier schon oft genug widerlegt wurde.
Du kennst offensichtlich nicht die Qualität der Dokumenttion unter *BSD, denn sonst würdest Du Dir wünschen, daß linuxbasierte Distributionen sich davon eine Scheibe abschneiden!
Zugegeben... wenn Kernel und Basissystem, wie bei *BSD, gemeinsam entwickelt werden statt als Suppe tausender unabhängiger Köche (ausnahmsweise isz mal nicht der hessische Ebendieser gemeint!) wie bei Linuxdistributionen, dann sind Vollständigkeit und Korrektheit leichter zu gewährleisten... ich seh ja ein, daß die *BSDs es da organisatorsisch bedingt einfacher haben, aber etwas mehr Mühe sollten sich die "Linuxmacher" ruhig geben!
Der Titel zeugt von Unverständnis und wird es auch noch weiter voran treiben. Es gibt keine Linux-Befehle! Es gibt höchstens Unix- oder GNU-Befehle. In den meisten Fällen sind es sogar schlicht Shell- bzw. bash-Befehle. Was in diesem Buch steht würde doch genau so gut unter FreeBSD oder Solaris funktionieren.
Wenn ein Linux-Neuling ein Buch sucht, so wird er unter Linux und nicht unter Unix oder GNU suchen. Bitte, spiel Apostel, reise durchs Land und bekehre Leute damit sie auch im richtigen Buecherregal schauen und Autoren dann nicht mehr falsche Namen verwenden muessen.
Gibts eigentlich nichts Wichtiges was Du zu tun hast dass Du Dich darueber aufregen kannst? Ja, es wuerde auch unter FreeBSD und Solaris funktionieren, ausserdem noch unter IRIX, HP/UX, Sinix, SunOS, OSF/1, DecUnix, und und und ... Und als schlauer Mensch bist Du sicher in der Lage auch im Linux-Regal zu suchen um dann kurz den Titel belaecheln.
Von Anonymous Coward am Fr, 14. März 2008 um 00:07 #
Wenn man keine Ahnung hat, einfach mal die Fresse halten. GNU-Utilities weisen viele Erweiterungen gegenüber dem auf, was POSIX vorschreibt. date +%F wird z. B. nur mit GNU date funktionieren.
Was in diesem Buch steht würde doch genau so gut unter FreeBSD oder Solaris funktionieren.
[ ] .... Du bist voll der Durchblicker.
Gerade auf der Kommandozeilenebene gibt es deutliche Unterschiede zwischen GNU- und BSD-basierten Systemen und diese können bei hinreichender Blauäugigkeit sogar primstens nach Hinten losgehen.
Als Bonmot lasse man sich auf der Zunge zergehen: GNU is Not Unix!
Ich kacke größere Korinthen als du, denn ich weiß: "Befehle" in diesem Sinne sind bestenfalls die in die Shell integrierten Schmankerl wie cd, pwd oder set. Zeugs wie ls oder cat sind streng genommen Programm-Aufrufe. Aber, und damit ist meine Korinthenkackerei leider hinfällig, ist ein Programmaufruf sozusagen nichts anderes als ein Befehl an das Betriebssystem, Code aus einer bestimmten ELF-Datei zu laden und in einen neuen Prozess auszuführen. Allein weil es keinen dedizierten notwendigen Befehl wie run* dafür gibt (dass man etwa schreiben muss: run ls -l /mnt/disk/), mache ich in meinen Korinthendurchfällen diese Unterscheidung.
*) so was ähnliches gibt es ja: exec, das tut aber etwas anderes - macht euch schlau.
gibt es irgendwelche Gruende, $() zu bevorzugen. Seit ich nur noch US Tastaturen verwende, habe ich mich mit den Backticks angefreundet, da ich genau weiss, wo sie zu finden sind. (ist das vllt der Grund, dass eben $() "eindeutig" ist).
$() ist schachtelbar, weil das öffnende und das schließende Zeichen ungleich sind. Zudem ist es, wenigstens für mich, leichter lesbar, insbesondere bei kleinen Fonts. Bei manchen Fonts sind zudem '`Ž schlecht zu unterscheiden.
Das ist richtig, allerdings habe ich alle meine Skripte wieder auf Backticks zurückändern dürfen weil zsh nicht mit der $() Konvention klar kam. Sofern ich allerdings mehrere Befehle schachteln möchte, würde ich eher auf Pipes zurückgreifen da es bei mehrere Schachteln schonmal unübersichtlich werden kann woher den jetzt ein Fehler kam, eine pipe baue ich von links nach rechts auf und mehr als 4 mal musste ich bisher noch nichts pipen (was für ein Wort). Oder ich mache manche Scripte auch mit Sed und Awk, was mir teilweise besser gefällt als Bash (von der hohen Lernkurve mal abgesehen).
Wobei ich allerdings weiß was mein Vorredner meint an einem Monitor zu sitzen mit schlechter Auflösung, zu hoher Auflösung, zu niedriger und nicht erhöherbarer Wiederholfrequenz etc. Dort ist es wirklich nicht einfach mit Backticks zu arbeiten.
Wer sich mal den Spaß durchlesen möchte, der kann in der bash manpage (man bash ca ab Zeile 1023) sich den ganzen Spaß durchlesen.
A command enclosed in parentheses preceded by a dollar sign, like `$(...)', or quoted with grave accents, like ``...`', is replaced with its standard output, with any trailing newlines deleted. If the substitution is not enclosed in double quotes, the output is broken into words using the IFS parameter. The substitution `$(cat FOO)' may be replaced by the equivalent but faster `$(<FOO)'. In either case, if the option GLOB_SUBST is set, the output is eligible for filename generation.
http://www.linux-ag.de/linux/LHB/
http://www.linux-ag.de/linux/LHB/node22.html#SECTION00400000000000000000
zap
Für Interessierte, die zu faul zum googlen sind:
http://home.arcor.de/thomas.litsch/downloads/
dort lhb-7.0.tar.gz
Viel Spaß damit
Gleichzeitig zeigen sie jedoch eine Schwäche von Linux: die mitgelieferte Dokumentation. Da haben wir Man-Pages und Tex-Info Dokumente, die einen in die Benutzung eines Programms einführen. Man-Pages sind leicht zu lesen, enthalten jedoch oft kaum nützliche Infos (man sed). Tex-Info Dokumente können recht ausführlich sein, sind aber schwierig zu bedienen. Man muss also erst `info info` aufrufen, um das Doku-Programm zu verstehen und wird dann lediglich auf die informationslose man-Page verwiesen (KUbuntu).
Für den Entwickler eines Programms, der Dokumentation zur Verfügung stellen möchte ergibt sich eine Schwierigkeit, er muss zwei Doku-Dateiformate beherrschen, um ein Programm zu dokumentieren, kann sich dann fast sicher sein, dass diese Tex-Info Doku nie gelesen wird.
Es geht aber auch anders: Unter OpenBSD habe ich Man-Pages, die sind so lang wie die Seite von bash (man bash) und enthalten vielfach Beispiele und tiefergehende Erklärungen. Vorbildlich gemacht. So was wünsche ich mir.
Ich denke, dass solche Bücher wie das hier vorgestellte genau eine solche Dokumentationslücke ausfüllen, die von den Softwareentwicklern hinterlassen wird.
GnuShi
gruss,
die mad
Alt-F2 aufrufen, dann "#ls" eingeben, ruft die man page auf.
"##sed" zeigt das info Dokument.
Sehr schöne Sache!
Mal wieder das übliche haltlose Blabla, was hier schon oft genug widerlegt wurde.
Man-Pages sind leicht zu lesen
Man-Pages sind höchstens leicht zu bedienen, vor allem wenn man ungeduldig ist und schnell etwas nachschlagen möchte. Sie sind aber von ihrem Inhalt her in den allermeisten Fällen als Referenz gestaltet, also um etwas nachzuschlagen, wenn man sich schon in Materie auskennt.
Dementsprechend kann man sie eher als schwer zu lesen bezeichnen.
enthalten jedoch oft kaum nützliche Infos (man sed).
Dann schau Dir mal die Info-Page zu sed an, und Du wirst staunen (Debian).
Man muss also erst `info info` aufrufen, um das Doku-Programm zu verstehen
Das ist in der Tat am Anfang eine ziemlich große Hürde, vor allem wenn man die einfach zu bedienenden Man-Pages gewohnt ist. Zudem wirkt der originale Info-Browser auch noch ziemlich unübersichtlich. Aber es gibt ja auch noch andere Browser, wie z.B. das schon genannte pinfo, oder tkinfo, oder tkman und yelp soll wohl auch Info-Seiten anzeigen können. Ziemlich praktisch am Info-System ist auch, dass es out-of-the-box eine globale Suche mitbringt.
Für den Entwickler eines Programms, der Dokumentation zur Verfügung stellen möchte ergibt sich eine Schwierigkeit, er muss zwei Doku-Dateiformate beherrschen
Es gibt Konverter.
Es geht aber auch anders: Unter OpenBSD habe ich Man-Pages, die sind so lang wie die Seite von bash (man bash) und enthalten vielfach Beispiele und tiefergehende Erklärungen.
Das ist allerdings sehr schade, dass solche Sachen nicht einfach von den BSD-Manpages übernommen werden.
Aber bei GNU wird halt Info präferiert, und wenn man sich erst dran gewöhnt hat, ist es sehr hilfreich.
Einige Man-Pages habe zwar welche, aber leider bei weitem nicht allen.
Gerade für Programmierneulinge ist es schwer aus den recht verschlüsselt geschriebenen Man-Pages einen Konkreten Befehl abzuleiten.
Es sollte Sitte werden mindestens Drei Beispiele anzugeben.
Mal wieder das übliche haltlose Blabla
Ich verwende GNU/Linux schon seit 10 Jahren, habe selber Info-Seiten und Man-Pages geschrieben. Ich weiß, wovon ich spreche.
In Man-Pages kann man auch schnell Infos finden.
"haltlos" ist ein ziemlich starkes Wort dafür und beschreibt das, was ich in letzter Zeit immer mehr in diesen Foren vermisse: Einfühlungsvermögen und Freundlichkeit.
Übrigens: installiere gerade pinfo.
"haltlos" ist ein ziemlich starkes Wort dafür und beschreibt das, was ich in letzter Zeit immer mehr in diesen Foren vermisse: Einfühlungsvermögen und Freundlichkeit.
*Zustimmung*
GnuShi
>>in diesen Foren vermisse: Einfühlungsvermögen und Freundlichkeit.
in letzter Zeit? Das ist schon seit mehr als 10 Jahren so.
> Mal wieder das übliche haltlose Blabla, was hier schon oft genug widerlegt wurde.
Du kennst offensichtlich nicht die Qualität der Dokumenttion unter *BSD, denn sonst würdest Du Dir wünschen, daß linuxbasierte Distributionen sich davon eine Scheibe abschneiden!
Zugegeben... wenn Kernel und Basissystem, wie bei *BSD, gemeinsam entwickelt werden statt als Suppe tausender unabhängiger Köche (ausnahmsweise isz mal nicht der hessische Ebendieser gemeint!) wie bei Linuxdistributionen, dann sind Vollständigkeit und Korrektheit leichter zu gewährleisten... ich seh ja ein, daß die *BSDs es da organisatorsisch bedingt einfacher haben, aber etwas mehr Mühe sollten sich die "Linuxmacher" ruhig geben!
Wenn ein Linux-Neuling ein Buch sucht, so wird er unter Linux und nicht unter Unix oder GNU suchen. Bitte, spiel Apostel, reise durchs Land und bekehre Leute damit sie auch im richtigen Buecherregal schauen und Autoren dann nicht mehr falsche Namen verwenden muessen.
Gibts eigentlich nichts Wichtiges was Du zu tun hast dass Du Dich darueber aufregen kannst? Ja, es wuerde auch unter FreeBSD und Solaris funktionieren, ausserdem noch unter IRIX, HP/UX, Sinix, SunOS, OSF/1, DecUnix, und und und ... Und als schlauer Mensch bist Du sicher in der Lage auch im Linux-Regal zu suchen um dann kurz den Titel belaecheln.
gruss,
die mad
Aber selbstverständlich gibt es die. Z.B. die Befehle der module-init-tools, oder einige Befehle der procps utilities.
[ ] .... Du bist voll der Durchblicker.
Gerade auf der Kommandozeilenebene gibt es deutliche Unterschiede zwischen GNU- und BSD-basierten Systemen und diese können bei hinreichender Blauäugigkeit sogar primstens nach Hinten losgehen.
Als Bonmot lasse man sich auf der Zunge zergehen: GNU is Not Unix!
*) so was ähnliches gibt es ja: exec, das tut aber etwas anderes - macht euch schlau.
gibt es irgendwelche Gruende, $() zu bevorzugen. Seit ich nur noch US Tastaturen verwende, habe ich mich mit den Backticks angefreundet, da ich genau weiss, wo sie zu finden sind.
(ist das vllt der Grund, dass eben $() "eindeutig" ist).
cheers
Zudem ist es, wenigstens für mich, leichter lesbar, insbesondere bei kleinen Fonts. Bei manchen Fonts sind zudem '`Ž schlecht zu unterscheiden.
Wobei ich allerdings weiß was mein Vorredner meint an einem Monitor zu sitzen mit schlechter Auflösung, zu hoher Auflösung, zu niedriger und nicht erhöherbarer Wiederholfrequenz etc. Dort ist es wirklich nicht einfach mit Backticks zu arbeiten.
Wer sich mal den Spaß durchlesen möchte, der kann in der bash manpage (man bash ca ab Zeile 1023) sich den ganzen Spaß durchlesen.
Funktioniert bei mir tadellos.
Zitat aus der zsh-Infopage:
14.4 Command Substitution
=========================
A command enclosed in parentheses preceded by a dollar sign, like
`$(...)', or quoted with grave accents, like ``...`', is replaced with
its standard output, with any trailing newlines deleted. If the
substitution is not enclosed in double quotes, the output is broken
into words using the IFS parameter. The substitution `$(cat FOO)' may
be replaced by the equivalent but faster `$(<FOO)'. In either case, if
the option GLOB_SUBST is set, the output is eligible for filename
generation.