The Unix Haters Handbook

[Ivo]

Und? Das Gegenstück zu mkdir ist rmdir.

rm -r foo geht auch

Teilweise steht das auch in dem Buch, teilweise aus eigener Erfahrung. Gibt noch mehr, wenn mir was aus eigener Sache einfällt dann lass ich es euch wissen. Auch immer wieder ärgerlich ist, dass man bei find den Pfad ganz am Anfang angeben muss.

Ja, find ist kompliziert zu verwenden.

So viel mehr ist es doch auch nicht:
find / | grep foo

Notfalls kann man sich ja auch ein alias in die bashrc setzen.

[shisha]

auch das über C++ hat finde ich einen wahren Kern:

The Evolution of a Programmer
[We’d love to assign credit for this, but it’s been whizzing around Cyberspace
for so long that the task would probably be impossible. —Eds.]
High school/Junior high
10 PRINT "HELLO WORLD"
20 END
First year in college
program Hello(input, output);
begin
writeln ('Hello world');
end.
Senior year in college
(defun hello ()
(print (list 'HELLO 'WORLD)))
New professional
#include <stdio.h>
main (argc,argv)
int argc;
char **argv; {
printf ("Hello World!\n");
}
216 C++
Seasoned pro
#include <stream.h>
const int MAXLEN = 80;
class outstring;
class outstring {
private:
int size;
char str[MAXLEN];
public:
outstring() { size=0; }
~outstring() {size=0;}
void print();
void assign(char *chrs);
};
void outstring::print() {
int i;
for (i=0 ; i< size ; i++)
cout << str[i];
cout << "\n";
}
void outstring::assign(char *chrs) {
int i;
for (i=0; chrs[i] != '\0';i++)
str[i] = chrs[i];
size=i;
}
main (int argc, char **argv) {
outstring string;
string.assign("Hello World!");
string.print();
}
Manager
“George, I need a program to output the string ‘Hello World!’”

also ich finds lustig
.. fehlt nur noch die ausgabe immer dazu...
hello world
hello world
...
segmentation fault

[LordJaxom]

Linux-User schrieb:

touch kann selbst heute noch keine Datei mit einem führenden - als Eingabe akzeptieren.

Bei mir schon.

[F98]

Linux-User schrieb:

Auch lustig:

user@linux:~$ mkdir test
mkdir: kann Verzeichnis „test“ nicht anlegen: File exists
user@linux:~$ rm test
rm: Entfernen von „test“ nicht möglich: Is a directory

Auf einem aktuellen Ubuntu.

Diese Ausgabe ist völlig korrekt. Unter Unix/Linux wird alles als "file" behandelt.

[Linux-User]

@nman, über den Blog-Einträg bin ich überhaupt erst auf das Buch gestoßen bzw. beides gleichzeitig und den Blog-Eintrag habe ich zuerst gelesen.

nman schrieb:

fricky: Wie wäre es, wenn Du Dein Getrolle ausnahmsweise auf themenspezifisches beschränkst oder einstellst?

Linux-User schrieb:

Lustiger sind dann schon sachen wie eine Datei -r in einem Verzeichnis und man macht ein rm * um alle Dateien in diesem Ordner zu löschen...

Wie häufig passiert das realistischerweise?

Es geht um den Schaden den es anrichten kann, nicht darum wie häufig es passiert. Mir ist bisher erst einmal im Leben ein erheblicher Datenverlust durch rm entstanden. Danach habe ich gelernt, dass es keine unwichtigen Dateien gibt auf die man verzichten könnte (ok, ich konnte darauf verzichten, aber ich hätte sie gerne noch gehabt). Und seit dem enthält mein wöchentliches Backup alle Dateien.
Aber so ein zwei-stufiger Löschprozess wäre schon eine tolle Sache, d.h. alle Dateien sind so lange abrufbar bis das Dateisystem den Speicher benötigt. Wobei das ja in ein paar Jahren unter Linux Einzug erhält mit Btrfs oder Logfs (ich glaube Tux3 wird das auch unterstützten). Da hat man dann versioning.

Auch lustig:

user@linux:~$ mkdir test
mkdir: kann Verzeichnis „test“ nicht anlegen: File exists
user@linux:~$ rm test
rm: Entfernen von „test“ nicht möglich: Is a directory

Auf einem aktuellen Ubuntu.

Und? Das Gegenstück zu mkdir ist rmdir.

Hier ging es um die Fehlerausgabe, nicht die Abfolge der Kommandos selbst.

@LordJaxom, das macht die Standardtools dann leider noch komplizierter. Bei manchen geht es bei manchen nicht

Eine andere Sache wo das Buch recht hat ist die on-line Dokumentation. So findet man manchmal etwas in man, häufig ist die Dokumentation aber stark abgespeckt mit der Info, dass man die offizielle Doku in "info" findet und dort dann nur die selbe man-page Seite zu Gesicht bekommt, weil die Distribution die info-Seiten nicht mitausliefert. Dann gibt es noch den Fall, dass es sich um shell built-ins handelt (oder noch besser es gibt ein globales Tools gleichen Namens für das es eine man-Seite gibt, aber man benutzt ein shell built-in mit erweiterter/veränderter Syntax, z.B. read in Bash). Klar wer weiß, dass es da Unterschiede gibt benutzt zuerst einmal type of das Kommando und schaut dann entweder mit "help kommando" oder "man kommando" nach, aber für Leute die schon entsprechendes Know-How haben ist eine on-line Dokumentation viel weniger wichtig als für Einsteiger.
Hier würde ich mir ein mächtiges und konsistentes System wie in Emacs wünschen. Info wäre da ein guter Kandidat, da man alle Info-Manuals auf einen Blick hat mit mächtigen Funktionen, aber wie gesagt oftmals werden die Info-Seiten gar nicht ausgeliefert (bei meinem System zum Glück nicht).

[supertux]

Linux-User schrieb:

und touch kann selbst heute noch keine Datei mit einem führenden - als Eingabe akzeptieren.

~ $ touch -- -unsinn
 ~ $ ls -- -unsinn
-rw-r--r-- 1 yanez yanez 0 Aug 26 17:18 -unsinn
 ~ $ rm -- -unsinn
 ~ $ ls -- -unsinn
ls: cannot access -unsinn: No such file or directory

[nman]

Ivo schrieb:

Und? Das Gegenstück zu mkdir ist rmdir.

rm -r foo geht auch

Andere Semantik. rmdir löscht nur leere Verzeichnisse, rm -r rekursiv alles unterhalb von foo. Ich verwende daher häufig rmdir, weil es dumme Fehler anfängt, auch wenn ich es früher für überflüssig hielt.

So viel mehr ist es doch auch nicht:
find / | grep foo

Naja, ich dachte an Dinge wie find / -iname '*foo*' -type d -exec touch {} \; oä. find ist sehr mächtig, aber leider komplizierter zu verwenden als nötig, die Lernkurve sieht hier eher unschön aus.

zwutz schrieb:

die Sache ist wohl eher, dass es gültige Dateinamen gibt, mit denen einige der fundamentalsten Linuxprogramme nicht zurechtkommen. Und dabei sind es nichtmal irgendwelche Sonderzeichenexperimente, die über ein fremdes System ins Dateisystem "geschmuggelt" wurden

Klar, könnte man als unschön sehen, wenn man tatsächlich mal den Timestamp einer Datei namens "-r" ändern möchte. Andererseits bewahrt mich das inkonsistente Verhalten von touch sehr effektiv davor, versehentlich Dateien mit derart unpraktischen Namen anzulegen. Ich halte das für keinen Bug, sondern für ein etwas hässliches und eigentümliches Feature. Dafür lassen sich bestimmt auch irgendwelche Belege finden, wenn man mal recherchiert.

Aber so ein zwei-stufiger Löschprozess wäre schon eine tolle Sache, d.h. alle Dateien sind so lange abrufbar bis das Dateisystem den Speicher benötigt. Wobei das ja in ein paar Jahren unter Linux Einzug erhält mit Btrfs oder Logfs (ich glaube Tux3 wird das auch unterstützten). Da hat man dann versioning.

Wenn Du Verzeichnisse versioniert haben möchtest, dann pack sie doch in ein Versionskontrollsystem. Oder mach versionierte Backups.

Ein versioniertes Dateisystem hatte zB VMS schon und ich trauere dem nicht hinterher. Hatte natürlich seine Vorteile, aber auch massig Nachteile.

rm ist nunmal eine sehr endgültige Sache; es gab da auch ein Projekt, mit einer Art rm-Papierkorb, der über die libc reingepatcht wurde, aber im Grunde sollte sowas IMO das GUI regeln.

(Ich glaube, übrigens dass Du ein Feature von Btrfs falsch verstanden hast, ich verfolge das recht interessiert, kann mich aber nicht an das erinnern, was Du zu meinen scheinst. Bei Tux3 _glaube_ ich das auch, kenne mich aber nicht besonders aus und von Logfs weiß ich praktisch nichts.)

Hier ging es um die Fehlerausgabe, nicht die Abfolge der Kommandos selbst.

Ach so. Naja, ein Verzeichnis ist eben eine Datei.

So findet man manchmal etwas in man, häufig ist die Dokumentation aber stark abgespeckt mit der Info, dass man die offizielle Doku in "info" findet und dort dann nur die selbe man-page Seite zu Gesicht bekommt, weil die Distribution die info-Seiten nicht mitausliefert.

Das ist eine GNU-Krankheit. Die BSDs haben richtig gute Manpages, die GNU-Leute wollen nur ihre Info-Seiten pflegen. Info halte ich allerdings auch für unschön, da gefällt mir man wesentlich besser. (Insbesondere ist der Standard-Info-Browser furchtbar, wenn ich nicht Emacs-User wäre, wäre Info für mich völlig unbenutzbar.)

Versteht mich nicht falsch; Unix hat einige ernsthafte, große Schwierigkeiten. Aber statt echte fundamentale Probleme aufzuzählen, ergeht sich das Buch größtenteils darin, über oberflächlichen Kleinscheiß zu motzen und herumzutrollen.

Viel spannender und gehaltvoller finde ich da das entsprechende Kapitel von ESRs "The Art of Unix Programming": http://www.faqs.org/docs/artu/futurechapter.html

[Linux-User]

supertux schrieb:

Linux-User schrieb:

und touch kann selbst heute noch keine Datei mit einem führenden - als Eingabe akzeptieren.

[17:15:58 - 08.26.2009] [yanez@psepc20] [/dev/pts/3] [~] [130] 
 ~ $ touch -- -unsinn
[17:18:10 - 08.26.2009] [yanez@psepc20] [/dev/pts/3] [~] [0] 
 ~ $ ls -- -unsinn
-rw-r--r-- 1 yanez yanez 0 Aug 26 17:18 -unsinn
[17:18:13 - 08.26.2009] [yanez@psepc20] [/dev/pts/3] [~] [0] 
 ~ $ rm -- -unsinn
[17:18:18 - 08.26.2009] [yanez@psepc20] [/dev/pts/3] [~] [0] 
 ~ $ ls -- -unsinn
ls: cannot access -unsinn: No such file or directory

Danke, für den Hinweis. Da habe ich mich von dem Buch irre führen lassen, denn dort wurde "-" als Trenner anstelle von "--" angegeben (und ich wusste zwar, dass es die Möglichkeit zum Trennen gibt, aber nicht das genaue Symbol, wobei ich -- eigentlich regelmäßig bei GIT benutze ...).
Das eigentliche Problem ist aber, wie auch in dem Buch beschrieben, dass die Programme die GLOBs nicht zu Gesicht bekommen. Schöner wäre der Ansatz aus dem Buch, dass Programme diese per Bibliothek expandieren können und die GLOBs bei Bedarf noch analysieren könnten und so eher vor dummen Fehler bewahren.

[nman]

Linux-User schrieb:

Danke, für den Hinweis. Da habe ich mich von dem Buch irre führen lassen, denn dort wurde "-" als Trenner anstelle von "--" angegeben

Vermutlich ein Satzfehler; viele Schriften haben eine Ligatur, die aus "--" einen Gedankenstrich machen. (Oder das Satzsystem macht das, wie auch immer.)

Das eigentliche Problem ist aber, wie auch in dem Buch beschrieben, dass die Programme die GLOBs nicht zu Gesicht bekommen. Schöner wäre der Ansatz aus dem Buch, dass Programme diese per Bibliothek expandieren können und die GLOBs bei Bedarf noch analysieren könnten und so eher vor dummen Fehler bewahren.

Dann müsste sich aber zwangsläufig auch jedes Programm selbst um Globs kümmern. Nein, auch wenn das Buch das als hübsche Lösung präsentiert; Globbing ist schon Shellsache.

[Linux-User]

nman schrieb:

Aber so ein zwei-stufiger Löschprozess wäre schon eine tolle Sache, d.h. alle Dateien sind so lange abrufbar bis das Dateisystem den Speicher benötigt. Wobei das ja in ein paar Jahren unter Linux Einzug erhält mit Btrfs oder Logfs (ich glaube Tux3 wird das auch unterstützten). Da hat man dann versioning.

Wenn Du Verzeichnisse versioniert haben möchtest, dann pack sie doch in ein Versionskontrollsystem. Oder mach versionierte Backups.

Klar kann man das, aber es geht nicht automatisch. Ich habe normal mehr als genug freien Diskspace den das Dateisystem für ein paar Diffs und gelöschte Dateien zeitweise benutzen könnte.

Ein versioniertes Dateisystem hatte zB VMS schon und ich trauere dem nicht hinterher. Hatte natürlich seine Vorteile, aber auch massig Nachteile.

Was sind die Nachteile?

rm ist nunmal eine sehr endgültige Sache; es gab da auch ein Projekt, mit einer Art rm-Papierkorb, der über die libc reingepatcht wurde, aber im Grunde sollte sowas IMO das GUI regeln.

Diese Patches kenne ich, aber so wie ich gehört habe gibt es trotzdem noch Fälle wo Dateien gelöscht werden ohne, dass diese gepatchten Routinen das erledigen. Und das schlimmste ist wenn man sich in falscher Sicherheit wiegt, auch wenn selbst nach jahrelangem Windows-Einsatz noch heute den Papierkorb kaum benutze (lösche meist direkt, oder leere den Papierkorb danach). Allerdings passiert es einem in einer GUI nicht so leicht, dass man falsche Dateien löscht.
Daher wäre so eine kleine Hilfe bei rm schon nicht schlecht, so lange man nicht eine "kann es ja sowieso wiederherstellen"-Mentalität entwickelt.

(Ich glaube, übrigens dass Du ein Feature von Btrfs falsch verstanden hast, ich verfolge das recht interessiert, kann mich aber nicht an das erinnern, was Du zu meinen scheinst. Bei Tux3 _glaube_ ich das auch, kenne mich aber nicht besonders aus und von Logfs weiß ich praktisch nichts.)

Ok, die Snapshots sind nicht das Selbe wie Versioning, aber ein bischen helfen kann es trotzdem (wobei ich denke, dass es nicht mit den Checkpoints bei LogFS mithalten kann, da sind die Kosten quasi 0 für das Erstellen eines Checkpoints).
Auf LWN.net findest du einen kleinen Artikel über LogFS: http://lwn.net/Articles/234441/

[quote]

Hier ging es um die Fehlerausgabe, nicht die Abfolge der Kommandos selbst.

Ach so. Naja, ein Verzeichnis ist eben eine Datei.

Ist mir schon klar, aber halt ein technisches Detail das hier leakt. Ein normaler User muss das nicht wissen (bzw. sollte es nicht wissen müssen).

So findet man manchmal etwas in man, häufig ist die Dokumentation aber stark abgespeckt mit der Info, dass man die offizielle Doku in "info" findet und dort dann nur die selbe man-page Seite zu Gesicht bekommt, weil die Distribution die info-Seiten nicht mitausliefert.

Das ist eine GNU-Krankheit. Die BSDs haben richtig gute Manpages, die GNU-Leute wollen nur ihre Info-Seiten pflegen. Info halte ich allerdings auch für unschön, da gefällt mir man wesentlich besser. (Insbesondere ist der Standard-Info-Browser furchtbar, wenn ich nicht Emacs-User wäre, wäre Info für mich völlig unbenutzbar.)

Was findest du an Info so schlecht? Ich hatte vor einiger Zeit keine Meinung dazu, dann habe ich angefangen "The Linux System Administration Handbook" zu lesen und dort wurde es total niedergemacht. Danach dachte ich "boah wie schlecht das Ding sein muss" (ok, damals hatte ich mit info auch nie was anfangen können, wenn mich eine Manpage mal wieder auf diese verwies). Und dann habe ich angefangen Emacs zu benutzen und die Info Seiten zu schätzen gelernt. Finde diese Baum-artige Struktur mit den Links und allem echt toll. Wie kann es sein, dass du mit Emacs Info nutzen kann und ohne nicht? Das Kommandozeilen-Toll hat doch die gleichen Shortcuts

Versteht mich nicht falsch; Unix hat einige ernsthafte, große Schwierigkeiten. Aber statt echte fundamentale Probleme aufzuzählen, ergeht sich das Buch größtenteils darin, über oberflächlichen Kleinscheiß zu motzen und herumzutrollen.

Viel spannender und gehaltvoller finde ich da das entsprechende Kapitel von ESRs "The Art of Unix Programming": http://www.faqs.org/docs/artu/futurechapter.html

Werde ich als nächstes lesen. Bisher habe ich mir noch nie Gedanken darüber gemacht was an Unix schlecht ist, daher habe ich hier noch keine große Meinung dazu.

[Linux-User]

Oh ganz vergessen. Aus dem Buch:

No File Types
To UFS and all Unix-derived file systems, files are nothing more than long
sequences of bytes. (A bag’o’bytes, as the mythology goes, even though
they are technically not bags, but streams). Programs are free to interpret
those bytes however they wish. To make this easier, Unix doesn’t store
type information with each file. Instead, Unix forces the user to encode this
information in the file’s name! Files ending with a “.c” are C source files,
files ending with a “.o” are object files, and so forth. This makes it easy to
burn your fingers when renaming files.
To resolve this problem, some Unix files have “magic numbers” that are
contained in the file’s first few bytes. Only some files—shell scripts, “.o”
files and executable programs—have magic numbers. What happens when
a file’s “type” (as indicated by its extension) and its magic number don’t
agree? That depends on the particular program you happen to be running.
The loader will just complain and exit. The exec() family of kernel func-
tions, on the other hand, might try starting up a copy of /bin/sh and giving
your file to that shell as input.

Also ich finde deren Vorschlag (Dateityp als Attribut der Datei) hat keine Vorteile gegenüber dem Unix-Weg zur Erkennung einer Datei. Ein Dateiattribut kann genau so falsch sein wie eine Dateiendung und ein gutes Programm sollte eine Datei anhand ihres Inhaltes bewerten und nicht nach einer Endung oder einem Attribut. Bei dem Punkt mit dem Umbenennen muss ich denen aber Recht geben. Allerdings kann Thunar (Dateimanager) beim Umbenennen automatisch alles bis auf die Dateiendung markieren, so kann man die Dateien leicht umbenennen ohne, dass man die Endung wiederholen muss (könnte sich der Windows Explorer mal abschauen). Ich sehe hier das Problem weniger im Design als in den Tools.
Unter den GUIs ist es bereits realität und in der Shell könnte man ein Tool schreiben das so arbeitet (und für diese eine eigene bash-completion). Wobei ich mir jetzt erst einmal rename anschauen muss

[Christian Steifen]

Linux-User schrieb:

Ein normaler User muss das nicht wissen (bzw. sollte es nicht wissen müssen).

Wenn der Benutzer ach so normal ist, dann soll er eben auch seine Finger von den Shells lassen...

[Ben04]

Also ich weiß ehrlich gesagt nicht, was an einem nicht löschendem rm so toll sein soll. Ich habe Win wesentlich länger verwendet als Linux und habe nicht gelernt den Papierkorb zu lieben. Um ehrlich zu sein nervt der mehr als er mir nützt. In all den Jahren habe ich ziemlich genau 0 Dateien da wieder ausgegraben. Da finde ich rm eigentlich toll so wie es ist. Wenn ich ein Backup will, dann nenne ich die Datei um und lösche sie halt nicht.

Entweder ich brauche die Datei vielleicht noch dann umbenennen oder ich brauch sie nicht mehr und lösche sie. Löschen und dann die Daumen drücken, dass das FS die Dateien doch nicht überschrieben hat ist Blödsinn.

[Mr. N]

Ben04 schrieb:

Wenn ich ein Backup will, dann nenne ich die Datei um und lösche sie halt nicht.

Oder du machst richtige Backups...

[nman]

Linux-User schrieb:

Wenn Du Verzeichnisse versioniert haben möchtest, dann pack sie doch in ein Versionskontrollsystem. Oder mach versionierte Backups.

Klar kann man das, aber es geht nicht automatisch.[/quote]
Doch, natürlich. TimeMachine macht das sehr hübsch, mein geliebtes man: rdiff-backup oä. bei Bedarf auch und für Git und Konsorten gibts auch fertige automatische Versionierungslösungen. Alle genannten Optionen sind wesentlich besser als die VMS-Versionierung es je war, auch wenn die VMS-Variante sehr elegant wirkt.

Was sind die Nachteile?

- Performancetechnisch war das katastrophal. Häufig hat man die Versionierung komplett abgeschalten und sie dann gezielt für einzelne Verzeichnisse wieder aktiviert, was auch nicht "automatischer" ist als die oben aufgezählten Lösungen.

- Du musstest die Anzahl von alten Versionen, angeben. Du wusstest also nie genau, wie lange die alte Version einer Datei wieder herstellbar ist. (Mit Git ist alles wieder herstellbar, mit TimeMachine alles, solange der Speicherplatz Deines Backupmediums reicht und mit rdiff-backup entweder auch die letzten n Versionen, oder - viel besser - alle Versionen der letzten m Wochen.)

- Teilweise war Files-11 ziemlich inkonsistent; Renames zB. waren immer wieder komisch und manches war einfach nur unintuitiv.

Diese Patches kenne ich, aber so wie ich gehört habe gibt es trotzdem noch Fälle wo Dateien gelöscht werden ohne, dass diese gepatchten Routinen das erledigen.

Nein, eigentlich funktionierte das ziemlich fein. Wie gesagt, da wurde damals wirklich die glibc zurechtgepatcht.

Allerdings passiert es einem in einer GUI nicht so leicht, dass man falsche Dateien löscht.

In einer vernünftig konfigurierten Shell auch nicht. Ich verwende zsh und lasse mir dort meine Wildcards beim Löschen immer per TAB inline expandieren. Wenn ich das vergesse und trotzdem ein Wildcard in Verbindung mit rm verwende, dann fragt mich zsh, ob ich mir sicher bin, dass ich das machen möchte.

Wenn man Midnight Commander oä. verwendet (empfehlenswert), stellt sich das Problem auch nicht.

Ok, die Snapshots sind nicht das Selbe wie Versioning, aber ein bischen helfen kann es trotzdem

Genauso sehr wie Git und die sonstigen oben genannten Alternativen.
(Nein, ich weiß schon, dass das praktisch wird, mag das bei ZFS ja auch sehr gerne. Habe dennoch zwei Einwände: 1. ist das auch nicht "automatisch" und 2. werden diese Dateisysteme gerade für ein Unix-Derivat entwickelt, offenbar ist das also nichts, was mit Unix konzeptionell unvereinbar wäre.)

Auf LWN.net findest du einen kleinen Artikel über LogFS: http://lwn.net/Articles/234441/

Hab ich irgendwann schon gelesen. Aber irgendwie kam mir das relativ tot vor und ich dachte, dass das primär für SSDs gedacht sei.

Ist mir schon klar, aber halt ein technisches Detail das hier leakt. Ein normaler User muss das nicht wissen (bzw. sollte es nicht wissen müssen).

Aber "normale User" verwendeten früher doch schon Midnight Commander & Co. bzw. verwenden jetzt eben GUIs.

Was findest du an Info so schlecht?

Ich finde einseitige, hübsch strukturierte Manpages mit Beispielen viel besser als Info, weil sie sich viel besser eignen um schnell mal was nachzulesen. Bei Info muss ich mich durch eine völlig überflüssige Hierarchie durchhangeln, die nur für "von vorne bis hinten alles vollständig durchlesen" passend ist.

Normalerweise tue ich das aber nicht, sondern möchte einfach nur eine schnelle Referenz, bzw. wenn ich etwas langes zu einem richtig komplizierten Stück Software lesen möchte, bevorzuge ich ohnehin PDF oä., weil sich das viel hübscher auf toten Baum bannen lässt und ich es auch auf Windows-Rechnern, Mobiltelefonen etc. gut lesen kann.

Wie kann es sein, dass du mit Emacs Info nutzen kann und ohne nicht? Das Kommandozeilen-Toll hat doch die gleichen Shortcuts

Trotzdem ist info(1) ein mieserabler Info-Browser und Emacs ein halbwegs akzeptabler Info-Browser. Du sagst doch selbst, dass Du Info erst verwendest, seit Du Emacs benutzt.

Bisher habe ich mir noch nie Gedanken darüber gemacht was an Unix schlecht ist, daher habe ich hier noch keine große Meinung dazu.

Das haben die Autoren des Unix Haters' Handbook IMO auch nicht, aber im Unterschied zu Dir geht es Ihnen offenbar nur um Herumgetrolle. Und das öfters zu wiederholen, macht es nicht richtiger und aktueller.

[Linux-User]

Ben04 schrieb:

Also ich weiß ehrlich gesagt nicht, was an einem nicht löschendem rm so toll sein soll. Ich habe Win wesentlich länger verwendet als Linux und habe nicht gelernt den Papierkorb zu lieben. Um ehrlich zu sein nervt der mehr als er mir nützt. In all den Jahren habe ich ziemlich genau 0 Dateien da wieder ausgegraben. Da finde ich rm eigentlich toll so wie es ist. Wenn ich ein Backup will, dann nenne ich die Datei um und lösche sie halt nicht.

Entweder ich brauche die Datei vielleicht noch dann umbenennen oder ich brauch sie nicht mehr und lösche sie. Löschen und dann die Daumen drücken, dass das FS die Dateien doch nicht überschrieben hat ist Blödsinn.

Es geht hier nicht um das alltägliche Löschen, sondern um versehentliches löschen, z.B. ein rm *.c statt einem vermeintlichen rm *.d

[Linux-User]

nman schrieb:

Linux-User schrieb:

Wenn Du Verzeichnisse versioniert haben möchtest, dann pack sie doch in ein Versionskontrollsystem. Oder mach versionierte Backups.

Klar kann man das, aber es geht nicht automatisch.

Doch, natürlich. TimeMachine macht das sehr hübsch, mein geliebtes man: rdiff-backup oä. bei Bedarf auch und für Git und Konsorten gibts auch fertige automatische Versionierungslösungen. Alle genannten Optionen sind wesentlich besser als die VMS-Versionierung es je war, auch wenn die VMS-Variante sehr elegant wirkt.
[/quote]
Das kannte ich noch nicht, werde ich gleich ausprobieren

Allerdings passiert es einem in einer GUI nicht so leicht, dass man falsche Dateien löscht.

In einer vernünftig konfigurierten Shell auch nicht. Ich verwende zsh und lasse mir dort meine Wildcards beim Löschen immer per TAB inline expandieren. Wenn ich das vergesse und trotzdem ein Wildcard in Verbindung mit rm verwende, dann fragt mich zsh, ob ich mir sicher bin, dass ich das machen möchte.

zsh wollte ich früher schon einmal verwenden, aber da gab es ein paar Dinge die ich bei bash habe und zsh nicht (dummerweise ist das schon recht lange her und ich kann mich nicht mehr daran erinnern, ich glaub da war was mit den Emacs shortcuts oder so). Kann zsh inzwischen Unicode?

Wenn man Midnight Commander oä. verwendet (empfehlenswert), stellt sich das Problem auch nicht.

Ok, die Snapshots sind nicht das Selbe wie Versioning, aber ein bischen helfen kann es trotzdem

Genauso sehr wie Git und die sonstigen oben genannten Alternativen.
(Nein, ich weiß schon, dass das praktisch wird, mag das bei ZFS ja auch sehr gerne. Habe dennoch zwei Einwände: 1. ist das auch nicht "automatisch" und 2. werden diese Dateisysteme gerade für ein Unix-Derivat entwickelt, offenbar ist das also nichts, was mit Unix konzeptionell unvereinbar wäre.)

In dem Fall ist das tatsächlich einigermaßen weniger relevant, aber für Backups sind die Snapshots schon praktisch, da kann man zu einem Zeitpunkt mit wenig Last (oder kurz in single user mode fahren) ein Snapshot erstellen und das Backup dann in Ruhe im laufenden Betrieb erstellen, ohne Angst für inkonsistenzen in Dateien haben zu müssen

Auf LWN.net findest du einen kleinen Artikel über LogFS: http://lwn.net/Articles/234441/

Hab ich irgendwann schon gelesen. Aber irgendwie kam mir das relativ tot vor und ich dachte, dass das primär für SSDs gedacht sei.

Ist es auch, aber finde es trotzdem interessant, weshalb ich es hier erwähnt habe.

Was findest du an Info so schlecht?

Ich finde einseitige, hübsch strukturierte Manpages mit Beispielen viel besser als Info, weil sie sich viel besser eignen um schnell mal was nachzulesen. Bei Info muss ich mich durch eine völlig überflüssige Hierarchie durchhangeln, die nur für "von vorne bis hinten alles vollständig durchlesen" passend ist.

Normalerweise tue ich das aber nicht, sondern möchte einfach nur eine schnelle Referenz, bzw. wenn ich etwas langes zu einem richtig komplizierten Stück Software lesen möchte, bevorzuge ich ohnehin PDF oä., weil sich das viel hübscher auf toten Baum bannen lässt und ich es auch auf Windows-Rechnern, Mobiltelefonen etc. gut lesen kann.

Wie kann es sein, dass du mit Emacs Info nutzen kann und ohne nicht? Das Kommandozeilen-Toll hat doch die gleichen Shortcuts

Trotzdem ist info(1) ein mieserabler Info-Browser und Emacs ein halbwegs akzeptabler Info-Browser. Du sagst doch selbst, dass Du Info erst verwendest, seit Du Emacs benutzt.

Das stimmt schon Der Hauptgrund warum man unter Emacs Info nutzen kann ist wohl C-h b um zu sehen wie man darin navigiert
Du kannst aber auch Info-Seiten am Stück lesen, einfach info node|less Oder mit -o einen gesamten Knoten in eine Datei umleiten. Also ich find es echt nicht schlecht, gerade libtool oder automake, da hab ich die Dokumentation direkt in Emacs sauber navigier- und durchsuchbar.
Für eine schnelle Übersicht, d.h. wenn man das Tool schon kennt hast du natürlich recht, da ist man schon besser. Gerade die system calls, da sind mir die man-pages schon lieber und mit woman in Emacs kann man die meisten ja auch in einem verlinkten Format anschauen.

So jetzt werde ich erst einmal The Art of Unix Programming lesen

[nman]

Linux-User schrieb:

Das kannte ich noch nicht, werde ich gleich ausprobieren

Lies insbesondere auch irgendwas zu Versionskontrolle mit Git; Pro Git zB. dürfte recht gut sein.

zsh wollte ich früher schon einmal verwenden, aber da gab es ein paar Dinge die ich bei bash habe und zsh nicht

Echt? Kann ich mir fast nicht vorstellen.

Kann zsh inzwischen Unicode?

Ja, seit 4.3.irgendwas.

In dem Fall ist das tatsächlich einigermaßen weniger relevant, aber für Backups sind die Snapshots schon praktisch, da kann man zu einem Zeitpunkt mit wenig Last (oder kurz in single user mode fahren) ein Snapshot erstellen und das Backup dann in Ruhe im laufenden Betrieb erstellen, ohne Angst für inkonsistenzen in Dateien haben zu müssen

Äh, Moment, halt: Angst vor Inkonsistenzen in Dateien habe ich sowieso nicht, weil alle auf rsync-basierenden Backup-Lösungen ziemlich Racecondition-frei sein sollten.
Was natürlich nix daran ändert, dass Snapshots toll sind und ich mich auf btrfs freue.

Du kannst aber auch Info-Seiten am Stück lesen, einfach info node|less

Ah, nett, das kannte ich noch gar nicht. Wobei sich "info gcc | less" jetzt auch nicht so prickelnd liest.

Also ich find es echt nicht schlecht, gerade libtool oder automake, da hab ich die Dokumentation direkt in Emacs sauber navigier- und durchsuchbar.

Wie gesagt, für Emacs-User geht das ja schon, ich hab ja auch meine SICP-Kopie im texi-Format, aber das ist doch eine ziemlich derbe Einstiegshürde nur zum Doku lesen.

So jetzt werde ich erst einmal The Art of Unix Programming lesen

Ja, tu das, das ist ein sehr feines Buch, das vieles an der Geschichte und Philosophie von Unix ein bisschen klarer werden lässt. Wobei sich in den letzten paar Jahren natürlich ein paar Sachen getan haben, die das Buch noch nicht berücksichtigt.

[nman]

Ach ja, falls Du zsh ausprobieren möchtest, hol Dir am besten das zsh-Setup von grml:

wget -O .zshrc http://git.grml.org/f/grml-etc-core/etc/zsh/zshrc

[u-ser_l]

Ben04 schrieb:

Also ich weiß ehrlich gesagt nicht, was an einem nicht löschendem rm so toll sein soll.

frage ich mich auch.

Mit

alias rm='/bin/rm -i'
alias cp='/bin/cp -i'

schützt sich der user vor der eigenen Schusseligkeit, wenn er sich zur
Angewohnheit macht, bei Nachfragen dieser Art die Zeile auch wirklich zu prüfen, ohne instinktiv "y" zu tippen.

Wichtige Dateiversionen kann man zB mit einem simplen Skript unter Anhängen des
Änderungsdatums an den Dateinamen in ein allgemeines backup-Vz kopieren.

Vorteil: nur die wichtigen Dateien werden aufbewahrt, Leerung überflüssig.