[linux-l] POSIX und busybox (was: Subtilitäten von find und xargs)

Steffen Dettmer steffen at dett.de
Sa Nov 17 01:12:13 CET 2007


* Mike Dornberger wrote on Fri, Nov 16, 2007 at 02:23 +0100:
> > externes_Programm ist entweder POSIX und gut oder nicht und
> > durchgefallen - oder?
> 
> externes_Programm_macht_Ausgabe = (eines m)ein(r) Shellscript(e),
> "beliebige" Ausgabe per echo oder printf? *gnnna* Ich sehe schon, geht
> bestimmt wieder nicht ohne ein Beispiel:

ja, ich versteh wirklich kein Wort...

> Ich habe so ein Konstrukt neulich mal gebraucht um aus einer Datei (Liste
> von Verzeichnissen/Dateien, jeweils mit \n separiert), in einem Script ein
> find \( -path "./datei_dir1" -or -path "./datei_dir2*" \) und einem anderen
> Script ein rsync-Kommando zusammenzubauen, wobei für letzteres Spaces
> gequotet werden mußten. 

(warum hier nicht einfach "rsync -r ./datei_dir[12]* ziel"?)

Datei mit Dateinamen? Kann man mit "read < file" einlesen, oder?

> Die Kommandos werden in einer Variablen zusammengebaut und
> anschließend eval "$Variable". 

(klingt gefährlich...)

> Nun ist zwar rsync wohl nicht POSIX, aber find.
> Und wenn ich die Variable nun mit einem externen Programm
> zusammengebaut hätte?

Egal, ist in beiden Fällen nicht POSIX, schon allein wegen rsync. Ohne
rsync wäre es POSIX, wenn das exterene Programm POSIX ist. Wenn's ein
cat wäre z.B.

> Oh, mir fällt noch ein einfacherer Fall ein, der tatsächlich auch
> große Relvanz hat: 'eval `ssh-agent`' und 'eval `ssh-agent -k`'
> 
> Und nun teste mal ein Script auf POSIX-konformität, daß irgendwo eval
> `ssh-agent -k` aufruft. 

Ist es nicht, weil ssh-agent muss ja gar nicht existieren.

Aber so einfach ist das in der Praxis ja auch nicht, weil man könnte ja
ein Script machen, was prüft, ob ssh-agent vorhanden ist oder nicht,
oder ob find den Schalter --xyz kennt oder nicht usw. Dabei sind aber
natürlich die Grenzen wieder fliessend, weil wenn man erlaubt, dass ein
POSIX-konformes Script konform ist, auch wenn unter POSIX-OS nur ein
Teil der Funktion gehen muss, könnte man ja wieder ein Script haben,
was bloss noch sagt "bash ist nicht installiert" oder so. Wäre konform,
aber sinnlos. Na ja, kommt auf den Fall an etc pp.

> Der Test muß ja das Programm ausführen, um an die Ausgabe zu kommen,
> um die testen zu können, ob diese konform ist. Resultat: Agent weg und
> du mußt alle Paßphransen neu eingeben.

? nah

eval `ssh-agent` nochmal machen? OK, sicher schlechtes Beispiel, weil
man sich das wohl sicherlich einmal in ~/.xinitrc einträgt... Aber
bleiben wir mal dabei, auch wenn es vielleicht nicht in der Praxis
vorkommt. Natürlich kann man das Testen. Man macht z.B. ein Script, was
einen 256 bit Schlüssel erzeugt in /tmp, ssh-agent startet (macht ja
nix, wenn er schon läuft, gibts halt 2 oder 5), den key lädt und guckt,
ob er geladen wurde. Dann wird dieser agent gekillt (bzw. startet man
den Testagent gleich als "ssh-agent test_script.sh"). Geht also. Wobei
das halt kein reines POSIX ist. Also schon, unter POSIXs gehts dann halt
nicht, aber mit sauberer Fehlermeldung ("Dieses Script braucht OpenSSH
Version 2.11 oder höher" oder sowas).

> > > Außerdem könntest du deine Shell-Scripte mit der posh testen. (Heißt
> > > jetzt Policy-compliant Ordinary SHell, aber ich glaube, sie hieß mal
> > > POSIX-Shell.)
> > 
> > hum, kennt nichtmal wikipedia, hast'n Link? Kann man das wirklich
> > benutzen?
> 
> http://packages.debian.org/posh

die knappe Minidoku klang eher, als ob das ein privat-Alpha-Tool ist?

> Aber ich hätte vielleicht besser von dash schreiben sollen.
> http://packages.debian.org/dash

Wenns um Stabilität nach Updates geht, dann find ich sash gut.

> Die Beschreibung sollte ja erhellend genug sein. Zusätzlich zu dem
> Geschriebenen glaube ich mich zu erinnern, daß die/einige Debianer
> dash gerne als /bin/sh hätten, damit die bash auch aus dem Basissystem
> (oder der Essential-Liste?) heraus kann.

Aber, funktioniert nicht? Was passiert dann? Sollte man doch hinkriegen.
Kommt natürlich drauf an, was man will. KDE geht vielleicht nicht, weil
ein Script in bash ist, aber wer KDE will, den stört bash wohl auch
kaum.

> Ich hatte das unter Sarge auch mal probiert, aber einige Wrapper, wie z. B.
> zless benutz(t)en Bash-Konstrukte, obwohl sie eine #!/bin/sh Zeile haben,
> sodaß ich wieder die bash als Link-Zeil von /bin/sh eingestellt hatte.

Versteh ich nicht. Wenn man ne einfachere, kleinere Shell nimmt, hat man
natürlich weniger Funktionalität, klar. Was hattest Du erwartet?

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.




Mehr Informationen über die Mailingliste linux-l