Hallo,
Schöner Wohnen kann man ja seit vorgestern schon in Dresden, aber schöner Verzeichnisse und Dateien auflisten, das ist noch nicht so bekannt. So geht's: [Achtung: KDE-Alarm - dieses muß ab Version 2.0 von CVS installiert sein - siehe unten]
1. Aua, das tut weh, aber es muß sein: Umbenennung von /bin/ls nach /bin/old.ls.
2. Perl muß installiert sein, wenn nicht, entweder installieren oder über den 1. Schritt fluchen. Anschließend in einen Editor seiner Wahl gehen und auf Copy&Paste vorbereiten.
3. Einfügen in /bin/ls und entsprechend anpassen:
#!/usr/bin/perl $BASE = "/home/josef/KDE2.2/kdelibs/kio/tests"; $arg = "@ARGV"; $syscall = "ls.old $arg"; @comp = split(/\ /, $arg); foreach $c(@comp){ if($c =~ m/tar:/){ $c =~ s/tar://; $syscall = "$BASE/ktartest list $c"; } } print "KIO::execute: $syscall\n"; #debug system($syscall);
4. Entsprechend erweitern. Geübte Unixer werden zwar "gzip -cd x.tar.gz | tar -t | less" kennen, aber eine Standard-API für die Konsole ist doch besser - und es reicht vor allem zu, immer das innerste Protokoll bei Verschachtelungen anzugeben. Also z.B. "ls tar:whatdoyoucontain.tar.bz2". Und bei erweiterten Sachen wie ls -la pop3://ich:**@myhost/myaccount könnte so ein kleines Skript seine Stärken voll ausspielen. Oder wie wäre es, "cp" zu ersetzen - etwa für "cp ftp://host.com/mymp3track.tar.gz cdburner:/mymp3track", also live CD's brennen über FTP bei hinreichend schneller Verbindung und automatischer Dekompression?
5. Weil die KDE-Libs normalerweise nicht für die Konsole ausgelegt sind, muß man dafür kleine Hilfsprogramme schreiben, allerdings würde vielleicht schon eins ausreichen. Sowas wie wget oder scp hätte dann für die einfachen Fälle ausgedient. Wozu auch für alles das Rad neu erfinden, sind schließlich alles normale Dateioperationen.
6. Braucht das jemand? Würde es (einfache) Fälle geben, wo das IO-Slave-Konzept nicht anwendbar wäre?
Josef Spillner
On Fri, Aug 17, 2001 at 10:36:49PM +0200, Josef Spillner wrote:
- Entsprechend erweitern.
Geübte Unixer werden zwar "gzip -cd x.tar.gz | tar -t | less" kennen, aber eine Standard-API für die Konsole ist doch besser - und es reicht vor allem zu, immer das innerste Protokoll bei Verschachtelungen anzugeben. Also z.B. "ls tar:whatdoyoucontain.tar.bz2".
...
zu ersetzen - etwa für "cp ftp://host.com/mymp3track.tar.gz
...
cdburner:/mymp3track", also live CD's brennen über FTP bei hinreichend schneller Verbindung und automatischer Dekompression?
Man müsste sich zuerst mal eine gescheite Notation ausdenken, bzw. schauen, ob es sowas schon gibt. Das Beipiel mit "cp ..." ist OK. Das Bsp. mit tar: ist aber blöd.
Jemand, der sagt "cp tar:whatdoyoucontain.tar.bz2 cdburner:/track1" will wahrscheinlich nicht das Listing des tars auf der CD haben sondern das _file_ whatdoyoucontain.tar oder whatdoyoucontain.tar.bz2.tar.
Die Position von Daten kann man über URIs spezifizieren - das ist klar. Du versuchst oben aber durch das "tar:" eine Operation auf dieses Objekte mit in den "Pfad" zu kodierenm also ein implizites 'gzip -cd|tar -t' und das ist - zumindest in dieser Notation - nicht sinnvoll. Wer die URI-Notaion im Hinterkopf hat, darf bei "cp tar:whatdoyoucontain.tar.bz2 ..." einen fehler erwarten, da das Ziel "whatdoyoucontain.tar.bz2" nicht kompatibel zum Protokoll "tar" ist.
_Operationen_ auf Objekte müssen also so gestaltet werden, daß sie mit dem Namensraum zur Angabe der _Position_ dieser Objekte (also URIs) nicht kollidieren.
Ein einfaches "tar" als Aktion kann nie ausreichen, um tar -x, tar -c und tar -t zu verstecken. Wenn man "tar" auf abc.tar anwendet, wird man nur _sehr_oft_ abc haben wollen, aben eben _nicht_immer_. Es kann genauso sein, daß dieser Mensch abc.tar.tar haben wollte und das _muß_ möglich sein. Software "intelligent" zu machen geht oft auf Kosten der Funktionalität.
- Weil die KDE-Libs normalerweise nicht für die Konsole ausgelegt sind, muß
man dafür kleine Hilfsprogramme schreiben, allerdings würde vielleicht schon eins ausreichen.
Ich nix Ahnung von KDE
Sowas wie wget oder scp hätte dann für die einfachen Fälle ausgedient. Wozu auch für alles das Rad neu erfinden, sind schließlich alles normale Dateioperationen.
Ja, das sehe ich aus so.
Ich würde wohl erstmal nur den ersten Schritt versuchen zu realisieren: URIs in der Kommandozeile analog zu files nutzbar machen. Das wäre wirklich ziemlichpraktisch.
Also etwa gzip -cd ftp://x.y.de/x.ps.gz | lpr grep news:eine_msgid Subject: echo "Bring mal bitte ein Bier" > partner:
Für alles andere (also alles abseits der standardisierten URIs) muß man sich erstmal eine schlaue Benamsung ausdenken. Momentan denke ich allerdings, daß eine neue Notation für das was ich oben "Operationen auf Objekte" genannt habe, wenig sinnvoll ist. Der Grund ist ganz einfach: Komplexe Unix-Kommandozeilen enthalten relativ wenig Redundanz. Damit ist wenig Spielraum zur Optimierung da und leserlicher wird die Sache garantiert nicht. Du kannst dich höchstens auf häufig verwendete Operationen beschränken und diese sehr kurz kodieren. Für Leute, deren Wortschatz auch mit 50 noch genau dem der Fibel entspricht, ist das DIE Lösung.
- Braucht das jemand? Würde es (einfache) Fälle geben, wo das
"Brauchen" ist sicher übertrieben. Wer keine Kommandozeile/Skripte nutzt wird es auch dann nicht tun.
Der größte Haken an deiner Überlegung ist aber, daß du das aufgeblähte KDE als Basis nehmen willst. Andersrum wäre es besser: Schreib eine minimale Umgebung, die die Behandlung von URIs als Files erlaubt und laß die KDEler das Ding dann auch für ihre Zwecke nutzen.
Der generische Ansatz sowas im Unix zu realisieren wäre, die URLs auf ein Filesystem abzubilden. Also sowas wie /uri/http://server/seite.html Das wäre doch ziemlich genial, oder? Ich möchte wetten, daß das schon mal jemand gemacht oder wenigstens versucht hat.
Reinhard
On Sat Aug 18, 2001 at 11:07:33 +0200, Reinhard Foerster wrote:
Der generische Ansatz sowas im Unix zu realisieren wäre, die URLs auf ein Filesystem abzubilden. Also sowas wie /uri/http://server/seite.html Das wäre doch ziemlich genial, oder? Ich möchte wetten, daß das schon mal jemand gemacht oder wenigstens versucht hat.
http://uservfs.sourceforge.net/ http://www.goop.org/~jeremy/userfs/ http://www.penguin.cz/~jim/userfs/ http://members.ozemail.com.au/~mccormack/userfs.html ...
und fuer UML ist wohl auch sowas geplant...
Adam
lug-dd@mailman.schlittermann.de
-
Adam Lackorzynski -
Josef Spillner -
Reinhard Foerster