Re: /bin/sh: prüfen ob String1 "Wort" aus String2 enthält
Hallo,
On Wed, 04 Jan 2017 16:33:08 +0000
Christian Andretzky <Christian.Andretzky@in-chemnitz.de> wrote:
> Hi,
> nachdem in den Thread die ganze Zeit schweigend und mit etwas
> Verwunderung (sorry ;-)
kein Problem :-)
> verfolgt habe,
> drängt es mich nun doch, da mal meinen Senf dazuzugeben.
>
> Das erste, was ich vermisse, ist eine Aussage darüber, was Du
> eigentlich vor hast.
Ääh... sagt das nicht von dir unten angefügte Zitat?!?
> Ich habe verstanden, dass Du einen String/Liste (oder was
> vergleichbares) haben möchtest, dass Du dann einem Programm/Script…
> zum Fraß vorwerfen kannst, um etwas bestimmtes zu tun.
> Da wäre zunächst mal interessant zu wissen, wie genau dieser String
> aussehen muss.
>
> Könnte es z.B. sein, dass die Ausgabe von
>
> apt-show-versions --upgradeable --brief
>
> bereits das liefert, was Du brauchst.
Leider nicht.
Ok, eine ausführlichere Erklärung, worum es geht (hatte ich mit Absicht
weggelassen, weil ich dachte, das tut für die konkrete Frage nichts
zur Sache):
Ein Skript das über cron angeschubst wird, soll eine Liste von
Updatekandidaten erstellen und in eine Datei schreiben. Diese wird von
einem einfachen GUi eingelesen, das in der Taskleiste sitzt und dem User
ermöglicht, mit ein paar Mausklicks das System Upzudaten.
Als Basis für das Skript habe ich die entsprechende Passage von apticron
1:1 verwendet. apticron bietet optional die Möglichkeit, sich auch
Updates für auf "hold" gesetzte Pakete und Pakete die beim Upgrade neu
installiert werden würden anzeigen zu lassen, was ich so übernommen habe,
vllt. will man das ja.
Ich habe das ganze dann noch erweitert um Optionen die es erlauben
aptitude statt apt-get zu verwenden und statt einem dist-/full-upgrade
für die täglichen Aktualisierungen nur ein (safe-)upgrade zu starten,
User von testing oder unstable könnten das ja evtl. vorziehen.
(Spätestens die letztgenannte Option macht apt-show-versions --upgradeable
wohl leider für meine Zwewcke unbrauchbar.)
Ich musste dann feststellen, dass der apticron-Code einen Fehler hat, der
dazu führt, dass manche Pakete fälschlicherweise aus der Liste der
Updatekandidaten entfernt werden, falls der User gewählt hat, die neu zu
installierenden Pakete *nicht* anzeigen zu lassen, also sollte ein Ersatz
für diesen Code-Abschnitt her.
Einen prinzipiell (scheinbar) gut funktionierenden Ansatz dafür hatte ich
auch schon:
die Liste der Installationskandidaten wird durch auswerten eines dry-run
von apt-get/aptitude (full-/dist-/safe-)upgrade erzeugt (genau wie in
apticron), diese Pakete werden dann (anders als bei apticron) verglichen
mit einer Liste aller installierten Pakete, nicht bereits installierte
fliegen dabei raus.
Das Problem dabei war nur, dass ich feststellen musste, dass man dabei
die maximale Argumentlänge sprengen kann, wenn man das nicht in der
Shell, sondern "extern" macht.
> Evtl. muss man die Ausgabe noch durch sed schicken, dass alles, was
> nicht der reine Paketname ist
> eliminiert, also:
>
> apt-show-versions --upgradeable --brief | sed "s/:.*$//g"
Das würde auch nicht korrekte Resultate liefern, weil ein Paket z.B. in
einer i386 *und* einer amd64 Version installiert sein kann; in dem Fall
hätte man dann z.B. statt libfoo und libfoo:i386 zweimal libfoo in der
Liste, was am Ende für Verwirrung sorgen kann, wenn die Anzahl der
gemeldeten Updates nicht mit der der tatsächlich installierten
übereinstimmt. Der oben erwähnte Fehler im apticron-Code war ähnlicher
Natur.
> Falls das oben gesagte nicht zutreffend sein sollte, d.h. wirklich
> shell-Operationen erforderlich sein sollten,
> dann wäre es nützlich zu wissen, von welcher shell wir reden. Da gibts
> mittlerweile eine ganze Menge davon, die sich z.T. auch massiv
> unterscheiden. Die eigentliche Bourne-shell "/bin/sh" existiert heute
> meist nur noch als Symlink auf eine wesentlich modernere shell.
Ich dachte, ich hätte erwähnt (vllt. ja auch nicht), dass das Skript
mit /bin/sh läuft und ich auch bevorzugen würde, wenn ich es dabei lassen
kann (deswegen ja auch mein "Sträuben" bei bash-only Lösungen und meine
Versuche, diverse Varianten mit posh zu testen).
>
> Sofern nicht wirklich zwingende Gründe existieren, wäre es
> kontraproduktiv, auf die ganzen Features, die bash bzw. dash bieten zu
> verzichten. Dabei ist nach meiner Kenntnis die bash die
> leistungsfähigere der beiden, speziell im Punkt der Stringverarbeitung.
Naja, "leistungsfähiger" im Sine von "kann mehr" bestimmt, im Sinne von
"ist schneller" hat nach meinen Tests aus den letzten Tage zu urteilen
zumindest in manchen Fällen die dash klar die Nase vorn.
So, ist länger geworden als geplant, ich hoffe mal, das war jetzt nicht zu
viel der Erläuterung :-)
Gruss
Michael
.-.. .. ...- . .-.. --- -. --. .- -. -.. .--. .-. --- ... .--. . .-.
Violence in reality is quite different from theory.
-- Spock, "The Cloud Minders", stardate 5818.4
Reply to: