Problem mit Argumenten und Schleife
Torsten Wolf
möchte ein Script schreiben, daß die als Argumente übergebenen Dateien
bearbeitet. Meine Idee war folgendes:
#!/bin/sh
counter=1
while [ $counter -le $# ]
do
# hier wird die Datei bearbeitet
counter=`expr $counter + 1`
done
Mein Problem ist, daß ich nicht weiß, wie ich an den gerade aktuellen
Dateinamen herankomme. $1 gibt mir ja das erste Argument (Dateinamen)
aus, $2 den zweiten, usw. (BTW; stimmt es eigentlich, daß das nur bis $9
gut geht?). Innerhalb der Schleife bräuchte ich dann jedoch -z.B. um den
Namen der gerade zu bearbeitenden Datei auszugeben- etwas wie
echo $Wert_von_Counter_der_aktuellen_Datei/Argument
bzw.
echo $$counter
was natürlich Nonsens ist. Wie muß es also korrekt lauten?
Danke im voraus.
Gruß
Torsten
Juergen Ilse
Torsten Wolf <t.w...@tu-bs.de> wrote:
> möchte ein Script schreiben, daß die als Argumente übergebenen Dateien
> bearbeitet. Meine Idee war folgendes:
> #!/bin/sh
> counter=1
> while [ $counter -le $# ]
> do
> # hier wird die Datei bearbeitet
> counter=`expr $counter + 1`
> done
> Mein Problem ist, daß ich nicht weiß, wie ich an den gerade aktuellen
> Dateinamen herankomme.
Benutze "$1" und schreibe in die Schleife noch ein "shift" Kommando
hinein (das ersetzt das vorherige $1 durch das vorherige $2, das vor-
herige $2 durch das vorherige $3 usw. Der neue Wert von $9 ist dann
der vorher nicht auf diese Weise benutzbare 10. Parameter).
Tschuess,
Juergen Ilse (il...@asys-h.de)
--
Wenn ich auch nur aus jedem 1000. Bug in einem M$ Produkt|Juergen Ilse
einen Tag trauern wollte, also da muesste ich 300 Jahre |Internet POP Hannover
alt werden und wuerde mehrere Dutzend schwarze Anzuege |Vahrenwalder Str. 205
aufbrauchen. (Detlef Bosau in dcoulm) |30165 Hannover
Helmut Schellong
>
> Hallihallo,
>
> möchte ein Script schreiben, daß die als Argumente übergebenen Dateien
> bearbeitet. Meine Idee war folgendes:
>
> #!/bin/sh
> counter=1
> while [ $counter -le $# ]
> do
> # hier wird die Datei bearbeitet
> counter=`expr $counter + 1`
> done
>
> Mein Problem ist, daß ich nicht weiß, wie ich an den gerade aktuellen
> Dateinamen herankomme. $1 gibt mir ja das erste Argument (Dateinamen)
> aus, $2 den zweiten, usw. (BTW; stimmt es eigentlich, daß das nur bis $9
> gut geht?). Innerhalb der Schleife bräuchte ich dann jedoch -z.B. um den
> Namen der gerade zu bearbeitenden Datei auszugeben- etwas wie
Die erste Lösung bei solchem Problem ist
for Path in "$@"
do
.........
done
"$@" wirkt wie "$1" "$2" "$3" ...
Dann gibt es ``shift'', ${10}, ${123}, ..., bsh.
--
Mit freundlichen Grüßen
Helmut Schellong po...@schellong.de po...@schellong.com
http://www.schellong.de http://www.schellong.com
http://home.t-online.de/home/schellong sche...@t-online.de
Fritz Schadt
> Torsten Wolf wrote:
>>
>> #!/bin/sh
>> counter=1
>> while [ $counter -le $# ]
>> do
>> # hier wird die Datei bearbeitet
>> counter=`expr $counter + 1`
>> done
>>
> Die erste Lösung bei solchem Problem ist
> for Path in "$@"
> do
> .........
> done
Nein, das ist die zweite. ;-)
die erste ist:
for file
do
xyz "$file"
done
SCNR
fs
--
"Murphy's Law, that brash proletarian restatement of Godel's Theorem ..."
-- Thomas Pynchon, "Gravity's Rainbow"
Helmut Schellong
>
> Helmut Schellong <sche...@t-online.de> wrote:
> > Torsten Wolf wrote:
> >>
> >> #!/bin/sh
> >> counter=1
> >> while [ $counter -le $# ]
> >> do
> >> # hier wird die Datei bearbeitet
> >> counter=`expr $counter + 1`
> >> done
> >>
>
> > Die erste Lösung bei solchem Problem ist
>
> > for Path in "$@"
> > do
> > .........
> > done
>
> Nein, das ist die zweite. ;-)
>
> die erste ist:
>
> for file
> do
> xyz "$file"
> done
Kennst Du die semantischen Unterschiede zwischen
$* "$*" $@ "$@"
?
Gunnar Ritter
> Fritz Schadt wrote:
>> Helmut Schellong <sche...@t-online.de> wrote:
>> > Die erste Lösung bei solchem Problem ist
>>
>> > for Path in "$@"
>> > do
>> > .........
>> > done
>>
>> Nein, das ist die zweite. ;-)
>>
>> die erste ist:
>>
>> for file
>> do
>> xyz "$file"
>> done
>
> Kennst Du die semantischen Unterschiede zwischen
>
> $* "$*" $@ "$@"
>
> ?
Unix 7th Edition, sh(1):
| If in word ... is omitted then in "$@" is assumed.
ISO/IEC 9945-2:1993(E), 3.9.4.2, p. 140:
# The format for the for loop is as follows:
# for name [ in word... ]
# [...]
# Omitting
# in word...
# shall be equivalent to:
# in "$@"
Und wieder einmal kennt Herr Schellong die relevanten Dokumente nicht
im Ansatz. Man könnte gewohnheitsmäßig »RTFM« unter seine Postings
schreiben, es würde zur Widerlegung auch genügen.
Grüße,
Gunnar
Helmut Schellong
Eine explizite Angabe von "$@" ist anzuraten, da die Weglassung
von 'in arg...' in vielen Shell-Varianten $* entspricht.
Ich weiß also gar nicht, warum Du hier meckerst.
(oder weiß ich's doch...?!)
Gunnar Ritter
> Eine explizite Angabe von "$@" ist anzuraten, da die Weglassung
> von 'in arg...' in vielen Shell-Varianten $* entspricht.
Soso, Herr Schellong. Aha. Hier mal eine spontane Zusammenstellung,
bei welchen Shells das *nicht* der Fall ist:
Bourne-Shell: 7th Edition, System III, SVr2, SVr3.2, SVr4, SVr4.2
Korn-Shell: ksh86, ksh88, ksh93, pdksh 5.2.14
bash: 1.14, 2.05
ash: 0.3.7 (RedHat Linux)
Eine Shell, die da »$*« substituierte, hätte mithin einfach einen Bug,
sowohl nach Tradition als auch nach POSIX.2. Laß mich raten, Du hast
das in Deiner sogenannten »bsh« derart verkehrt implementiert? Gott,
nein! Die Dokumentation erwähnt »$*«, aber ausgeführt wird sogar dort
»"$@"«. Und jetzt einen Beleg für die »vielen Shell-Varianten«, bitte.
Grüße,
Gunnar
Torsten Wolf
Gruß
Torsten
Andreas Riedel
>> ISO/IEC 9945-2:1993(E), 3.9.4.2, p. 140:
>> # The format for the for loop is as follows:
>> # for name [ in word... ]
>> # [...]
>> # Omitting
>> # in word...
>> # shall be equivalent to:
>> # in "$@"
>>
>> Und wieder einmal kennt Herr Schellong die relevanten Dokumente nicht
>> im Ansatz. Man könnte gewohnheitsmäßig »RTFM« unter seine Postings
>> schreiben, es würde zur Widerlegung auch genügen.
>
> Eine explizite Angabe von "$@" ist anzuraten, da die Weglassung
> von 'in arg...' in vielen Shell-Varianten $* entspricht.
Kannst Du mehr als kein Beispiel einer solchen "Variante" geben?
Vorbedingung: Du hast das Beispiel nicht selber geschrieben.
Gruß
Andreas
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
Hanspeter 'Happl' Oberlin
Torsten Wolf <t.w...@tu-bs.de> wrote:
>möchte ein Script schreiben, daß die als Argumente übergebenen Dateien
>bearbeitet. Meine Idee war folgendes: .....
Da du die Dateinamen als Argument(e) bekommst, schlage
ich folgende Lösung vor:
while test $# -gt 0
do
# hier wird die Datei $1 bearbeitet
shift 1
done
Grüsse aus der Schweiz
Happl
--
Besucht die Mundartritter in ihrer Burg
<http://members.telering.at/mundartritter/> -- <news:alt.stupid>
Helmut Schellong
>
> Helmut Schellong schrieb:
> >> ISO/IEC 9945-2:1993(E), 3.9.4.2, p. 140:
> >> # The format for the for loop is as follows:
> >> # for name [ in word... ]
> >> # [...]
> >> # Omitting
> >> # in word...
> >> # shall be equivalent to:
> >> # in "$@"
> >>
> >> Und wieder einmal kennt Herr Schellong die relevanten Dokumente nicht
> >> im Ansatz. Man könnte gewohnheitsmäßig »RTFM« unter seine Postings
> >> schreiben, es würde zur Widerlegung auch genügen.
> >
> > Eine explizite Angabe von "$@" ist anzuraten, da die Weglassung
> > von 'in arg...' in vielen Shell-Varianten $* entspricht.
>
> Kannst Du mehr als kein Beispiel einer solchen "Variante" geben?
> Vorbedingung: Du hast das Beispiel nicht selber geschrieben.
In meinem Manual zur bsh steht, daß eine Weglassung $* entspricht.
Und genau das hat sicher einen Grund, nämlich daß ich das Verhalten
bekannter Shells damals nachempfunden/kopiert hatte.
Ein Kandidat ist /bin/sh auf SCO-Unix3.2.0-.4.
Das ist aber etwa 7 Jahre her, und ich will da nicht mehr extra
nachforschen.
Daß in der bsh "$@" gilt, rührt wohl daher, daß ich das Parsen wegen $*
zunächst vergaß und nach Lesen neuerer Manuals auch nicht mehr
realisierte.
Trotz allem finde ich, daß eine explizite Angabe stets vorzuziehen ist,
u.a. weil ich in *keinem* neueren Manual eine explizite Angabe von $@
und
auch nicht $* im Zusammenhang der Weglassung von 'in arg...' gefunden
habe.
Aber "$@" ist an *anderer* Stelle stets mit gleicher Semantik
beschrieben.
Shell-Standards werden wohl die wenigsten vorliegen haben...
---------------------------------------------
for vname [ in word ... ] ;do list ;done
Each time a for command is executed, vname is set to the next
word taken from the in word list. If in word ... is omitted,
then the for command executes the do list once for each
positional parameter that is set starting from 1 (see
``Parameter Expansion''). Execution ends when there are no
more
words in the list.
---------------------------------------------
Welcher der vier Fälle hier gilt, wird nicht beschrieben.
Und bei 'Parameter Expansion' werden alle vier beschrieben, jedoch
ohne Bezug zur for-Schleife.
Folglich ist eine explizite Angabe einfach besser.
Andreas Krennmair
* Helmut Schellong <sche...@t-online.de> wrote:
> Trotz allem finde ich, daß eine explizite Angabe stets vorzuziehen
> ist, u.a. weil ich in *keinem* neueren Manual eine explizite Angabe
> von $@ und auch nicht $* im Zusammenhang der Weglassung von 'in
> arg...' gefunden habe. Aber "$@" ist an *anderer* Stelle stets mit
> gleicher Semantik beschrieben.
--- SNIP ---
For Loop
The for loop will execute a sequence of commands for each member
in a list of items. The for loop requires that the reserved words
do and done be used to delimit the sequence of commands.
The format for the for loop is as follows:
for name [ in word ... ]
do
compound-list
done
First, the list of words following in will be expanded to generate a list of
items. Then, the variable name will be set to each item, in turn, and the
compound-list executed each time. If no items result from the expansion, the
compound-list will not be executed.
Omitting:
in word ...
is equivalent to:
in "$@"
--- SNIP ---
Aus der Single Unix Specification Version 2. Obiger Text stammt von
http://www.opengroup.org/onlinepubs/7908799/xcu/chap2.html#tag_001_009
Im uebrigen ist jede Software, die sich nicht standardkonform verhaelt,
sowieso kaputt, und sollte auf keinen Fall mehr verwendet werden. Aber
das wurde fuer ihre »bsh« sowieso schon bewiesen.
Andreas Krennmair
--
...quoth the server, 404.
Helmut Schellong
Ich rede von Manuals, also man-Pages.
bsh hat nie den Anspruch erhoben, mit irgendeinem Standard
konform zu sein.
Ist perl konform mit POSIX.2 ? - dennoch ist perl brauchbar und
nützlich.
Desweiteren kann man in dieser NG von hunderten kleinen
Nichtkonformitäten von Nicht-bsh lesen.
Also was soll der Quatsch.
Andreas Krennmair
> bsh hat nie den Anspruch erhoben, mit irgendeinem Standard
> konform zu sein.
> Ist perl konform mit POSIX.2 ? - dennoch ist perl brauchbar und
> nützlich.
Eine Shell ist im Gegensatz zu Perl ein systemwichtiger Bestandteil
eines Unix-Systems, und sollte deswegen unbedingt IEEE 1003.2 oder SuS
v2 kompatibel sein. Und das ist ihre »bsh« sicher nicht. Und "yet
another scripting language" braucht auch keiner, da gibt es bereits
nettere Dinge, eines davon wurde von ihnen oben schon erwaehnt.
> Desweiteren kann man in dieser NG von hunderten kleinen
> Nichtkonformitäten von Nicht-bsh lesen.
Wissen sie, immer wenn man ihnen Inkompatibilitaeten ihrer »bsh«
aufzeigt, zeigen sie mit dem Finger auf andere Shells und schreien "aber
die doch auch!", und das nervt. Sowas machen normalerweise nur
Kleinkinder.
Joerg Bruehe
Helmut Schellong wrote:
>
> [...]
>
> Ich rede von Manuals, also man-Pages.
>
> bsh hat nie den Anspruch erhoben, mit irgendeinem Standard
> konform zu sein.
> Ist perl konform mit POSIX.2 ? - dennoch ist perl brauchbar und
> nützlich.
> Desweiteren kann man in dieser NG von hunderten kleinen
> Nichtkonformitäten von Nicht-bsh lesen.
> Also was soll der Quatsch.
Einige Postings frueher in diesem Thread, naemlich heute frueh
um 01:01, schriebst Du (Helmut Schellong) selbst bereits:
| Eine explizite Angabe von "$@" ist anzuraten, da die Weglassung
| von 'in arg...' in vielen Shell-Varianten $* entspricht.
Daraufhin wurdest Du nach Beispielen gefragt, und es wurden (sowohl
davor als auch danach) Manuals zitiert, die ausdruecklich
"$@"
vorschreiben. Du bliebst sichere Beispiele schuldig, hattest nur
einen "Kandidaten".
Wenn Du Dich geirrt hattest, dann gib es doch einfach zu - das kann
IMHO _wirklich_ jedem passieren. Aber lenke nicht ab (mit Perl),
handle nicht nach "Was schert mich mein Geschreibsel von vorhin",
und bezeichne nicht einfach alle anderen Beitraege als "Quatsch".
Gruss,
Joerg Bruehe
--
Joerg Bruehe, SQL Datenbanksysteme GmbH, Berlin, Germany
(speaking only for himself)
mailto: jo...@sql.de
Gunnar Ritter
> ---------------------------------------------
> for vname [ in word ... ] ;do list ;done
> Each time a for command is executed, vname is set to the next
> word taken from the in word list. If in word ... is omitted,
> then the for command executes the do list once for each
^^^^^^^^
> positional parameter that is set starting from 1 (see
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> ``Parameter Expansion''). [Kammzitat gesnippt]
> Welcher der vier Fälle hier gilt, wird nicht beschrieben.
Doch.
Die Beschreibung in der v7-Manpage (»if in word ... is omitted then
in "$@" is assumed«) stimmte damals nämlich nicht -
$ cat t
for i in "$@"
do
echo "$i"
done
echo -----
for i
do
echo "$i"
done
$ sh t
-----
$
- denn ohne positionale Parameter wurde "$@" bis SVr3 (?) zu ''
expandiert und nicht zu nichts wie heute. Wohl deshalb steht schon
in der System III-Manpage genau die Formulierung, die Du oben ohne
Quellenangabe wiedergegeben hast. Man muß sie eben nur verstehen.
Somit ist »for i« stets portabler als »for i in "$@"«, zumal die
ältere Expansionsweise von »"$@"« immer noch anzutreffen ist (vgl.
<3b97...@news.uni-ulm.de>).
Grüße,
Gunnar
Sven Mascheck
> for i
> do
[als in v7 nichtdokumentierte Alternative zu ${1+"$@"}]
> Helmut Schellong <sche...@t-online.de> wrote:
>> [...]
>> for vname [ in word ... ] ;do list ;done
»in word« ist also (im Gegensatz zur offenbar fehlerhaften SCO manpage)
ein Spezialfall, der nur mit Semikolon abgeschlossen werden muß, wenn er
nicht-leer ist. Auf wohl allen anderen Systemen (zumindest v7, (x)BSD,
SIII, SVr2/3/4) wird die Syntax ohne Semikolon dargestellt.
Interessanterweise ist Umbrechen aber trotzdem möglich.
Gunnar Ritter
>> Helmut Schellong <sche...@t-online.de> wrote:
>>> [...]
>>> for vname [ in word ... ] ;do list ;done
>
> »in word« ist also (im Gegensatz zur offenbar fehlerhaften SCO manpage)
> ein Spezialfall, der nur mit Semikolon abgeschlossen werden muß, wenn er
> nicht-leer ist. Auf wohl allen anderen Systemen (zumindest v7, (x)BSD,
> SIII, SVr2/3/4) wird die Syntax ohne Semikolon dargestellt.
Das ist offenbar eine ksh-Manpage. Die sh-Manpages von SCO enthalten
an dieser Stelle auch keine Semikola.
> Interessanterweise ist Umbrechen aber trotzdem möglich.
Deshalb steht ja ein paar Zeilen weiter auch
| The following words are only recognized as the first word
| of a command and when not quoted.
|
| if then else elif fi case in esac for while until
| do done { }
oder worauf wolltest Du jetzt hinaus?
Grüße,
Gunnar
Helmut Schellong
>
> Hallo!
>
> Helmut Schellong wrote:
> >
> > [...]
> >
> > Ich rede von Manuals, also man-Pages.
> >
> > bsh hat nie den Anspruch erhoben, mit irgendeinem Standard
> > konform zu sein.
> > Ist perl konform mit POSIX.2 ? - dennoch ist perl brauchbar und
> > nützlich.
> > Desweiteren kann man in dieser NG von hunderten kleinen
> > Nichtkonformitäten von Nicht-bsh lesen.
> > Also was soll der Quatsch.
>
> Einige Postings frueher in diesem Thread, naemlich heute frueh
> um 01:01, schriebst Du (Helmut Schellong) selbst bereits:
>
> | Eine explizite Angabe von "$@" ist anzuraten, da die Weglassung
> | von 'in arg...' in vielen Shell-Varianten $* entspricht.
>
> Daraufhin wurdest Du nach Beispielen gefragt, und es wurden (sowohl
> davor als auch danach) Manuals zitiert, die ausdruecklich
> "$@"
> vorschreiben. Du bliebst sichere Beispiele schuldig, hattest nur
> einen "Kandidaten".
Ich habe bis dahin *keine* man-Pages (Manuals) gezeigt bekommen,
die bei der for-Schleife "$@" als Ersatz von 'in arg...' nennen.
> Wenn Du Dich geirrt hattest, dann gib es doch einfach zu - das kann
> IMHO _wirklich_ jedem passieren. Aber lenke nicht ab (mit Perl),
> handle nicht nach "Was schert mich mein Geschreibsel von vorhin",
> und bezeichne nicht einfach alle anderen Beitraege als "Quatsch".
Ich hatte den unprovozierten bsh-Inkompatibilitäts-Angriff
als "Quatsch" bezeichnet, angesichts der vielen Inkompatibilitäten
anderer Shells.
Helmut Schellong
>
> * Helmut Schellong <sche...@t-online.de> wrote:
> > Ich rede von Manuals, also man-Pages.
> Dann schreiben sie das auch.
Hier hatte ich:
----------------------------------------------------------------------
Trotz allem finde ich, daß eine explizite Angabe stets vorzuziehen ist,
u.a. weil ich in *keinem* neueren Manual eine explizite Angabe von $@
und auch nicht $* im Zusammenhang der Weglassung von 'in arg...'
gefunden habe.
----------------------------------------------------------------------
> > bsh hat nie den Anspruch erhoben, mit irgendeinem Standard
> > konform zu sein.
> > Ist perl konform mit POSIX.2 ? - dennoch ist perl brauchbar und
> > nützlich.
> Eine Shell ist im Gegensatz zu Perl ein systemwichtiger Bestandteil
> eines Unix-Systems, und sollte deswegen unbedingt IEEE 1003.2 oder SuS
> v2 kompatibel sein. Und das ist ihre »bsh« sicher nicht.
bsh *kann* gar nicht vollständig konform sein!
Ich hätte sehr viele nützliche, zusätzliche Konzepte
bei voller Konformität nicht implementieren können.
Mein Ziel war es nie, eine /bin/sh_VonSchellong
hinzuzufügen, sondern etwas ganz Neues für alle
wesentlich verbreiteten Plattformen.
> > Desweiteren kann man in dieser NG von hunderten kleinen
> > Nichtkonformitäten von Nicht-bsh lesen.
> Wissen sie, immer wenn man ihnen Inkompatibilitaeten ihrer »bsh«
> aufzeigt, zeigen sie mit dem Finger auf andere Shells und schreien "aber
> die doch auch!", und das nervt. Sowas machen normalerweise nur
> Kleinkinder.
"die doch auch" ist ein Fakt.
Ich kannte die Inkompatibilitäten der bsh bereits,
bevor sie überhaupt fertig entwickelt war.
Gunnar Ritter
> Joerg Bruehe wrote:
>> und bezeichne nicht einfach alle anderen Beitraege als "Quatsch".
>
> Ich hatte den unprovozierten bsh-Inkompatibilitäts-Angriff
> als "Quatsch" bezeichnet, angesichts der vielen Inkompatibilitäten
> anderer Shells.
Meßlatte configure-Skripte. Aber das hatten wir ja schon. Wird wohl
Zeit, mal wieder auf Deine Gefährlichkeit aufmerksam zu machen.
Grüße,
Gunnar
Sven Mascheck
> Sven Mascheck <sven.m...@student.uni-ulm.de> wrote:
>> »in word« ist also [...] ein Spezialfall, der nur mit Semikolon
>> abgeschlossen werden muß, wenn er nicht-leer ist.
>> [Umbruch aber möglich]
(Sorry: mit Umbruch hat es eigentlich nichts zu tun)
> Deshalb steht ja ein paar Zeilen weiter auch
> | The following words are only recognized as the first word
> | of a command and when not quoted.
> | if then else elif fi case in esac for while until
> | do done { }
> oder worauf wolltest Du jetzt hinaus?
Hm, an dieser Stelle taucht »in« übrigens nur bei den v7-Varianten auf,
warum eigentlich?
Ich fand es nicht intuitiv, daß »for i; do [...]« nicht möglich ist,
das Semikolon aber (natürlich) zwingend wird, wenn »in« vorhanden ist.
Denkbar belanglos, »immerhin« ist es dann aber in allen »moderneren«
Shells erlaubt, entweder sogar der Intuition wegen oder weil das alles
nur sehr spezielle Parser-Eigenschaften sind?