Re: Chroot Skriptausführung Ebene
On Fri, 2005-03-04 at 09:04 +0100, Heike C. Zimmerer wrote:
> Du hast den Kontext weggelassen. Der war:
>
> Du:
> | > Hmm? Alle Parameter werden in der jetzigen Version an gmplayer als
> | > ein Parameter übergeben (in argv[1] resp $1, je nach Philosophie).
>
Genau. Ich habe nicht gesagt, "\"$@\"" würde als ein Parameter an
dchroot gehen, sondern am Ende des Aufrufstacks an gmplayer. Und das
habe ich gezeigt.
Mein Beispiel war 'script.sh a b' mit den zwei Parametern a und b.
> Ich:
> | Nö. Da steht "\"$@\"".
> | [..]
> | (Vor du jetzt antwortest "Sag' ich doch: einer", solltest du
> | evtl. nachschlagen.)
>
> Du:
> | Überlass ich dir.
>
> Also: *Alle Parameter* werden als *einer* übergeben. So deine
> Behauptung, und ich schrieb "nö".
Genau. Und dein 'nö' ist verkehrt.
> Nachzuschlagen wäre `"$@"' gewesen. Das hatte ich zitiert und mehr
> stand da ja nicht. Im Unterschied zu `"$*"' expandiert das zu so
> vielen Parametern wie übergeben wurden, fasst sie also *gerade nicht*
> zu einem einzigen zusammen. Das ist ja genau der Witz, warum "$@"
> existiert und nicht nur "$*".
Schön und richtig, nur nicht relevant. Es geht nicht nur um die Shell
Syntax, sondern wie dchroot bzw. su seine Subshell aufruft. Teste z.B.
mal
su - root /tmp/echo.sh \"a b\" # zwei Paramater !
wo /tmp/echo.sh enthält
#!/bin/sh
exec echo "$1"
und schau was dabei rauskommt.
Dieses Verhalten ist zwar nur halb oder gar nicht dokumentiert
man su:
...
Any arguments supplied after the username will be passed to the
invoked shell (shell must support the -c command line option in
order for a command to be passed to it).
...
aber eben da.
Und jetzt ein Wort zur Logik, warum all das auch ohne Analyse klar war.
Grundlage dafür war nämlich Carsten's Aussage es würde mit "\"$@\""
gehen:
(1) die inneren Quotes in "\"$@\"" sind escaped und gehen daher in die
dchroot Argumente
(2) die Quotes kommen aber nicht in den gmplayer Argumenten an, sonst
wären sie Teil eines nicht exisitierenden Dateinamens
(3) sie werden also im Aufrufstack weginterpretiert, und zwar mit an
Sicherheit grenzender Wahrscheinlichkeit paarweise und shellmässig,
d.h. alles was zwischen ihnen steht wird als ein Wort/Parameter
angesehen
(4) dieses Wort könnte zwar weiter im Aufrufstack wieder auseinander-
fallen, aber da an der Stelle wo die Anführungszeichen wegfallen
keine gequoteten Leerzeichen mehr existieren würde dann auch ein
Dateiname mit Leerzeichen in Worte zerfallen. Carsten hatte aber
wie gesagt eine Erfolgsmeldung gebracht. Natürlich für Dateinamen
mit Leerzeichen, denn darum handelte es sich.
Ergo, auch ohne grosse Analyse war die Sache klar, egal wie sehr man
sich an der bash man page festhält.
Reply to: