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

Mike Dornberger Mike.Dornberger at gmx.de
Sa Nov 17 04:20:53 CET 2007


Hi,

On Sat, Nov 17, 2007 at 01:12:13AM +0100, Steffen Dettmer wrote:
> * 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...

hm, reden wir vielleicht aneinander vorbei?

Ich bezog mich immer darauf, daß ich _Shell-Scripte_ schreiben will, deren
Syntax (nach Möglichkeit) POSIX-konform ist (und die nicht zu aufgebläht
sein sollen). Dazu zähle ich aber auch die Aufruf-Syntax von Programmen, die
man in einer POSIX-konformen Umgebung typischerweise vorfindet. (Ich glaube,
dazu sagt die OpenGroup.org auch was, aber ich hab gerade keinen Browser zur
Hand um das rauszusuchen.) Zu diesen Programmen zählen zum Beispiel echo,
test, sed, printf, ggf. find.

Natürlich rufen meine von mir geschriebenen (und meist noch nicht
veröffentlichten) Scripte in der Regel auch "externe" Programme, wie z. B.
rsync, auf.

Mir geht es darum, daß ich mir durch praktische Übung bewußt mache, was
POSIX ist und was nicht und wo ich nachschauen kann, wenn ich mir nicht
sicher bin, etc. pp.

> > 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?

Warum muß ich mich jetzt vor dir verteidigen warum ich gewisse Dinge so
mache? :) Na gut, noch eine kleine Erklärung.

Wenn du meinen Text oben nochmal liest, steht da was von 2 Scripten. Diese
sind natürlich nicht vollständig unabhängig voneinander und gehören zum
selben "Projekt". Wichtig ist halt, daß beide mit der _selben_ (sozusagen
synchronen) Liste von Dateien/Verzeichnissen arbeiten müssen.

> > Die Kommandos werden in einer Variablen zusammengebaut und
> > anschließend eval "$Variable". 
> 
> (klingt gefährlich...)

Ja und? :)

Ich weiß, daß ich 'nen Sack voll Quoting-Probleme zu lösen habe und denke,
daß ich das geschafft habe.

Vielleicht fiele ein viertel Sack davon weg, wenn ich das zusammenzubauende
Kommando in eine temporäre Datei schreiben würde, die dann ge-source-t wird.
Aber zum einen mag ich nur ungern temporäre Dateien anlegen und zum anderen
muß man sich dann wieder wirklich viele Gedanken darum machen, wie man (den
Namen) dieser Datei denn nun erzeugt, sodaß Sachen wie "symlink attacks"
nicht möglich sind, udgl.

Gut könnte man "für privat" ja alles weglassen und so, aber wie schon
gesagt, geht es mir darum, Dinge zu üben und sich bewußt zu machen.

> > 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.

Du hast keine Phantasie. ;) Stell dir doch einfach vor, ich möchte testen,
ob meine .profile POSIX-konform ist und da hab ich halt eine Funktion
definiert, die ich aufrufen kann, wenn ich einen bestimmten ssh-agent killen
will. So, und nun, was passiert, wenn ich auf irgendeiner Konsole ein Script
benutze, daß intensiv, in mehreren Aufrufen, diesen Agenten benutzt und ich
nun den Tester anwerfe? Schwups, Agent weg und beim Script scheppert's.

> 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.

Naja, eigentlich wollte ich am Anfang der Diskussion mit meinem Einwurf nur
sagen, daß so ein Testtool entweder wohl ziemlich schnell an seine Grenzen
stößt oder halt Dinge im laufenden Betrieb einfach kaputt machen kann.

> > > > 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?

Ja, kann sein, daß die posh mitlerweile eher "deprecated" ist.
Zugegebenermaßen nutze ich sie und dash vielleicht zu wenig.

> > 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.

Mit der hab ich mich noch nicht außeinandergesetzt. Vielleicht sollte man
eher allgemein sagen: "Es gibt kleine Shells, die POSIX-konform sein wollen.
Teste dein Script doch mit denen mal." Was dann natürlich nur erstmal für
die Syntax des Scripts gilt. Ob man sed, echo, printf, test, ... "richtig"
verwendet, kann man dann wohl nur rausfinden, wenn man entweder statt der
GNU-Tools was anderes verwendet oder eben wirklich in eine "native"
Solaris- oder vielleicht BSD-Umgebung, beispielsweise. Oder eben halt die
Seiten der OpenGroup.org studiert. :)

> > 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.

Ich kenne den momentanen Stand der Diskussion um die Shell, auf die /bin/sh
unter Debian standardmäßig zeigen soll, nicht. Aber wann immer jemand ein
Script (in Debian-Paketen) findet, daß XSI- oder bash-Konstrukte benutzt und
trotzdem "nur" /bin/sh als Interpreter angibt, soll er das natürlich melden.
Solch ein Bug ist dann wohl Priority: serious oder sogar höher, da in der
Debian-Policy eben steht, wenn /bin/sh, dann auch keine Spezial-Konstrukte.

> 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?

Es ging mir darum, daß diese Wrapper #!/bin/sh stehen haben und nicht
#!/bin/bash, obwohl sie Bash-Konstrukte benutzen.

Ich argumentiere weder gegen die Bash noch gegen die Benutzung derer eigenen
Konstrukte in Scripts. Nur wenn man letzteres tut, sollte man halt nicht
#!/bin/sh als Interpreter haben.

(Und wenn man die bash, zsh oder sonstwas mit speziellen Features benutzt,
gehört das natürlich auch zur Abhängigkeitsliste des (z. B. Debian-)Pakets
hinzu, aber das ist eine andere Baustelle.)

Gruß,
 Mike



Mehr Informationen über die Mailingliste linux-l