> 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.
> Ich habe neulich Civilization - Call to Power hier auf der DLD
> installiert. Das geht über ein Tcl/Tk-Script, und funktionierte
> einwandfrei.
Ich muß mich falsch ausgedrückt haben: Schwierigkeiten habe ich nicht:
foreach pgpex {pgpk pgpv pgpe pgps} {
if { ![file executable /usr/bin/$pgpex] && \
! [file executable /bin/$pgpex] && \
! [file executable /usr/sbin/$pgpex] && \
! [file executable /sbin/$pgpex]} {
tk_messageBox -icon error -title "Error" \
-message "Can't find or execute $pgpex, may be \
it's not installed; Exited"
file delete -force $RUNDIR
exit 4 }
}
Obiger Hack funzt natürlich ohne Probs; Bauchschmerzen bereits es mir trotzdem
(Was ist wenn einer sie in /usr/local/bin oder /usr/fantasy/bin oder ...
abgelegt hat ??)
> 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.
Funktioniert bestimmt alles; habe mir auch schon so etwas geschrieben;
ist aber zur Laufzeit eines anderen Programms inpraktikabel und stellen nur
Behelfslösungen dar !!
> 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.
Nun muß ich zum Angebot des o.g. Programms selbst ein RPM bauen , weiß
Du außer o.g. Buch und man-pages eine gute Doku speziellen zum RPM-Bau ??
> 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.
Völlig klar nur so geht's !!!
> > 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...
Natürlich soll ein Install-Programm die systemweiten und erst recht nicht die
User-Konfig-Files verändern ! Es soll nur eine standardisierte Basis geschaffen
werden, in der Installationsroutinen neuer Progamme oder Programme zur Laufzeit
die aktl. Einstellungen auslesen können, um sich an sie optimal anpassen zu
können.
> 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...
Wirklich guter Kommentar !! Bleibt nur zu hoffen, daß sich alle Hersteller bei
der Installation daran halten und daß so etwas auch für die 159 Konfig-Files
geben sollte.
> > 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ß.
Das stimmt nur zu gut, bedenke aber, daß die Entscheider nicht NUR aus Angst
dumm aufzufallen, MS wählen, sondern in konservativer Manier auch Kriterien wie
Plattform-Einheitlichkeit, Investitionsschutz und Haftungs-Verantwortlichkeit
zulassen müssen.
> > 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
> > Geschä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...
Stimmt auch aber neue Versionen bieten meistens über die Behebung der Bugs
in Vorgängerversionen hinaus noch zusätzliche Funktionalität. Und vielleicht
trägt dieser Kreislauf ja auch ein wenig zu Deiner Arbeitsplatzsicherheit bei !
Grüße Hans Heering
_______________________________________________________________
Dipl. Wirt.-Inf. Hans Heering
email: Hans.Heering@munich.netsurf.de
www : http://homepages.munich.netsurf.de/Hans.Heering
Public-Key-Server: (ID: Hans Heering <Hans.Heering@munich.netsurf.de>)
http://www.trustcenter.de/cgi-bin/SearchCert.cgi?FORMTYPE=Search
oder: http://math-www.uni-paderborn.de/pgp/extract.html
_______________________________________________________________