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, "\"[EMAIL PROTECTED]"" 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 "\"[EMAIL PROTECTED]"".
> | [..]
> | (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 "\"[EMAIL
PROTECTED]""
gehen:
(1) die inneren Quotes in "\"[EMAIL PROTECTED]"" 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.
--
Haeufig gestellte Fragen und Antworten (FAQ):
http://www.de.debian.org/debian-user-german-FAQ/
Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED]
mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
