Ganz normal: Du muß wissen, wie das Programm heißen soll, das du
benötigst. Das mußt du aber sowieso, denn du willst es ja auführen.
Heißt das Programm z.b. "zgrep" so müßte ein "ll /usr/bin/zgrep" es
finden, wenn es sich dort befindet. Da es nur wenige Verzeichnisse geben
kann, wo das Proggi sein könnte (/usr/bin, /bin, /usr/local oder /opt
bei einer Standard-Installation) führt das recht schnell zum Ziel.
Ein Script-Profi (ich bin keiner) schreibt selbst komplexere Abfragen
dieser Art in wenigen Zeilen.
Schau dir mal die DLDADMIN-Sachen DLDADMIN oder PKGISTALL an. Das sind
alles Scripte.
Im Pfad /usr/lib/delix/setup/ finden sich die meisten.
StarOffice bzw. andre kommerzielle Programme enthalten alle
Install-Scripte, die teilweise recht simpel aufgebaut sind.
(Bei StarOffice war es sogar mal ein und dasselbe Script für alle
UNIX-Versionen...)
Ich habe neulich Civilization - Call to Power hier auf der DLD
installiert. Das geht über ein Tcl/Tk-Script, und funktionierte
einwandfrei.
> > man das auch in der RPM-Datenbank abfragen..incl. Pfade, wo es sich
> > befindet.
> > Dazu ist RPM nämlich auch da....
>
> Mit welchem RPM-Befehl, wenn der Programmierer von nicht feststehenden Paket-
> Namen ausgehen kann ? (Bin für jedwelche Hilfe dankbar, da pgpk --version
> unendlich langsam ist)
Dann sucht man nach Teilnamen oder Teilstrings. Ich verwende hier z.b.
ein Script, das mal ein Listenteilnehmer geschrieben hat, dieses
durchsucht RPM-Files nach Strings.
Will ich z.b. wissen in welchem RPM-File das Programm "ping" enthalten
ist, so reicht eine Zeile, und dieses Ding findet mir das zugehörige
File.
Sowas muß auch für die RPM-Datenbank möglich sein.
Es gibt hierzu auch das ultimative Buch "Maximum RPM - Taking the RedHat
Paket Manager to the Max". Ein "man rpm" müßte auch hier weiterhelfen.
Allerdings ist RPM nicht ganz simpel zu verstehen, eben wegen seiner
Möglichkeiten, das gebe ich zu.
> > Und sind wir mal ehrlich: Viele wissen gar nicht, wo sich ihre Programme
> > befinden, auch wenn sie beim Installen groß und breit ein "Target-Dir"
> > angeben dürfen...und es interessiert sie auch nicht!
> > Warum also einen Aufwand treiben, um diese Infos zu erhalten und
> > abzuspeichern, wenn es den Leuten nach 5 Minuten eh egal ist, ob ihr PGP
> > jetzt unter /usr/local oder /opt liegt...zumal man mit symbolischen
> > Links ja auch ein Programm ganz schnell "verschieben" kann...
>
> Vollkommen klar, aber was ist, wenn aus irgendwelchen Gründen doch ein "Target-
> Dir" gewünscht ist ?
Dann kann ja immer noch eines unter /opt oder /usr/local gewählt
werden...
Es geht mir darum, den Wildwuchs zu verhindern. Ich hab früher auch
Dirctories ala "/bilder" oder "/tools" angelegt. Bis ich beim ersten
Backup dahinter gekommen bin, das die Vorgaben halt doch Sinn machen und
ein "Tools"-Dir unterhalb meines /home/pclinux besser aufgehoben ist.
> > > Bist Du in der Lage mir die Anzahl und Lokationen der Konfig-Dateien nur
> > > für das X-Window zu nennen zzgl. für KDE ?
> >
> > Anzahl nicht, wozu ?
> > Lokation sehr wohl:
> >
> > X-Server : /etc/X11/xinit/*
> > KDE: /home/user/Desktop
> > sowie /home/user/.kde
> und /opt/kde und Xdefaults und Xresources und xconfig und
> /usr/X11R6/lib/X11/app-defaults (mit knapp 60 Dateien) und und ....
> Klar, aber das sind überwiegend Batch-Files, keine standardisierte DB.
> Konfig-Dateien wie Xdefaults z.B. weisen anwendungsspezisch eine eigene
> Konfigurationslogik auf, die erst mühselig erschlossen werden muß.
Schon möglich, aber wozu willst du diese Files verändern ?
Das sind User-Konfig-Files, deren eigenmächtige Veränderung durch ein
Install-Programm vielleicht den einen oder andren User nicht fröhlich
stimmt...
Ich würde mich jedenfalls bedanken, wenn das Install-Script von
StarOffice mal schnell meinen Desktop umbaut oder das von Civilisation
ein andres Hintergrundbild einbaut....
>
> > > Registry exportieren: kein Problem
> >
> > Schon, und nach dem Zurückschreiben crasht mir das NT...und wie bieg ich
> > das dann wieder hin, ohne lauffähiges NT ?
>
> Komisch bei mir nicht ! (Hab' vielleicht nur "Glück" gehabt) Wie ich schon
> sagte: es ist ein halbes Hochschulstudium dazu nötig.
Glück...es kommt aber noch ein prinzipielles Problem dazu:
Die Interaktionen der einzelnen Keys. Diese sind ja völlig undefiniert.
Wenn ich bei KDE mein "/home/pclinux/Desktop/Netscape.kdelnk"-File
wegwerfe, so weiß ich, das nacher *nur* das Netscape-Icon aufm Desktop
fehlt und nicht etwa die PPP-Verbindung zum ISP nicht mehr funktioniert
oder aber ich keine HTML-Files mehr öffnen kann, etc...
> > > Na für wen wohl ! Z.B. für wildfremde Software-Produzenten, die zentral nur
> > > irgendwo nach schauen müßten, wo z.B. ein externer Email-Klient läge, um diesen
> > > aus deren Software heraus zu starten, wenn dieser eher vom User als der eigene
> > > gewüsncht würde.
> >
> > Die RPM-Datenbank enthält alle diese Daten...
>
> Ich wäre Dir wirklich dankbar, mir kurz zu zeigen, wie ein fremdes Programm zur
> Laufzeit aus der RPM-DB o.g. Infos bekommt.
Das kann ich nicht so tief binich in RPM auch nicht drin, vielleicht
kann es ein andrer Listenteilnehmer.
Prinzipiell gehen tut es aber, denn PKGINSTALL kann es ja auch, es kann
bei laufendem System die installierten Pakete incl. deren Inhalt
anzeigen.
Allerdings sollte sich das mit oben genannten Buch auch rausfinden
lassen.
Vermutlich müßte der Name des gewünschten E-Mail-Clients bekannt sein.
Allerdings bietet RPM auch die Möglichkeit, Application-Types zu
vergeben.
Beim Paket eines bekannten E-Mail-Readers (mutt) steht da z.b.
"Applications/Mail"
Wenn also alle beim Erstellen ihrer E-Mail-Reader-RPM-Pakete hier
korrekterweise "Mail" eintragen, so klappt das mit der automatischen
Suche aller E-Mail-Clients recht gut.
Natürlich nur WENN. Aber das WENN gilt auch bei einer
Application-Database...
> > Sagt gar nichts aus. Daimler-Chrysler macht noch mehr Umsatz, obwohl
> > deren Autos teilweise umfallen. Das Ziel von Linux kann und sollte nicht
> > sein, Gates zu kopieren, sondern alternative Wege aufzuzeigen, wie z.b.
> > Open Source...
> Mit Verlaub, der Vergleich hinkt ein wenig, was M$ in 15 Jahren durch
> Ankündigungsorgien, rüpelhaftes Marktverhalten und ein glänzendes Marketing von
> teilweise auch rechten ordentlichen Produkten schaffte hat Daimler-Chrysler erst
> in 50 Jahren erreicht.
Sicher hinkt der Vergleich, allein schon deswegen, weil die Masse wohl
nicht alle 6 Monate eine neues Auto kauft, weil das alte inzwischen
"veraltet" ist und sie ständig Benzin in der neuen Version bekommen, mit
dem ihr Auto nicht mehr fährt...
Bei Software gehen eben schnellere Generationensprünge als bei Autos...
> > Es bleibt noch vieles zu tun, um Linux bei Desktops aus der
> > > 7 % -Marktanteilsecke herauszuholen !! PACKEN WIR`s AN !!!
> >
> > Ja, die 7% innerhalb von 3 Jahren....
> > Natürlich sollten wir es anpacken. Aber nicht, indem jetzt planlos
> > irgendwelchen Tools samt ihren Macken aus dem Unix- oder Windowsbereich
> > portiert werden, nur um sagen zu können:
> > "Yes, we too have a Registry!"
> Geb' ich Dir voll recht. Trotzdem würde ich mich über eine zentralisierte
> Datenbasis mit system- und netzwerkweite Konfigurations-Infos schon freuen !
Wie gesagt, RPM bietet hier gewaltige Möglichkeiten, man muß sie nur
nutzen.
Ich nutze sie auch nur als End-User, aber schon diese Möglichkeiten
schlagen die Möglichkeiten jedes "Uninstall-Programms" unter Windows um
Längen...
> Wir alle sollten uns vor einer Selbstgerechtigkeit, daß Linux das bessere OS
> sei, hüten. Denn die selbstgefällige Arroganz sollte nur in Redmond zu Hause
> sein.
Macht bei Linux auch niemand. Linux-Systeme überzeugen zur Zeit immer
durch Leistung, einfache Wartbarkeit, etc.
Aus seiner selbst Willen setzt heute noch keiner Linux ein, dazu ist die
MS-Konkurrenz und die Angst der Entscheider, "dumm" aufzufallen, zu
groß.
> Zum Schluß zählt nur eins: Die klare Beantwortung der Frage: mit welchen
> Systemen bei niedrigen Administrationskosten und Herstellerabhängigkeiten
> ist die höchste Produktivität und Anpassbarkeit an bestehende + zukünfige Ge-
> schäftsprozesse zu erzielen ? (dabei sind technische Vorteile , der Open-
> Source-Kram oder gar Linzenskosten absolut zweitrangig !!)
Lizenzkosten würde ich nur bis zu einem gewissen Grad so ansehen. Ich
kenne Fälle, da erhöhte eine bekannte Softwarefirma schlagartig die
Lizenzkosten für ihre Produkte, was überhaupt nicht egal war, im
Gegenteil, man versuchte durch verringerten Einsatz der Produkte die
Mehrkosten wieder reinzuholen.
Auch im IT-Bereich wächst das Geld nicht auf Bäumen.
Und spätestens, wenn die Spirale "Neue Version - Neue Rechner - Neue
Kosten - Neue Bugs - Neue Version - Neue Kosten..." zu offensichtlich
wird, zieht irgendwer die (Not-)Bremse...
Solong..
mfg Frank.
-- Frank Schneider, <SPATZ1@T-ONLINE.DE>. -Linux, because: Who needs Gates in a fenceless World ?? ... -.-