Re: ein kleines bash toot für den webserver

Autor: Robert Schiele (rschiele_at_uni-mannheim.de)
Datum: 19. Feb 2004


On Thu, Feb 19, 2004 at 08:37:30PM +0100, Thomas Groß wrote:
> Ok,
> das hier ist die letzte email die ich zu diesem Thema schreibe da du ja
> anscheinend ins sinnlose polemisieren gefallen bist.

Bin ich das? Na, mir macht es jedenfalls Spass.

> On Thu, 2004-02-19 at 19:47, Robert Schiele wrote:
> > On Thu, Feb 19, 2004 at 06:35:34PM +0100, Thomas Groß wrote:
> > > On Thu, 2004-02-19 at 17:40, Robert Schiele wrote:
> > > > Schwachsinn! Wir sind uns einig, dass / auf den meisten Sytemen ein
> > > > Verzeichnis ist, oder?
> > > Ach schön, dass hier immer alle so freundlich sind.
> >
> > Moegliche Antworten auf diese Frage waeren "ja", "nein" oder "weiss nicht"
> > gewesen.
> Dass sich meine Anmerkung auf den Schwachsinn bezieht hättest auch du
> merken können.

Stimmt. Jetzt wo du es sagst.

> > Du kannst es auf einem Linux-System nicht testen, weil unter Linux read(2) das
> > Lesen eines Verzeichnisses nicht erlaubt. Das ist keine Frage der Tools.
> Das mag sein. Hat aber doch wenig damit zu tun ob man das nun bloß weil
> man unter BSD mit read Verzeichnisse lesen kann das auch auf die
> Benutzerebene hinaufreichen muss.

Man muss ja nichts reichen. Das passiert automatisch, indem man einfach
_nichts_ tut.

> Ich habe den Begriff Kompatibilität sehr wohl verstanden. Wenn ich nicht
> davon ausgehen kann, dass zwei Programme gleichen Namens sich auf zwei
> Systemen gleich verhalten dann sind sie für diesen Fall nicht
> kompatibel. Ob es für die Anwendung ein vernünftiges Szenario gibt ist

Falsch! Sie sind genau dann kompatibel, wenn sie einen gemeinsamen Standard
korrekt implementieren. Vielleicht wird das am Beispiel eines C++-Compilers
klar: Wenn zwei C++-Compiler jedes korrekte C++-Programm gemaess dem
C++-Standard uebersetzt und jedes offensichtlich inkorrekte C++-Programm
abweisst, dann sind sie kompatibel. Wenn du allerdings ein
nichtdeterministische C++-Programme uebersetzt, so duerfen die von den
Compilern erzeugten Programme sich auch unterschiedlich verhalten. Ein
kompatibler C++-Compiler darf die Uebersetzung sogar verweigern, wenn er den
Nichtdeterminismus "nachweisen" kann.

> da vollkommen egal. Wer weis vielleicht gibt es ja eins, man ist blos
> noch nicht drauf gekommen. Vielleicht solltest du dir mal überlegen ob
> dein Kompatibilitätsbegriff nicht ein wenig an der Definition vorbei
> ist.

Habe ich oben grade nochmals frisch ueberlegt.

In diesem Zusammenhang bleibt uebrigens noch zu erwaehnen, dass ein cat,
welches auf BSD die Verzeichnisse nicht liest, inkompatibel waere, weil der
Standard das Lesen aller Files beschreibt.

> Ich kann mir genug Fälle vorstellen wo sich Skripte auf einmal anders
> verhalten wo sie es nicht müssten blos weil jemand ein Unterverzeichnis
> irgenwo angelegt hat. Hab mal ein wenig Fantasie.

Dann musst du das fehlerhafte Skript fixen.

> > Na, beim open(2) mit Schreibberechtigung ist eine Pruefung technisch
> > erforderlich, um die Konsistenz zu garantieren, beim read(2) hingegen
> > nicht. BSD minimiert also in dieser Hinsicht unnoetige Pruefungen.
> Das mag sein. Ist auf dieser Ebene vielleicht auch sinnvoll, obwohl man
> sich da sicher auch streiten kann. Warum dieses Verhalten dann aber bis

Natuerlich kann man das. Was denkst du, was wir hier die ganze Zeit tun?

> zum User durchgereicht werden soll steht wieder auf einem anderen Blatt.
> Insbesondere bei Tools die nicht dafür gedacht sind, dass sie auf dem
> Inhalt von Directories arbeiten.

Dem replace-Tool kann es doch vollkommen Wurst sein, worauf es arbeitet.
Entweder es geht, oder es geht halt nicht. Wenn man das kuenstlich
beschraenkt, und irgendjemand erfindet mal was, dass dies technisch doch
irgendwie gehen sollte, dann wuerdest du dich aergern, wenn das Tool fuer
diesen Fall nicht funktioniert.

> > > Verzeichnisse sind einfach was anderes als normale Files oder auch FIFOs
> > > oder device files. Und da sie was anderes sind kann man sie auch anders
> > > behandeln.
> >
> > Klar, man koennte auch eine Registry fuer Konfigurationsdaten einfuehren.
> Äh, was soll das bedeuten?

Weil du behauptest, Verzeichnisse seien etwas anderes als normale Dateien.
Vielleicht solltest du mal die Designdokumente von Hans Reiser zu seinem
Filesystem lesen, dann wuerdest du vielleicht erkennen, dass dies nicht so
sein muss.

> > Doch, sie entfernt durch eine Pruefung Moeglichkeiten, ohne dabei einen
> > Vorteil zu bringen oder einen Nachteil zu beseitigen. Also sinnloser Code.
> Nein ist es nicht, weil es auf der Benutzerebene verhindert, dass dem
> Benutzer Fehler unterlaufen die nicht sein müssten.

Haeh? Es kommt hoechstens eine _andere_ Fehlermeldung, wenn etwas nicht geht!

> > > würde viel eher fragen:"Was macht es denn für einen Sinn das zu können?"
> >
> > Mir faellt keiner ein. Aber wenn jedes Programm Code enthalten muss, um das zu
> > verhindern, dann macht dies alle Programm komplizierter, ohne das du einen
> > Vorteil davon hast.
> Den Vorteil habe ich eben erklärt.

Der erklaerte Vorteil ist in einem einheitlichen Namespace aber halt kein
Vorteil, sondern ein Nachteil. Nur weil du jetzt glaubst, etwas waere sinnlos,
solltest du das nicht verbieten. Bill Gates hat auch mal geglaubt, es wuerde
niemals jemanden geben, der mehr als 640KB Arbeitsspeicher hat. Weil das bei
IBM auch ein paar Leute geglaubt haben, haben sie den IBM-PC so gebaut, wie er
heute ist. Was das unter DOS spaeter fuer Verkrampfungen hervorgerufen hat,
hat der eine oder andere gemerkt.

> > Das ist wieder Schwachsinn: Einerseits behauptest du, eine derartige
> > Moeglichkeit wuerde nie benoetigt werden, andererseits dann aber wieder, das
> > Programm wuerde sich unberechenbar verhalten, wenn man es so aufruft. Wenn du
> > diese Moeglichkeit aber nie benutzt, dann kann sich das Programm doch auch bei
> > dir nie unberechenbar verhalten.
> Erstens kann es durchaus mal vorkommen, dass man etwas unabsichtlich
> aufgrund eine Versehen oder Anwendungsfehler benutzt. Dann sollten Tools
> meine Erachtens möglichst versuchen sinnlose Aktionen nicht zuzulassen.

Nun, ich denke halt, man sollte Theologie und Betriebssysteme unabhaengig
voneinander betrachten. Ob eine Aktion sinnlos ist oder nicht, ist eben eine
Frage der Betrachtungsweise.

Beispiel: Ein einfaches Backupprogramm fuer BSD-Systeme kann alle Inodes
kopieren und dann Indizes erstellen, indem er die Verzeichnisse mit cat oder
einem aehnlichen Programm auf das Backupmedium in einen Index schreibt. Das
ist zugegebenermassen eine sehr ungewoehnliche Loesung, und ich wuerde das nie
so implementieren. Aber es zeigt, dass man Anwendungsfaelle konstruieren kann.
Und wo man das kann, da taucht irgendwann auch mal ein ernsthafter auf.

> Zweitens dürfen sich Programme in Anwendungsfällen die normalerweise
> nicht vorkommen sollten trotzdem nicht unberechenbar sein. Sionst sind
> sie einfach schlecht.

Es ist nicht unberechenbar. Es haengt nur von den Faehigkeiten des Systems ab.

Sonst waere uname ja auch unberechenbar. Es gibt auf jedem System was anderes
aus.

> Wenn man um das Verhalten weis kann man natürlich den Anwendungsfall
> vermeiden. Aber in diesen Fall gibt es vielleicht keinen, also braucht
                                         ^^^^^^^^^^

Aha! Erkennst du das Problem?

> man es doch auch nicht zuzulassen.

*seufz*

> > Nein, aufregen wuerde eh nichts nuetzen. Es ist auch nicht schlimm, wenn das
> > jemand nicht weiss. Bedenklich wird es erst, wenn jemand sagt, weil er das
> > nicht kenne, muesse man es unterbinden.
> Ich habe nicht gesagt men müsse unterbinden weil ich es nicht kenne. Du
> solltest manchmal vielleicht weniger interpretieren und mehr lesen.

Vielleicht.

> > Faellt mir keine ein, wobei letzteres auch nicht geht. Aber wie bereits
> > gesagt, es gibt auch keinen Nachteil, und wenn man das eh nicht tun will, ist
> > es doch egal, ob es geht oder nicht.
> Nein ist es nicht. Aber da werden wir wohl keine Einigung kriegen.

Wenn du deine Meinung nicht aenderst wohl kaum.

> > > Zu deiner vielgelobten orthogonalen Tool Implementierung: Klar ist eine
> > > Abstraktion eine gute Sache. Aber Abstraktion die als Selbstzweck
> >
> > Die Abstraktion ist kein Selbstzweck, sie macht den Code einfacher wartbar.
> Dazu kann ich nur sagen: Wenn man verschiedene Dinge gleich behandelt,
> die nicht gleich sind hat man die Abstraktion einfach zu weit getrieben.

Du kannst halt deren Gleichheit nicht erkennen. Lies am besten gelegentlich
mal die Dokumente von Hans Reiser.

> Ich habe gesagt es ist ein Fehler auf Verzeichnissen Aktionen zuzulassen
> die keinen Sinn machen. Das hat sich wiederum nicht auf die Systemebene
> bezogen sondern auf die Tool Ebene.

Hmm, das ist dann halt kein UNIX mehr. UNIX basiert halt auf einem
Schichtenmodell, bei dem man in den ausseren Schichten Moeglichkeiten der
inneren Schichten nicht wegwirft, sondern hoechstens erweitert.

> Hast du dir auch mal überlegt, dass es vieleicht gute Gründe gibt warum
> Linux nicht zulässt, dass man Verzeichnisse lesen kann? Vielleicht steht

Ja, weil die Linux-VFS-Implementation dir nicht garantiert, dass eine
physische Repraesentation des Verzeichnisses existiert. BSD nacht das anders.
Das bietet dir die physische Repraesentation an, wenn sie existiert, und sonst
halt nicht.

> ja dahinter, das man den Filesystemlayer einfach nicht zumuten möchte,
> dass er für jedes Verzeichnis einen Bitstream erzeugen muss, egal wie es

??? Muss es doch gar nicht. Das Verzeichnis steht bei normalen Filesystemen
auf der Platte.

> physikalisch abgelegt ist. Das würde nämlich sowohl den virutellen
> Filesysem Layer als auch jede Filesystemimplementierung verkomplizieren.

Das Lesen von Bloecken verkompliziert das Filesystem? Ich dachte, das koennten
die meisten bereits.

> Achtung ich sage nicht, dass das der Grund ist. Falls es so wäre, wäre
> das aber ein gutes Beispiel dafür wie überflüssige Abstraktion an einer
> Stelle Schwierigkeiten an einer anderen Stelle erzeugt.

Wenn das so kompliziert waere, haette das ja auch niemand gemacht. Ist aber ja
nicht so.

> > Die Tatsache, dass man ein Verzeichnis mit read(2) lesen kann macht dir das
> > Leben schwerer? Solange du sonst keine Probleme hast...
> Dazu sag ich jetzt nix mehr.

Dann mach ich das auch nicht.

> Ich weiß, dass Windows einen POSIX Kompatibilitätslayer hat. Wenn deine

_hatte_

> Unix Programme sich also an die POSIX Konventionen halten dann sind sie
> auch relativ einfach zu portieren. Das machen allerdings die wenigsten

Nun ja, weil die Arbeit von Microsoft schon gestemmt wurde. Aber irgendwann
wurde denen das offenbar zu viel.

> Programme und die großen Portierungsprobleme treten dann halt da auf, wo
> sich die Programme nicht nur auf POSIX verlassen. Wenn alle Unix
> Programme nur POSIX Funktionalität benutzen würden, dann bräuchten wir
> so was wie die GNU autotools wohl eher nicht, mal abgesehen davon, dass

Doch. Es gibt auch optionale POSIX-Features.

> wir dann wohl auch keine graphischen Oberflächen hätten. Oder willst du
> Windows zum Vorwurf machen, dass es keine X Bibliotheken und ähnliches
> gibt?

Wenn ich die Windows-GUI-Library direkt benutzen muesste, dann wuerde ich das
wohl tun.

Robert

-- 
Robert Schiele			Tel.: +49-621-181-2517
Dipl.-Wirtsch.informatiker	mailto:rschiele_at_uni-mannheim.de



Dieses Archiv wurde generiert von hypermail 2.1.7 : 19. Feb 2004 CET