linuxinfoserver.de ---- hier geht es weiter

[netzmeister]

Hallo,

und hier geht es dazu weiter.

Wie blackbird es schon gesagt hat, jetzt fehlt uns nur noch http://www.linuxforen.de/ubb/wink.gif das DB-Modul und die Oberfläche.

Schaut Euch mal die Supportdatenbank von SuSE an, das ist gut gemacht, auch mit dem htsearch. <--- htdig http://www.linuxforen.de/ubb/biggrin.gif

Viele Grüsse,


Eicke

[Diese Nachricht wurde von netzmeister am 17. April 2000 editiert.]

[blackbird]

och das bisschen db und interface wird schonnoch http://www.linuxforen.de/ubb/wink.gif

gibts eigentlich schon genaure vorstellungen welche funktionen alle erfüllt sein sollten? das würd die suche nach ner lösung zum verwenden/abkupfern/wieauchimmer ja doch n bissl leichter machen.

ich denk mal das folgende sachen wichtig wären:
- gute suchfunktion (hehe) in etwa so gelöst:
suche nach stichwörtern (erweiterbarer stichwortkatalog), jedem artikel werden passende stichwörter zugewiesen, weiterhin volltextsuche in überschriften/artikel
ist mir natürlich klar das sich sowas leicht schreibt, und das da wohl die meiste arbeit drin steckt.

- eine benutzerverwaltung, ähnlich der sache hier.. moderatoren für die einzelnen themengebiete, welche auch für die neuen einträge zuständig sind. (perfekte gruppenarbeit: alle denken, der andre machts. http://www.linuxforen.de/ubb/wink.gif)
das sollte wohl nicht so wahnsinnig schwer werden

- und eine "navigationsoberfläche" durch die themen, also ne art baumstruktur. weil wenn man "nur" mit der suche an artikel kommt ist das nicht immer so einfach. vorallem für mich, ich such grundsätzlich nach den falschen begriffen - drum hab ich jetzt ne flatrate, da machts nicht so viel aus... -

ich denk mal dass das so die wichtigsten sachen sind.. wenn das soweit läuft kann man sich wohl gedanken machen, wie der rest ausschaun soll. wie die links gestaltet werden, wo die hinkommen etc..

jetzt viel spass beim zerpflücken meiner - zugegebner massen - hoch gesteckten ideen. aber wollen wir nur eine weitre HOW-TO sammlung ins netz schmeissen, oder wollen wir was richtig gutes machen http://www.linuxforen.de/ubb/biggrin.gif

in diesem sinne

viele grüsse&gutes gelingen!

blackbird

[Diese Nachricht wurde von blackbird am 17. April 2000 editiert.]

[Bernhard Koschnick]

Hallo Blackbird

Deine mail ist tatsächlich nicht angekommen. Ich hab jetzt mal testhalber mails von meinen referenzierten Links und über das Mail-Feld im Forenbeitrag an mich gesendet. Klappt UFB. Da scheint die Adress-Übermittlung schief gelaufen zu sein.

Null Problemo. Kannst mir ja die Referenz-URL auch im Beitrag posten.

Ja, mit dem Server wird es noch eine Weile dauern. Unseren Chef sollten wir momentan mit gar nichts konfrontieren. Absolute Power-Action im Betrieb. -- Oh, wie ich das jetzt bedauer, dass ich mich noch nie um Datenbanken gekümmert habe. Sowas lässt sich nicht in kurzer Zeit auschecken. Ausserdem fehlen praktisch noch sämtliche Anhaltspunkte zum Scriptgerüst. Können wir nicht im Team einfach mal einen Weg "rausdeuten"? Ich denk mir, wenn alle Mitmach-Interessierten mal einen Vorschlag machen, sollten wir den Rahmen auch erarbeiten können. Beispiele sind ja tonnenweise im Netz zu finden. An den Konzepten fällt sofort auf, was gut ist und wo man doch gerne andere Wege beschreiten möchte. Wenn das, was wir rausknobeln gut ist, wird unser Chef http://www.linuxforen.de/ubb/wink.gif es auch akzeptieren können. Er will ja ohnehin nicht alles alleine rausdeuten. Wär doch echt ein guter Gag, wenn wir ihn mit 'ner handfesten Vorarbeit überraschen könnten.

Und ehrlich: Wo ich hinschaue, sehe ich genügend ähnlich aufgebaute Konzepte. Nur diese Fakt-Form, die mit möglichst wenig kompaktem Text Sachverhalte möglichst komplett und praxisgerecht darzustellen versucht, hab ich eigentlich noch nicht entdeckt. Und ohne die nachträglich entstandene Idee, deutsche man-pages endlich mal möglichst komplett unter Einbeziehung der aktuellen Quellen incl. konkreter Praxisbeispiele zu schreiben -- Energie und Zeit liessen sich vorteilhaft in bereits bestehende Projekte investieren. Schon bemerkenswert, dass es etwas gibt, das es im Netz zumindest in dieser Form noch nicht oder fast nicht gibt. Ich mach halt weiter mit dem, was momentan geht: Seiten ausarbeiten. Ich hab inzwischen wieder einige fertig, gerade hatte ich die crontab beim Wickel. Mit Kopieren ist da nicht viel zu machen. Die man-pages geben einfach zu wenig Informationen her. Wenn ich nur die "Bandwurm"-Syntax sehe. Ich übernehm sie halt jetzt mal parallel, weiss aber noch nicht, ob die überhaupt noch zeitgemäss ist. - Aktuelle Literatur präsentiert dagegen eine klare und praxiskonforme Syntax. Oberdrein weiss sie eine Fülle weiterer Details zu den Programmen zu berichten. Da kommen mir die man-pages manchmal so richtig "altmodisch" und irgendwie roh und auf die Schnelle zusammengepfrimelt vor (sorry, die Meister haben wirklich unglaubliches geleistet. Wo wären wir heute ohne sie? Doch die komischen Zahnräder drehen sich weiter. Sie benötigen hin und wieder ein paar Tropfen Öl http://www.linuxforen.de/ubb/biggrin.gif ). - Man wird sehen, wo die Zukunft hintendiert...

OK, genug Gequassel. War ein wenig als Appetithäppchen gedacht. Unter 1 400 Mitgliedern befinden sich noch etliche, die vom Erstellen des "Rahmenwerkes" was verstehen. Vielleicht findet der eine oder andere doch noch Interesse, und packt getreu alter Linux-Tradition ohne viel zu fragen einfach mit an?

Gruss

Bernhard

[Ilja]

hallöle.

ich hatte heut mal etwas zeit und dachte mir ein db-konzept aus. ok es ist zwar nicht das grösste aber es müsste für unsere zwecke ausreichend sein.

db: mysql
www: php3

2 tabellen:
groups & entrys

aufbau groups:

id -> int not_null autoincrement
name -> char(40)
description -> memo
parent -> int

aufbau entrys:

id -> int not_null autoincrement
name -> char(40)
description -> memo
keywords -> memo
groups -> array of int ???

mit diesen beiden tabellen hätten wir das "gerüsst" in einer db und dir eigentlichen daten in einer anderen db. dadurch wird ein eventuelles "neu-anordnen" der sammlung relativ einfach. ausserdem ist durch parent in groups die möglichkeit gegeben eine baum-struktur aufzubauen.
bsp.: netzwerk -> isdn&modem -> pap/chap.

das einzige was mir bis jetzt noch im dunklen steht ist die möglichkeit eines int-array's bei mysql. sprich ein eintrag aus entrys steht in mehreren gruppen. so ist es vorstellbar, dass der cat-befehl in den verschiedensten gruppen auftauchen könnte. und nicht nur dieser befehl.

die aufmachung der w3-site aus diesen daten geschieht dann mit php3 und kann individuell gestaltet werden. aber ich glaub' soweit waren wir schon http://www.linuxforen.de/ubb/wink.gif

das wäre mein vorschlag. verbesserungen, anregungen bzw. konstruktive kritik ist erwünscht.

gruss
ilja

[Bernhard Koschnick]

Na wenn das kein richtiger Osterhase ist... http://www.linuxforen.de/ubb/cool.gif

Hallo Ilja

Da steht 'ne leckere Bibliothek hintendran, wenn der Aufbau so klar geschrieben werden kann. Das ist ja wesentlich mehr als eine einfache Datenverwaltung. Für unsere Zwecke soll das allemal gut sein. Die leichte Wartbarkeit ist ein wichtiges Argument.

Also wird das Interface in PHP3 geschrieben. Zum Einstimmen für weitere Interessierte hier ein paar deutschsprachige URLs: http://www.php-center.de/ http://www.php-homepage.de/source/ http://www.dynamic-webpages.de/ http://ffm.junetz.de/privat/reeg/DSP/ .

Vorab mal 'ne Frage: Formatierten HTML werden wir sicher nicht eingeben können? Vermutlich muss alles, was schon besteht, als Text dargestellt und mit Formatanweisungen versehen werden? Wäre ja in dem Fall Blödsinn, wenn ich hier wie gehabt, weiterschreibe. Das sollte ich also mal explizit wissen. Villeicht entdecke ich ja auch die Hinweise in den URLs.

Vorschlag zur file-Struktur:

In der obersten Ebene lagert globales wie Index, Themenübersicht, Linkliste, Grafik usw.

Eine SubDir für die Programmbeschreibungen. Weitere Unterteilungen nach Sachgebieten halte ich nicht für sinnvoll. Besser ist alphabetischer Aufbau. Wenn das Dir mal gut ausgelastet ist, können alphabetische SubDirs gebildet werden. Könnte aber auch sinnvoll sein, gleich die Struktur aufzubauen. Es würde sicher reichen, wenn drei bis fünf Buchstaben zusammengefasst werden.

Ein zweites SubDir beherbergt alle übrigen Info-Themen und wird von Anfang an nach Sachgebieten wie Allgemein, Hardware, Netz, X-Window usw. eingeteilt. Für neu geschaffene Themen, wie z.B. Installation wäre dann sofort ein neues SubDir anzulegen.

Mal sehen, welche Ideen noch beim Lesen auftauchen.

Bernhard

[Ilja]

nabend bernhard.

zur verzeichnis-struktur:
ich dachte mir das so, dass ein php3-script anhand der db's die entsprechenden html-sites beim aufruf generiert. je nachdem, welche gruppe aufgerufen wird bzw. welche such-anfrage gestellt wird. alternativ könnte man die ganze geschichte auch so gestalten wie bei diesem ubb-forum. dort werden nach jedem neuen eintrag die html-seiten in automatisch angelegten sub-dirs aktualisiert bzw. neu angelegt. ist eigentlich ein recht guter gedanken-ansatz. so ist die html-sammlung immer auf dem neuesten stand und es muss sich keiner gedanken um die genaue directory-structur während der laufzeit machen. einfach pro groups-eintrag ein sub-dir mit allen html-sites (evtl. nur aufgerufene?) erstellen und fertig.
sollte ich jetzt ein denkfehler haben, dann bitte berichtigen.

gruss
ilja

[Diese Nachricht wurde von Ilja am 19. April 2000 editiert.]

[Manfred-B]

Hallo!
Also jeder der Linux lernen will wird sich wohl ein paar notes machen so auch ich. (Bernhard hat das mal angesprochen und beklagt)
Aber diese Anfängerweisheiten sind doch in dieser Form ungeeignet für eine Infosammlung von Welt http://www.linuxforen.de/ubb/wink.gif Darum glaube ich, es ist das aller wichtigste einen Rahmen vorzugeben für diesen input!
Denn was wäre ein Basar ohne Stände ? - Ganz einfach: Eine Sammlung ohne Inhalt; oder sollen wir es wie die eM$igen machen - zuerst mal die Verpackung drucken, der Inhalt zwar ist bugy ?
Dies ist nicht böse gemeint, im Gegenteil.
Wichtig wären schnelle download Möglichkeit um auf dem neusten Stand zu sein auch diff wenn's größer wird
und wie gesagt ein Rahmen um infos zu posten damit keiner mehr mit seinen Notes hinterm Berg bleibt!
In diesem Sinne - es lebe der Basar
http://www.linuxforen.de/ubb/smile.gif

Gruß Manfred

[Bernhard Koschnick]

Hi Ilja

Im Prinzip wird es egal sein, in welcher file-Strukzur die Daten abgelegt werden. Wichtig ist aber, dass die Links immer stimmen, egal ob online gebrowst wird oder nach dem (zip-)gepackten download offline. Das wird am einfachsten zu realisieren sein, wenn bereits in der DABA die file-Struktur vorhanden ist. Dein Beispiel mit dem ubb-forum sollte also wohl favorisiert werden.

Ich hab zum Download übrigens noch ein "Feintuning" im Kopf. Zum lokalen Aktualisieren muss nicht immer alles komplett geladen werden. Beim ersten Download könnte ein text-file lokal gespeichert werden. Dieser kann die ausgewählten Rubriken oder sonstigen Kriterien enthalten, muss aber nicht. Auf jeden Fall ist er händisch editierbar und wird vor dem download eingelesen. Am Ende des files steht ein Datum. Der file wird nicht überschrieben sondern das aktuelle Datum wird angehängt oder vorangestellt. Der User müsste das Dir diese files zum download nur übergeben. Alternativ kann der file auch in der DABA gespeichert werden, wenn der User es gestattet. Nun kann der Server den Auftrag erhalten, alles, was nach diesem Datum ergänzt wurde, zu verpacken und zu senden. Wenn der (zip-)file dann im lokalen Stammverzeichnis der Sammlung entpackt wird, aktualisiert er durch Überschreiben gleich in der richtigen file-Struktur.

Und aufrufen kan man das ganze lokal z.B. mit dem Befehl: "hilfe" auf der Kommandozeile (oder via Icon):

------------------------------------------------
#!/usr/bin/bash
#
kfmclient folder /c/Eigene/Hilfe/html/index.htm;
------------------------------------------------

Die Gestaltung des Aufrufs ist kein Problem. Schneller ist Hilfe nicht verfügbar.

Ist genau so leicht gesagt, wie die Volltext-Suche, die Blackbird vorgeschlagen hat. Es sollte sich aber realisieren lassen. Die Foren verfügen z.B. auch über eine starke Suchmaschine. Die könnte ggf. als Muster dienen. Vielleicht lässt sich auch für die Aktualisierungsroutine ein brauchbares Muster finden.

---Ideen wären noch genug. Aber das will auch alles aufgearbeitet sein. Also erst mal weiterlesen und knobeln...

Gruss
Bernhard

[Bernhard Koschnick]

Da kommt ja allmählich richtig Leben in die Bude http://www.linuxforen.de/ubb/cool.gif

Manfred,

Dein Posting ist Gold. Dein Argument kannte ich noch nicht. Für mich ist alles wichtig, was Information ist. Der Starter benötigt das Handbuch, danach kommen Literatur, Links und Foren. Der Versierte wird nur noch gelegentlich nachschlagen müssen, was er nicht ständig braucht. Vom Prinzip her besteht also kein Unterschied, der Informationen irgendwelche Qualität zuweisen könnte.

Wenn eine Quality-DABA nicht "user@sonne> ls -l /etc/ppp" supporten soll, wird sie auch schweigen, wenn es um "user@sonne> kpanel -no-KDE-compliant-window-manager" geht. Sie wird auch nicht verraten, was "00 */2 * * * root /usr/local/bin/mail_poll" bedeutet. Oder wo ist die Grenze? Nur ein paar willkürliche Beispiele.

Quality ist meiner Auffassung nach ein gut ausgearbeitetes Konzept. Dabei ist es egal, ob es sich um ein einzelnes Thema dreht, ob in Buchform dem Einsteiger breites Wissen vermittelt wird, das ihn nach und nach zum Fortgeschrittenen werden lässt oder, wie in unserem Falle um einen breit gestreuten Markt, der möglichst viele Themen eher kompakt behandelt - also für möglichst jeden User als Nachschlaghilfe dienen kann. Alle drei Grundformen bedürfen sorgfältiger Recherchen und Ausarbeitung. Sie taugen nichts, wenn überall nach "banalen" Bestandteilen vergeblich gefahndet wird.

Sollen wir uns deshalb vom Konzept her beschränken? Das breit angelegte Konzept wird noch eine Weile original in den Kinderschuhen stecken. Wenn aber viele User entdecken, dass die scheinbaren "Unwichtigkeiten", die sie eigentlich gar nicht beitragen wollten, das Ganze erst mit Leben füllen, kann diese Zeit schnell überwunden werden. Immerhin orientieren sich verschiedene User auch an verschiedenen Sachthemen. Was für den einen Peanuts ist, kann für den anderen wochenlange Fahndung bedeuten, wenn er sich spontan für dieses Thema interessiert und umgekehrt.

Das Konzept selbst braucht meiner Ansicht nach nicht konkretisiert werden. Es bietet jedem User die bestmögliche kretive Freiheit. Meine Aufschreibungen waren z.B. erst die bescheidenen Möglichkeiten der $Win-Konfiguration aus Zeitschriften. Bald folgten tonnenweise Quellcode-Beispiele aus den $Win-Borland-Foren, die ich niemals so schnell aufarbeiten konnte, wie sie reinkamen. Jetzt unter Linux macht das Sammeln erst richtig sinn. Ich hab genau wie wohl fast alle mit "Banalkram" begonnen... Lass ich diese "Peanuts" weg, wird der Rest nicht folgen. Nie werde ich die HP mit der Start-Sammlung basteln. Nie wird unser Netzmeister nach der Möglichkeit fahnden, Server und DABA zur Verfügung zu stellen. Nie werden wir in MBytes, gespickt mit den leckersten Infos und wertvollsten URLs rumstöbern können. -- Ist natürlich übertrieben gesagt, um das Bild besser darstellen zu können.

Wenn das immer noch nicht reicht, schau Dir villeicht mal die bereits ausgearbeiteten Programmbeschreibungen an - exclusive der Teilchen, die ich inzwischen wieder local vorbereitet habe. Vielleicht findest Du eine bessere Lösung. Das soll dann das Konzept für die Programmbeschreibungen sein...

...Oh, ich soll einfach hier aufhören. Ich hab ohnehin mehr weggelöscht, als stehengeblieben ist. Das Thema macht einfach fun und gibt zuviel Stoff her http://www.linuxforen.de/ubb/biggrin.gif .

Das Spezialforum wird sicher kommen. Lass unseren Netzmeister erst mal den Giga-Knoten im Betrieb entwirren. Gönn ihm noch eine reichliche Zeit und eine sonnigen Hang mit gutem Auf- und Gegenwind (oder hab ich die kurzen Worte im Posting falsch gelesen?).

Gruss
Bernhard

Hi

Wie wär's mit folgendem Tabellenvorschlag?:

[b]Mustertabelle für Indexe:

CREATE TABLE HIndex (
Letters VARCHAR(2),
IndexLetters VARCHAR(2),
Dir VARCHAR(10),
Datum DATE,
PRIMARY KEY(ID)
);

[b]Mustertabelle für die Texte:

CREATE TABLE Progs (
IndexGroup VARCHAR(2),
Index VARCHAR(110),
ProgGroup VARCHAR(2),
ProgIndex VARCHAR(10),
Text TEXT,
Dir VARCHAR(10),
Datum DATE,
PROGID INT NOT NULL AUTO_INCREMENT,
PRIMARY KEY(ID)
);

[b]Tabelle Linkliste:

CREATE TABLE Links (
LinkGroup VARCHAR(25),
LinkUGroup VARCHAR(25),
LinkIndex VARCHAR(100),
LinkText VARCHAR(250),
Dir VARCHAR(10),
Datum DATE,
LINKID INT NOT NULL AUTO_INCREMENT,
PRIMARY KEY(ID)
);

Aber wie geht das mit Iljas Grundaufbau zusammen? Ich finde dazu einfach keine Anleitung. Über die Variable "Dir" kann das Verzeichnis festgelegt werden, (egal, was die DABA intern damit macht). Wahrscheinlich stecken auch noch Verständnisfehler drin. Aber wo was ist, kann auch dran gebastelt werden. Die Tabelle für die Themenübersicht wäre dann auch gleich geschrieben.

Wenn der Teil mal klar ist, kämen Eingabe und Abfrage dran.

Christoph, hast Du's auch gesehen?: mysql ist relational http://www.linuxforen.de/ubb/biggrin.gif .

Und für morgen: Frohes Ostereiersuchen
Bernhard

[Diese Nachricht wurde von Omega-X am 22. April 2000 editiert.]

[Ilja]

mahlzeit.

wieso so umständlich? die zwei tabellen oben müssten meiner ansicht nach vorherst ausreichend sein. ok ich versuch das ganze mal zu erklären. aber vorsicht: mein pädagogisches geschick tendiert gegen null http://www.linuxforen.de/ubb/wink.gif

die lis sollte hierarisch aufgebaut werden. dazu die groups-tabelle. in der obersten ebene haben alle einträge parent=0 sprich keine unterordnung. die zweite ebene, für jeden eintrag der ersten ebene, erhält als parent die id des entsprechenden eintrages aus der ersten ebene usw. die anzahl der ebenen kann dabei von fall zu fall variieren. so kann zum biespiel ein eintrag der ersten ebene nur eine unterebene besitzen wohingegen ein anderer eintrag 5-10 (nach oben offen) unterebenen besitzt.
damit sollte das "gerüsst" stehen. ähnlich wie www.lycos.de (http://www.lycos.de) zum durchklicken.

die eigentlichen infos stehen in der entrys-tabelle. alle in einer einziegen. die einordnung in entsprechende gruppen der og. tabelle geschieht durch das feld groups. wobei dieses entweder genau eine oder mindestens eine gruppe enthält.

je nachdem in welcher gruppe man sich zur zeit befindet wird dann auf die entrys-tabelle ein


select * form entrys where entrys.groups = groups.id from groups, entrys


gemacht.

verzeichnis-struktur:
angefangen im / mit index.html geht es dann von gruppe zu gruppe beispiel:


/index.html
/group1/group1/entry1.htm
/group1/group2/entry2.htm
/group2/entry3.htm
/group3/group1/group1/entry4.htm
...


wie oben schon erwähnt wird die verzeichnisstruktur und die html-dateien beim hinzufügen, ändern bzw. löschen eines beitrages erstellt, angepasst bzw. gelöscht.

zum download der lis:
eventuell ein script, welches aus den beiden tabellen unter verwendung der scripts zum anzeigen der lis eine .tar.gz-datei erstellt mit allen verzeichnissen, unterverzeichnissen und html-dateien angefangen von /

so. ich hoffe, dass das jetzt einiegermassen vernünftig rüberkam.

in diesem sinne
ein frohes eier-fest


------------------
gruss
ilja (http://www.andreasr.de)

Hi

OK. Demnach muss eine Tabelle beim creieren nicht als Array fest angelegt werden. Wusste ich nicht. Allerdings kann ich das immer noch nicht in ein praktisches Denkmodell umsetzen.

Beispiel einer Eingabe-mail:

Buchstabengruppe im Index : "in" /* kann ggf. automatisch generiert werden */
Indexeintrag: "Indexeintrag"

Buchstabengruppe im Index : "an" /* kann ggf. automatisch generiert werden */
Indexeintrag: "Anderer Indexeintrag"

Buchstabengruppe im Index : "no" /* kann ggf. automatisch generiert werden */
Indexeintrag: "Noch ein Indexeintrag"

Eintrag in die Themenübersicht : "Themen(unter)eintrag"

Weitere Einträge in den GruppenIndex nach dem Muster für Index, aber ggf. andere Einträge. Übernahme (Gleichsetzung) soll möglich sein.

HTML-Text : "Endlich kommt das, was den Leser interessiert: Der (hoffentlich) informative Text."


Der Ersteller will alles miteinander verlinken. Er will auch Querverweise zu anderen Texten schaffen. Ihm müssen also konkrete Dir- und FileNamen bekannt sein. Mit dem groups/entrys-Modell darf er nicht direkt konfrontiert werden, denn dann müsste er ja zwei Ordnungssysteme beachten. Ausserdem ist eine groups/entrys-Structur abstrakt. Niemand kann sich das merken. EDV-Mitarbeiter sind speziell geschult. Hier müssen wir das möglichst offizierssicher machen. Sonst wird das nichts.

Übrigens, Auch der Index erhält von vornherein Structur. Am Anfang ist alles ein file, später wird sinnvoll gesplittet. Nur der Buchstabe "A" oden "Aa" bleibt immer index.html. Auf ihn zielen die Rüchverweise. Wie wäre das Lösungsmodell?

Herrliches Wetter hier im Rheintal

Bernhard

[Ilja]

mahlzeit omega-x.

nun versteh' ich endlich, wo unser problem liegt. mit meiner db-struktur ist es natürlich nur schwer möglich innerhalb eines eingabetextes ein link zu setzen. das könnte man durch einen algorithmus ermöglichen, der die eh zu programmierende suche-funktion benutzt, um "verwandte" postings anzuzeigen. das kann natürlich in einer liste am ende oder am anfang des postings geschehen.

zur eingabe der daten: eine mail-eingabe habe ich in meinem denkmodell ausser acht gelassen. vorrangig würde alles online über eine schnittstelle laufen. müsste man sich vielleicht nochmal ein wenig gedanken machen zu dem problem. jedoch fällt das bei diesem herrlichen wetter extrem schwer http://www.linuxinfoserver.de/ubb/cool.gif



------------------
gruss
ilja (http://www.andreasr.de)

[Pingu]

Hi Leute,

ich wollt mich nur mal kurz einmischen:

Ilja: als kleine Empfehlung würde ich bei den Tabellen mind. noch eine Spalte für Timestamp einführen. Eigentlich sogar zwei.

CREATE ...
...
row_update TIMESTAMP,
row_create TIMESTAMP,
...;

Die erste Timestamp-Spalte wird von mySQL automatisch aktualisiert. Damit hat man dann immer die Information, wann der entspr. Eintrag das letzte mal aktualisiert wurde. Mit der zweiten Timestamp-Spalte hätte man die Info wann der Eintrag das erste Mal kreiert wurde; muß aber von Hand eingetragen werden.

Das ganze hat z.B. den Sinn, wenn einer 'ne Spiegelung (egal aus welchem Grund) machen möchte oder für Backup-Spiegelung, denn dann ist immer eindeutig, wie aktuell der Eintrag ist.

Nur so als Idee zu verstehen, da mySQL dies leider noch nicht automatisch unterstützt.

Gruß

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-= Pingu =-

[Ilja]

mahlzeit.

"einmischen" erwünscht http://www.linuxinfoserver.de/ubb/wink.gif

die idee mit den timestamp-feldern ist net übel. dadurch könnte die suche-funktion ebenfalls profitieren. zb: zeige nur neue postings seit letztem besuch an. (natürlich mit cookie-unterstützung) etc.

mal merken ;-)



------------------
gruss
ilja (http://www.andreasr.de)

Hi Ihr Knobelspezialisten

Ilja, zu Deiner Frage: "e-mail als Eingabeweg". Zu Eickes Vorschlag gibt es keine Alternative, da wir ja direkt HTML auf die DABA packen. Den Mangel beim Quoting in Texteingabefelder haben wir ständig bei den Forenbeiträgen.

In die Beispiele, die Du genannt hast, kann ich leider nicht (scrptseitig) reinschauen. Ich bin hier schon Tage am Denkmodell knobeln. --> Ein Problem ist, dass ein file nicht unendlich lang werden kann. Z.B.: Es werden fleissig Infos zum Thema "Netzwerk" eingereicht. Das SubDir könnte ./netz heissen (legt man die Hauptthemen wie netz, x-window usw. in SubDirs, wird das auch für die Zukunft optimal sein). Der file hiesse z.B. ../config.html. Wenn aber genügend Themen hier zusammenkommen (Grössenordnung so bei 40 - 50 Kb), muss gesplittet werden. Den Zeitpunkt weiss der User nicht, der einfach nur mal ein einzelnes leckeres Thema beisteuert. Aber er muss die Links richtig schreiben. Im Grunde haben wir so etwas ähnliches wie die einzelnen Foren mit ihren Beiträgen. Nur kommen noch der Inex und die Verlinkung dazu. Das macht die Sache schwierig. Auch das voll relationale Modell, dass ich so aus dem Steggreif vorgestellt habe, kann das Problem nicht allein handeln.

Wir brauchen Vorschläge ohne Ende, um dieses harte Problem in den Griff zu bekommen. Eine Möglichkeit wäre, es wird ein Forum geschaffen, dass von einem Admin unterhalten wird. Der müsste die file-Struktur im Auge haben und diese aktuell posten, sobald eine Änderung sinnvoll ist. Er würde dann statt des files ../config.html den file ../config1.html bekannt machen. --

-- Vielleicht lässt sich das auch über ein Kontrollscript automatisch regeln. Wenn die Basis ../config ist, könnte dieses die file-Grösse bestimmen und ggf. eine fortlaufende Zahl und die Endung anhängen. In Folge verwendet es dann den file mit der letztkreierten Zahl als Checkbasis. Es müsste "nur" den Eintrag in den Index.Links ändern.

Pingu, Diene beiden Variablen sind Pflicht!! http://www.linuxinfoserver.de/ubb/biggrin.gif im Tabellen-Array. Und sag bitte nicht mehr: "Einmischen" http://www.linuxinfoserver.de/ubb/rolleyes.gif . So ein Projekt wird doch im Team erst richtig lecker. Dabei wären wie übrigens wieder beim relationalen Muster. Ich denke, nur so lässt sich alles in Einklang bringen. Das file-Gerüst wird einmal vernünftig aufgebaut und kann jederzeit erweitert werden. Das Kreieren der Tables kann übrigens bei neuen Themenkomklexen automatisch geschehen. Ein Script muss nur suchen, ob der Themen-Name vorhanden ist. Wenn nicht, wird eine neue Tabelle kreirt. Sie ist nach dem einheitlichen Muster gestaltet und erhält nur den neuen Table-Namen. Die ID's werden aus TableName + ID gebildet.

Falls wir uns auf dieses Grungmuster einigen könnten, fehlte "nur" noch das Scriptgerüst. Ob sowas machmar ist?

Gruss

Omedga-X

[Manfred-B]

Es sollte besser keine ewige Baustelle werden http://www.linuxinfoserver.de/ubb/wink.gif
Leider kann ich hier nicht so ganz mitreden - mangels db u. html Kenntnisse
Also die Möglichkeit einer Eingabe durch E-Mail halte ich nicht mehr für sinnvoll
Ebenso, daß jetzt HTML Pflicht sein soll: Um eine einheitliche Formatierung der
Sammlung zu erzielen muß doch das system selber formatieren.
Ist es nicht sinnvoller dem Input-Gebenden eine Maske (das meinte ich mit Rahmen s.o.) zu liefern,
die er/sie ausfüllen kann? Damit wäre eine Fehlerqulle schonmal ausgeschoßen. Auserdem kann nicht
jeder der z.B. die Bash kennt auch HTML - auch wenn es HTML Editoren gibt - das einheitliche Format
bliebe doch auf der strecke.
Das könnte dann eine universal Maske werden mit auswahlmenues; nur als Beispiel:

Kategorie (Komandos; Shellsyntax; Konfigfiles; Programme; Systeminfos; Peripherie; Netzwerk; Internet; ... )
darraus dann z.B.
Konfigfiles (fstab; route.conf; lilo.conf...)
unterkategorien sollte "jeder" erstellen können
Dann könnte man buttons platzieren, klickt man sie an öffnet sich eine Maske die man mit z.B. einer Überschrift füllen kann
Eine Tabelle müsste auch gehen
Ein button für die Komandozeile
Eins für die beispiele
...
Und ein button welches markiert, daß hier noch eine Baustelle ist - Hilfsbereite bräuchten so nicht lange nach denen zu suchen
Ein linkauswahlmenue um die Sammlung in sich mit Querverweisen zu verlinken

Vieleicht hab ich mich jetzt doch etwas zu weit über die Reling gebeugt?

Bernhard:
>die begrenzung der Dateigröße
Warum?
ok angenommen es werden wirklich mal fleißig Infos zum Thema Netzwerk eingereicht
dann sind es doch wohl Infos von verschiedenen Informanten - sommit sind es doch auch mehrere files
zu warscheinlich unterschiedlichen Unterthemen falls nicht kann das system einen link anhängen zur nächsten Seite


Jeder der Korrekturen, Ergänzungen, Fehlermitteilungen, Beispiele, neue Beitäge, oder auch ganz wichtig - das geschriebene so wie es ist bestätigen will muß
zugang zum Server erhalten. Mit Password - aber nur damit das System speichern kann wer es war. Korrekturen müssen erlaubt sein; der Autor kann seinen Beitrag
mit seinem Password direkt ändern... jeder Andere sollte es indirekt auch können; er klickt an die Stelle welche er ändern möchte, und erhält ein Formular
vorgefüllt mit dem original Infotext
Also das mit dem "das geschriebene bestätigen" könnte auch so eine Art Rückversicherung sein - ist es von Mehreren bestätigt worden, kann es als richtig gelten und so das Betastadium verlassen
Ja, alles leicht gesagt http://www.linuxinfoserver.de/ubb/smile.gif
Also ich geh' jetzt schon mal in Deckung vor dem Echo - hoffendlich lebt der Basar!

Manfred

Hi Manfred

Feldeingabe wäre an und für sich ein einfacher zu handelnder Weg. Aber wenn ich mir die unterschiedlichen Postings so anschau ... sobald am Zeilenende des schmalen Eingabefeldes die Entertaste bedient wird, wird ein Zeilenwechsel eingefügt. Im Forenbeitrag ist das OK. Aber im Infotext einer DABA? Viele Beitäge müssten nachbehandelt werden. Wer will sowas stupides übernehmen?

e-mail quotet im Hintergrund. Zumindest fett, Farbe, Überschrift und Link sollten möglich sein, ggf. sogar Tabellen. HTML-Seiten lassen sich anhängen. Wer es schreiben kann oder in einem guten HTML-Editor (bluefish, asWedit...) quoten lässt, kann gleich das Layout beurteilen.

Vielleicht sollten beide Möglichkeiten zur Verfügung stehen.

>> die begrenzung der Dateigröße
> Warum?
Aslo ich steh auf blitzschnell ablaufende Prozesse. Geh z.B. mal in selfhtml (/usr/doc/selfhtml) ins Stichwortverzeichnis. Selbst auf einer schnellen Maschine hat das mit seinen 93,1 KB deutliche Ladezeit. Ich denke, wenn man so ein System anlegt, soll es nicht nur für Monate gut sein sondern auf Jahre hinaus konzipiert sein - natürlich auch leicht wart- und änderbar. MAn führt am kontrollierten file-Splitting kein Weg vorbei.

Ähnliches gilt für die Verzeichnisgrösse. Ich erinner mich noch gut an meine Startzeit. Die Grafikkarte war noch nicht supportet. Also nur erstmal Loginshell. Grosse Verzeichnisse konnte ich nicht mehr bis zu Anfang durchscrollen...

> sommit sind es doch auch mehrere files
Das wäre sicher utopisch. Genügend Infos werden nur wenige Zeilen haben, also nicht mal 500 Bytes. Die Allround-Inodengrösse kann mit 4 KB angenommen werden. Wir würden zu recht gegrillt werden http://www.linuxinfoserver.de/ubb/biggrin.gif .

Vor der Möglichkeit, dass jeder korrigieren kann, muss gewarnt werden. DABA-Admins haben üblicherweise nur eingeschränkte Befugnisse. Weitergehende Befugnis sollte nur haben, wer sich wirklich auskennt. Änderungen betreffen aber nur die weitere Pflege. Der erste Weg soll ja nicht in die DB selbst sondern in ein Vorbereitungsforum gehen. Das gibt die Sicherheit. Auch weniger erfahrene User können nach Herzenslust mitwerkeln.

Aber bis dahin ist der Weg noch weit. Wohl alle, die mitmachen, haben in dem Bereich noch nicht gearbeitet. Es soll sogar User geben, die haben sich extra für dieses Projekt Fachliteratur zugelegt http://www.linuxinfoserver.de/ubb/wink.gif , http://www.linuxinfoserver.de/ubb/cool.gif . Vielleicht gibt es im Hintergrund User, die nicht nur schmunzeln sondern mal so'n kleines Pik-As ausspielen http://www.linuxinfoserver.de/ubb/wink.gif ?

Gruss aus dem Dreiländereck

Bernhard

[blackbird]

hi mal wieder http://www.linuxinfoserver.de/ubb/wink.gif

- inzwischen bin auch ich wieder aus dem biergarten zuhaus angekommen... -
ich bin auch umbedingt dafür, keine formatierten texte in die db zu schreiben, dafür ist sie meines erachtens ja da. aus folgenden gründen:
<ul> einheitliches design: alle navigations-buttons, kopf- und fusszeilen werden automatisch eingebaut</li> banner: ich denke auf jeder seite sollte auch ein banner zu sehen sein, also muss das auch wieder automatisch eingefügt werden. dabei sollte auch sicher gestellt werdne, dass jede seite zumindest im kopfbereich gleich ausschaut (wie´s hier zb auch ist).</li> einfachere handhabbarkeit: fällt zwar wieder in richtung design, aber egal. sollte man sich mal entscheiden, das design zu ändern, muss man nur die maske hierfür ändern, nicht jeden db-eintrag von hand! das erspart wirklich einiges..</li> platzersparnis: wozu sollt ich auf jeder seite die allgemeinen teile immer wieder einbinden, schluckt ja nur unnötig platz in der db, und das geht auch wieder auf die performance</li>und noch was: egal auf welchen weg man die daten eingibt, man wird immer ein script brauchen, welches das überprüft.. sei´s jetzt wegen den umlauten, welchen überprüft werden müssen oder wegen was auch immer. das muss auf alle fälle rein.</li>[/list]

omega-x, wegen den links innerhalb der dokumente: ich denke da gibt es wieder 2 möglichkeiten. entweder wir müssen uns echt was einfallen lassen, wie wir jedes dokument nennen, um dann jeweils darauf verlinken zu können (da wirds mit der zeit echt schwer, sich sinnvolle namen auszudenken http://www.linuxinfoserver.de/ubb/frown.gif ) oder im dokument werden bloss "interne" links gesetzt. dieser wird dann durch den endgültigen link vor auslieferung des dokumentes ersetzt. beleibt bloss die frage, wie man das hinterher verlinken will, wenn hunderte themen zu einem themengebiet vorhanden sind. also wer dann noch weiss, was wo drinsteht...
oder man muss eben doch gleich auf das dokument verlinken, allerdings halt über ein php-script, welches dann bei jeder anfrage die daba abfragt (vieeeel ram zum zwischenspeichern http://www.linuxinfoserver.de/ubb/wink.gif ) linux.php?level1=2&level2=5&level3=3&id=[fiktiverdateiname|ordnungs-id]
das wäre - nach meiner vorstellung - ein link auf ein dokument in der ebene 2-5-3. und darauf könnte man auch immer wieder verlinken, egal was sich da noch tut. ausser die daba wird komplett umgeschmissen, aber wer tut sich das an..

wegen dem weg der dokumenten-eingabe:
ich denke das kann man über beide wege machen.. entweder per formular mit entspechenden helpern (button für kommandozeile etc) oder per mail.
wie gesagt, ich denke ein script muss auf alle fälle drüberlaufen, bevor ein beitrag aufgenommen werden kann.

ich stell man eben dar, wie ich mir den weg eines dokuments vorstell:
<ul> das dokument wird per formular/mail an das system übergeben, ein script formatiert das dokument unsren ideen entsprechend. zb umlaute &amp;uuml;berprüfen. alle farbinformationen rausnehmen (die kommen später wieder rein)...</li> als nächstes wird das dokument in die daba geschrieben, entsprechend dem angegebenen index. hierbei wird dann evtl noch eine id automatisch erzeugt, falls doch keine fiktiven dateinamen verwendet werden. </li>dadraufs könnte man dann auch gleich eine liste der neuen dokumente erstellen, nur mal so als nebengedanke. ein dokument wird abgerufen: das php-script holt sich den entsprechenden eintrag aus der daba, formatiert wieder, also farben, hintergrundfarben, tabellenoutfit, aktuelle buttons, banner etc werden an den vorgesehenen stellen eingefügt und das dokument ausgeliefert.</li>

ich hoff mal dass mich zumindest ein paar leute mit meinen ideen verstanden haben http://www.linuxinfoserver.de/ubb/wink.gif

grüsse blackbird

[christophwth]

Hi
blackbird das hört sich für mich schon ganz vernüftig an. So habe ich mir das auch schon vorgestellt. Aber wie man so was realisiert
weis ich leider nicht . PHP ist dann wohl das
Stichwort. Einlesen per mail. Überschrift übernehmen Index zuordnen.
Dann meine Frage ist es möglich die verschiedenen Bereiche Normaltext, Beispiele
Skripte bzw. Links in die richtigen Bereiche
zu bringen. D.h PHP basiert das Maildokument
in seine Bestandteile zu zerlegen.und dabei
eine Tabelle anzulegen die speichert wo die
Inhalte abgelegt wurden.

Das ganze mal an einem Beispiel von Bernhard
T = Normaltext
S = Skript
H = Headline
C = Code
usw
damit wären ohne Sonderzeichen 24 verschiedene Bereiche möglich

Tabelle:
+--------------------------+--------------------+
|Allgemeines zu Headerfiles| H1,T1,S1,T2,S2,T3 |
+--------------------------+--------------------+

--------------------------------------------
Allgemeines zu Haederfiles (H1)

Include-Anweisungen veranlassen den Praeprozessor, den Text aus der zu inkludierenden Datei an der Stelle des Befehls
einzusetzen. Alle Einbindungen, die mit der Raute "#" beginnen, sind Praeprozessoranweisungen. Der Praeprozessor ist ein
etwas fortschrittlicheres Textprogramm mit der Aufgabe Text zu suchen, zu ersetzen und zu verbinden.

Headerfiles werden meistens in mehreren Dateien benoetigt. Um Doppeldefinitionen und -Deklarationen zu
vermeiden, staht am Beginn jedes vernueftigen Headerfiles folgende Define-Anweisung:

// Wenn dieses define noch nich definiert ist
(T1)
#ifndef __STDIO_H
// definiere es
#define __STDIO_H
(S1)
Statt der doppelten Unterstriche könnten auch einzelne vorhanden sein. Es hat sich aber eingebürgert, interne
Defines mit Doppelunterstrich zu beginnen. So sind sie besser von eigenen Defines zu unterscheiden. Das H
am Ende sagt, dass es sich um einen Haederfile handelt.

In dieser Form richtig aufgebaute Haederfiles können somit über die Include-Anweisung
(T2)
#include <stdio.h>
(S2)
in mehrere Projekt-Quelltexte eingebunden werden, ohne dass auf mögliche Doppeldeklarationen geachtet
werden muss. Die richtige Auswahl triff der Praeprozessor.

Erst, nachdem die Arbeit des Praeprozessors getan ist, übernimmt der Compiler dann die Umwandlung in
Binaercode. Am Schluss stellt der Linker alle vorgesehenen Verbindungen zwischen den Modulen her. Wenn
auch dieser seine Arbeit erfolgreich beenden konnte, ist ein lauffähiges Programm entstanden.

Die Abläufe des gesamten Compilierungsablaufs im einzelnen:

a) Praeprozessor
b) Compilieren
c) Assemblieren
d) Linken
(T3)
---------------------------------------------
So , ich denke mit dieser Unterteilung währe
es z.B. möglich z.B nur im Bereich Code zu suchen wenn z.B jemand einen Standartbefehl eingibt
Beim Schreiben merke ich jetzt aber auch das das evtuell noch nicht ganz ausreicht.
Ich weiß auch nicht welche Rechenleistung der
Server haben müßte um so was bei einer Anfrage bereitzustellen. zu mal das Dokument
ja wieder rückwärts aufgebaut werden müßte

Das waren mal die Überlegungen die ich mir so gemacht habe.
vielleicht liege ich aber auch total falsch. und man kann das Ganze besser
und übersichlicher machen.
Vorteil dieser Gliederung für die Html Formatierung ist es möglich
einfach zu sagen alle Sachen die aus dem Bereich H kommen werden mit
Attribut Fett und Farbe sowieso dargestellt usw.

Gruss
Christoph

Oha, langsam werden die Probs eingekreist.

blackbird, Du kannst das Groups/Entrys-Modell scheinbar umsetzen. Bin gespannt, wie die Steuerscripten aussehen. (Kannst vielleicht mal ein kurzes Beispiel [für die Doofys {its me}] posten?).

Christoph, MAn sollte Quellcode normal aber in Schriftart mit fester Breite dargestellt werden. Die Fragmente können dann direkt in den Editor kopiert werden. Die farbige Syntax-Hervorhebung wird so unterstützt.

Hier mal ein Muster für den Formular-Aufbau. Kritik ist erwünscht. Genauso kann die Eingabe über e-mail erfolgen. Nur müssen statt der Buttons noch Kürzel geschaffen werden.

Die e-mail lässt sich genauso vorbereiten: Auf dem Server liegt die Muster-e-mail und wird angefordert. Der erklärende Text ist über ein weiteres Kützel :E: gekapselt und braucht vor dem Absenden der ausgefüllten Antwort nicht gelöscht werden.

<HR ALIGN=LEFT WIDTH="100%"><form action="eingabe.phtml" method=post>Autor:
Thema:<input type=submit value="erstellen">* <input type=submit value="korrigieren">

**Lektor:
Thema:<input type=submit value="korrigieren">**
Kommunikation:
<input type=submit value="e-mail an den Autor"><input type=submit value="e-mail an den Lektor">

Für die Textauszeichnung stehen folgende Kürzel zur Verfügung:
**C = Code
**H = Headline (Include- und Define-Einbindungen in Quelltext)
**K = Kommentar (Eigene Erfahrung, Anregung)
**L = Link
**LT = Text, der für den Link angezeigt werden soll
**O = Programm-Option (Erste Spalte der Optionen-Tabelle)
**OT = Erklärung zur Programm-Option (Zweite Spalte der Optionen-Tabelle)
**S = Skripttext
**T = Normaltext
**U1 = Überschrift
**U2 = Unter-Überschrift
**U3 = Weitere Unter-Überschrift
**W = Warnung


Alle Kürzel können beliebig oft und in beliebiger Reihenfolge eingesetzt werden. Für die leichtere Auffindbarkeit der Information wird es oft sinnvoll sein, mehrere Index-Einträge (z.B. in verschiedener Wortreihenfolge) vorzusehen.

Links erscheinen normalerweise mit ihrem Linktext. Wenn LT nicht explizit gesetzt wird, wird der Link selbst als Linktext genutzt.

Jede Benutzung der Enter-Taste fügt einen Zeilenwechsel ein. Bitte die Enter-Taste nur einsetzen, wenn ein Zeilenwechsel auch erwünscht ist.

Muster für die Schreibweise im Formular:

:L:
X-Window mit Tastenkombination beenden
:L:
Tastenkombination - X-Window beenden
:U1:
X-Window mit Tastenkombination beenden
:T:
Mein Infotext


/* Ich hab nur den Befehl für ein einzeiliges Feld gefunden. Es soll aber möglichst Screenhoch
sein. */

Texteingabe:
<input name="feld1" size=40 maxlength=255>
<HR ALIGN=LEFT WIDTH="100%">

Bin gespannt, wie sich die Quotung jetzt darstellt http://www.linuxinfoserver.de/ubb/biggrin.gif .

Bernhard

[Diese Nachricht wurde von Omega-X am 03. Mai 2000 editiert.]

[blackbird]

wir sollten mal wieder ein neuen beitrag aufmachen, so langsam wirds unübersichtlich, und die downloadzeiten für den thread werden selbst bei isdn bemerkbar...

omegaX hat mich nach nem script gefragt, wie das ausschaun könnte..
da kann ich leider nicht viel zu sagen, ich kann mich nur auf grundlegende bash-kenntnisse berufen, leider http://www.linuxinfoserver.de/ubb/frown.gif

aber egal welche sprache wir wählen, ob perl für cgi oder eben php, sollte die gewünschte funktionalität ja nicht sonderlich aufwändig sein. im prinzip brauchen wir ja nur folgende elemente:
- für die ankommenden beiträge eine löschung sämtlicher html-tags bzw insbesondere der farbinformationen (ist noch ein diskussionspunkt, ob wir einfach html verwenden und nur bestimmte elemente rauslöschen, oder einen eignen code verwenden, zb ähnlich dem ubb-code hier im forum...)
- ebenfalls für die ankommenden beiträge: ersetzung aller sonderzeichen in html-konforme zeichen. einfaches suchen&ersetzen, eigentlich nicht der rede wert, oder etwa doch?
- dann eine formatierung bei der ausgabe. einmal hinzufügen der allgemeinen daten aus der vorlagendatei (links[hyper- http://www.linuxinfoserver.de/ubb/wink.gif] oben und unten, anker für top, banner, logo etc...). und eben wieder das hinzufügen der farbinformationen entsprechend dem "corporate design" wie´s so schön auf neudeutsch heisst, oder die umsetzung unsres codes in html. wobei das in den meisten fällen auf suchen&ersetzen rausläuft. (suche code, ersetze durch pre und, suche /code ersetze durch /pre, etc..)

omegax, probier doch mal statt input type=text mit size=xx und maxsize=xx ein textarea rows=xx cols=xx und zwar ohne input type=! natürlich ist das ein normales tag und muss auch wieder geschlossen werden.
alles, was zwischen dem eröffnenden und dem schliessenden tag steht, erscheint als vordefinierter text im mehrzeiligen textfeld und kann überschrieben werden.

das war doch das, was du gesucht hast http://www.linuxinfoserver.de/ubb/wink.gif

grüsse blackbird

[Diese Nachricht wurde von blackbird am 07. Mai 2000 editiert.]

[Diese Nachricht wurde von blackbird am 07. Mai 2000 editiert.]

[Manfred-B]

Hi
Omega-X, Deine Maske kommt gut! ... Aber mir scheint sie hat uns alle die Sprache verschlagen? http://www.linuxinfoserver.de/ubb/wink.gif oder doch nicht?

Zu dem verlinken der Sammlung: Diese Arbeit kann vieleicht der PC erledigen?: wenn ich in meinen notes was suche verwende ich grep

Um nach mehreren begriffen in /var/spool/wwwoffle/http/ zu suchen : # braucht man öfters: Ich hab da mal was gelesen; wo war das blos?
for i in $(find /var/spool/wwwoffle/http/www.linuxforen.de | xargs grep -il "$1" | xargs grep -li "$2") ; do cat ${i%/*}/U${i##*/D};echo ; done
dabei sind die parameter $1 und $2 ... durch den suchstring zu ersetzen!
Das selbe (nur besser) soll auch mit htdig gehen ... man muß nur noch die sinnvolle Fundstelle isolieren diese arbeit kann man auf mehrere Schultern verteilen wenn man eine entsprechende option in die maske integriert

Gruß Manfred