# Bash: Inhalt von $1 als neue Variable nutzen

## Finswimmer

Hi!

Ich möchte, dass ./test temp1 dazu führt, dass im Skript ein "echo $1" den Inhalt von $temp1 ausgibt.

Ich schaff das einfach nicht....

Tobi

----------

## blice

```

bodo@localhost ~/bashtest $ cat temp1.txt

Hallo Welt!

Dies ist nur ein file.

bodo@localhost ~/bashtest $ cat test

#!/bin/bash

echo $1 # gibt den übergabewert als "temp1" aus

cat $1 # gibt den inhalt mit cat aus (ACHTUNG! steuerzeichen erzeugen möglicherweise Chaos

bodo@localhost ~/bashtest $ 

```

chmod a+x test nicht vergessen  :Smile: 

```

bodo@localhost ~/bashtest $ ./test temp1.txt

temp1.txt

Hallo Welt!

Dies ist nur ein file.

bodo@localhost ~/bashtest $ 

```

das klappt auf allen lesbaren dateien auf die du rechte hast .. zb 

```

bodo@localhost ~/bashtest $ ./test /var/log/Xorg.0.log

/var/log/Xorg.0.log

X Window System Version 1.3.0

Release Date: 19 April 2007

X Protocol Version 11, Revision 0, Release 1.3

Build Operating System: UNKNOWN 

Current Operating System: Linux localhost 2.6.22-gentoo-r5 #5 SMP Sat Sep 22 21:10:26 Local time zone must be set--see zic  i686

.

.

. [geschnitten]

```

----------

## firefly

 *blice wrote:*   

> 
> 
> ```
> 
> bodo@localhost ~/bashtest $ cat temp1.txt
> ...

 

falsch verstanden  (setzen sechs *g*)

er meinte folgendes:

```
$ export Temp1="Hallo"

$ ./test Temp1

Hallo

$
```

sprich der übergebene parameter ist wiederum eine env variable dessen inhalt er ausgeben möchte.

----------

## firefly

 *Finswimmer wrote:*   

> Hi!
> 
> Ich möchte, dass ./test temp1 dazu führt, dass im Skript ein "echo $1" den Inhalt von $temp1 ausgibt.
> 
> Ich schaff das einfach nicht....
> ...

 

```
TT=$(env | grep $1); echo ${TT/$1\=/};
```

dies funktioniert aber nur mit variablen, die per export in der aktuellen shell session "deklariert" wurden.

----------

## Finswimmer

```
realvar=$(echo \$$1)

for line in $(eval echo $realvar ); do

                        echo "$line"

done

```

So gehts nun. War aber ein großer Akt, bis das ging...

Tobi

----------

## Necoro

 *Finswimmer wrote:*   

> 
> 
> ```
> realvar=$(echo \$$1)
> ```
> ...

 

Hier kann man ein echo einsparen  :Arrow:  realvar="\$$1" oder auch realvar='$'$1

 *Quote:*   

> 
> 
> ```
> for line in $(eval echo $realvar ); do
> ```
> ...

 

Auch hier macht das echo keinen Sinn ...

/edit: hmm ... vllt doch ... hab das letzte als $(eval $(echo $realvar)) gelesen ... sorry ^^

----------

## mv

 *Finswimmer wrote:*   

> 
> 
> ```
> realvar=$(echo \$$1)
> ```
> ...

 

```
./myscript "exploit_me; rm -rf *"
```

Du suchst so etwas: 

```
eval "wert=\"\${${1}}\""
```

 (unter bash ginge es einfacher, aber warum schrottig programmieren, wenn es sauber geht?)

Edit: Auch das kann "exploited" werden!Last edited by mv on Thu Feb 14, 2008 11:18 pm; edited 1 time in total

----------

## Necoro

 *mv wrote:*   

>  *Finswimmer wrote:*   
> 
> ```
> realvar=$(echo \$$1)
> ```
> ...

 

So wie ich den code sehe, sollte der exploit nicht anwendbar sein (da er die variable nur in einer for schleife verwendet) - und er halt kein kein eval $1 macht

----------

## mv

 *Necoro wrote:*   

> So wie ich den code sehe, sollte der exploit nicht anwendbar sein (da er die variable nur in einer for schleife verwendet)

 

Probier es aus. Der Eploit greift schon in der ersten Zeile...

Edit: Sorry. Du hast recht.

----------

## Finswimmer

 *mv wrote:*   

>  *Finswimmer wrote:*   
> 
> ```
> realvar=$(echo \$$1)
> ```
> ...

 

Teste ich nachher. 

BTW: Ich nutze die Bash.

Tobi

----------

## mv

 *Finswimmer wrote:*   

> BTW: Ich nutze die Bash.

 

M.E. ein Fehler: Wenn schon inkompatibel, dann lieber wirklich bequem (sprich: zsh).

Bei Bash und zsh gibt es indirekte Expansion: 

```
wert=${!1}
```

----------

## Finswimmer

 *mv wrote:*   

>  *Finswimmer wrote:*   BTW: Ich nutze die Bash. 
> 
> M.E. ein Fehler: Wenn schon inkompatibel, dann lieber wirklich bequem (sprich: zsh).
> 
> Bei Bash und zsh gibt es indirekte Expansion: 
> ...

 

Ok. Wird nun OT, aber warum ist Bash ein Fehler?

Ich dachte immer das wäre DIE Standarshell?

Tobi

----------

## STiGMaTa_ch

 *Finswimmer wrote:*   

> Ok. Wird nun OT, aber warum ist Bash ein Fehler?
> 
> Ich dachte immer das wäre DIE Standarshell?

 

Ist sie auch... zumindest unter Linux Systemen. Andere Systeme verwenden lieber die Bourne Shell (Nicht zu verwechseln mit Bourne Again Shell!) oder nutzen C-Shell. 

Aber eigentlich ist die Diskussion um "die beste Shell" genau so müssig und unsinnig wie die Diskussion um das beste Linux, das beste Betriebsystem, das beste File System oder den schönsten Busen.

Denn es gibt einfach keine beste "Irgendwas". Es gibt nur Anforderungen welche mal von diesem "Irgendwas" und mal von jenem "Irgendwas" besser abgedeckt werden.

Lieber Gruss

STiGMaTa

----------

## mv

 *STiGMaTa_ch wrote:*   

> Ist sie auch... zumindest unter Linux Systemen.

 

Keineswegs. Das ist sie nur bei Gentoo, weil Portage (meint hier: den gesamten Portage-Baum) darauf eingeschossen ist.

Andere Distributionen sind wesentlich weniger freier bei der Wahl der Shell.

Wenn es so etwas wie eine Standardshell gibt, dann heißt diese POSIX-shell - das ist der einzige festgelegte Standard.

 *Quote:*   

> Denn es gibt einfach keine beste "Irgendwas". Es gibt nur Anforderungen welche mal von diesem "Irgendwas" und mal von jenem "Irgendwas" besser abgedeckt werden.

 

Das wäre bei Shells so, wenn sie disjunkt wären. Nun ist es aber so, dass zsh quasi eine Obermenge für die Features aller Shells darstellt. Wenn es einem also nicht auf Portabilität ankommt (und das heißt eben normalerweise: POSIX oder gar noch weniger), warum soll man dann nicht von allen verügbaren Features Gebrauch machen? bash ist da ein sehr merkwürdiger Kompromiss: Nicht kompatibel und trotzdem nicht mächtig. Man hat also von beiden Seiten nur die Nachteile...

----------

## think4urs11

 *mv wrote:*   

> Andere Distributionen sind wesentlich weniger freier bei der Wahl der Shell.

 

Und welche installieren standardmäßig etwas anderes als die bash? (Weiß ich wirklich nicht, bei allen (Linux-)Systemen an denen ich rumfingere ist bash installiert.)

----------

## STiGMaTa_ch

 *mv wrote:*   

>  *STiGMaTa_ch wrote:*   Ist sie auch... zumindest unter Linux Systemen. 
> 
> Keineswegs. Das ist sie nur bei Gentoo, weil Portage (meint hier: den gesamten Portage-Baum) darauf eingeschossen ist.
> 
> Andere Distributionen sind wesentlich weniger freier bei der Wahl der Shell.

 

Wie Think4UrS11 schon sagte. Welche der grossen Distributionen benutzt als default etwas anderes als bash?

 *mv wrote:*   

> Wenn es so etwas wie eine Standardshell gibt, dann heißt diese POSIX-shell - das ist der einzige festgelegte Standard. [...] bash ist da ein sehr merkwürdiger Kompromiss: Nicht kompatibel und trotzdem nicht mächtig. Man hat also von beiden Seiten nur die Nachteile...

 

Wie kommst du darauf, dass bash nicht kompatibel ist?

```
man bash

[...]

       Bash is intended to be a conformant implementation of the Shell and Utilities portion of  the  IEEE  POSIX  specification  (IEEE

       Standard 1003.1).  Bash can be configured to be POSIX-conformant by default.

[...]

       --posix

              Change  the  behavior  of  bash  where the default operation differs from the POSIX standard to match the standard (posix

              mode).

[...]

       When bash is started in posix mode, as with the --posix command line option, it follows the POSIX standard  for  startup  files.

       In  this  mode,  interactive  shells  expand the ENV variable and commands are read and executed from the file whose name is the

       expanded value.  No other startup files are read.

[...]

```

Lieber Gruss

STiGMaTa

----------

## think4urs11

 *mv wrote:*   

> Andere Distributionen sind wesentlich weniger freier bei der Wahl der Shell.

 

Und weil es gerade ins Auge sticht - bedeutet dieser Satz nicht viel eher 'woanders ist die Auswahl noch kleiner' - war das vom Autor so gewollt?

 *STiGMaTa_ch wrote:*   

> Aber eigentlich ist die Diskussion um "die beste Shell" genau so müssig und unsinnig wie die Diskussion um das beste Linux, das beste Betriebsystem, das beste File System oder den schönsten Busen.

 

Welches davon paßt nicht in eine Diskussion zwischen Geeks?   :Mr. Green: 

----------

## Max Steel

 *Quote:*   

> Welches davon paßt nicht in eine Diskussion zwischen Geeks? 

 

das beste File System @Think

OnTopic:

Nunja, ich würde sagen, es hat schon einen Grund das die Bash die Standardshell ist.

Und es hat bestimmt auch einen Grund warum chroot als Standard nicht die Bash als standard nimmt.

Demnach, jo, ich bleib bei der BAsh.

----------

## firefly

 *Think4UrS11 wrote:*   

>  *mv wrote:*   Andere Distributionen sind wesentlich weniger freier bei der Wahl der Shell. 
> 
> Und weil es gerade ins Auge sticht - bedeutet dieser Satz nicht viel eher 'woanders ist die Auswahl noch kleiner' - war das vom Autor so gewollt?
> 
>  *STiGMaTa_ch wrote:*   Aber eigentlich ist die Diskussion um "die beste Shell" genau so müssig und unsinnig wie die Diskussion um das beste Linux, das beste Betriebsystem, das beste File System oder den schönsten Busen. 
> ...

 

wenn ich tippen müsste, dann kann es sowas von gar nicht das Thema über "das beste Linux" sein  :Wink:  *g*

----------

## mv

 *Think4UrS11 wrote:*   

>  *mv wrote:*   Andere Distributionen sind wesentlich weniger freier bei der Wahl der Shell. 
> 
> Und welche installieren standardmäßig etwas anderes als die bash? (Weiß ich wirklich nicht, bei allen (Linux-)Systemen an denen ich rumfingere ist bash installiert.)

 

Wie Du richtig bemerkt hast, habe ich mich oben vertippt. Es sollte natürlich "wesentlich freier" (oder: "wesentlich weniger einschränkend") heißen.

Meines Wissens hat Debian (und neuerdings möglicherweise auch Ubuntu) die dash als Default-Systemshell. Bei *BSD m.W. sowieso...

----------

## mv

 *Max Steel wrote:*   

> Nunja, ich würde sagen, es hat schon einen Grund das die Bash die Standardshell ist.

 

Wie gesagt: "Standard" nur unter Gentoo. Der Grund ist der existierende Portage-Baum. baselayout-2 versucht nicht ohne Grund, von den bashismen endlich los zu kommen.

----------

## mv

 *STiGMaTa_ch wrote:*   

> Wie kommst du darauf, dass bash nicht kompatibel ist?

 

Sie kann natürlich kompatiblen Code interpretieren (von ein paar exotischen Ausnahmen einmal abgesehen).

Aber wenn man nur kompatiblen Code schreibt, nimmt man besser die dash, weil die das dann wenigstens schneller interpretiert (und man nebenbei eine bessere Kontrolle hat, dass der Code wirklich kompatibel ist).

Die Frage kam aber im Zusammenhang mit Bash-Erweiterungen wie ${!VAR} auf, was eindeutig inkompatibel ist. Wenn man sich entschließt, so etwas zu benutzen, sollte man m.E. lieber gleich den Schritt zu einer wirklich mächtigeren Sprache machen...

Für eine interaktive Shell (also sprich: als login-Shell) gibt es eigentlich gar keinen Grund, nicht zsh zu nehmen.

----------

## mv

 *Max Steel wrote:*   

> Und es hat bestimmt auch einen Grund warum chroot als Standard nicht die Bash als standard nimmt.

 

Wie meinen? Was hat chroot mit einer Shell zu tun?

Ich vermute, Du meinst so etwas wie su, sudo, dchroot. Die nehmen alle, was $SHELL liefert, starten also normalerweise die Shell, in der man sich gerade befindet; welche auch immer das ist...

----------

## STiGMaTa_ch

 *mv wrote:*   

>  *STiGMaTa_ch wrote:*   Wie kommst du darauf, dass bash nicht kompatibel ist? 
> 
> Sie kann natürlich kompatiblen Code interpretieren (von ein paar exotischen Ausnahmen einmal abgesehen).
> 
> Aber wenn man nur kompatiblen Code schreibt, nimmt man besser die dash, weil die das dann wenigstens schneller interpretiert (und man nebenbei eine bessere Kontrolle hat, dass der Code wirklich kompatibel ist).

 

Um kompatiblen Code zu schreiben greife ich immer noch gerne auf das Buch Portable Shell Programming von Bruce Blinn (nur mal so als Tipp für interessierte  :Laughing:  ). Eines der Ziele dieses Buches ist es Zitat:

 *Quote:*   

> This book can teach you how to build shell scripts that are portable across System V and BSD versions of UNIX, and will also work under Korn and POSIX shells.

 

Ich bin mit den Tipps dieses Buches relativ gut gefahren um Scripts zu erstellen welche unter HP-UX 10.20, Solaris 8, Solaris 10 und Linux (diverse Hersteller) laufen sollten.

 *mv wrote:*   

> Die Frage kam aber im Zusammenhang mit Bash-Erweiterungen wie ${!VAR} auf, was eindeutig inkompatibel ist.

 

Stimmt schon. Aber darum heisst das ja auch Bash-Erweiterung  :Wink: 

 *mv wrote:*   

> Wenn man sich entschließt, so etwas zu benutzen, sollte man m.E. lieber gleich den Schritt zu einer wirklich mächtigeren Sprache machen...
> 
> Für eine interaktive Shell (also sprich: als login-Shell) gibt es eigentlich gar keinen Grund, nicht zsh zu nehmen.

 

Und ob es den gibt. Der wichtigste Grund ist die Verbreitung. Die meisten Linuxer verwenden nunmal bash weil "Ihre" Distribution diese Shell als default verwendet hat. Und wir wissen wohl alle, wie schwer es ist, einem Menschen (falsche) Angewohnheiten auszutreiben...

Für den Otto Normal User spielt es doch gar keine Rolle ob die zsh besser ist als die bash. Für die vier Befehle die er einmal im Monat in der Shell eingeben muss reicht die bash völlig aus. Und der "versiertere" Linux Benutzer, der mal ein wenig mehr machen will und dabei Beispiele aus dem Internet holen will, ist froh, wenn er einfach loslegen kann. Das geht wiederum nur deshalb, weil vieles bash bezogen ist.

Ich persönlich benutze zum Beispiel deshalb die zsh nicht, weil ich bisher noch nie das Bedürfnis verspürt habe etwas anderes als die bash zu nutzen. Bisher konnte ich alle Probleme mit der bash lösen ohne irgendwelche "Wursteleien" produzieren zu müssen. Warum sollte ich also zur zsh wechseln wollen? Müsste ich mich die ganze Zeit über Unzulänglichkeiten aufregen, dann würde ich wohl sehr schnell nach alternativen ausschau halten. Aber Fakt ist nunmal, dass die Bash für den Alltäglichen Einsatz so schlecht gar nicht ist. 

Versteh mich nicht falsch. Ich will damit nicht sagen, dass bash besser ist als die zsh. Ich will eigentlich nur damit sagen, dass sie vielleicht nicht alles richtig macht aber auch nicht so viel falsch. Und darauf kommt es an. Wir kennen schliesslich alle so ein Beispiel. Microsoft Windowd versus KDE/GNOME/XFCE und wie sie alle heissen. Jeder könnte sofort eine Unmenge an nachweislichen Gründen aufzeigen warum KDE/GNOME/WHATEVER besser ist als Microsofts Windows. Und doch benutzt immer noch einen Grossteil der Bevölkerung Windows und ist mehrheitlich ganz zufrieden damit.

Manchmal muss man der Schafherde einfach die normale Wiese zum grasen lassen, auch wenn es nebenann die besten Kräuterwiesen gäbe. In diesem Sinne "määääähe" ich weiter mein bash Umfeld ab  :Mr. Green: . Aber wer weiss, vielleicht komme ich auch noch auf den zsh Geschmack  :Wink: 

Lieber Gruss

STiGMaTa

----------

## mv

 *STiGMaTa_ch wrote:*   

> Um kompatiblen Code zu schreiben greife ich immer noch gerne auf das Buch[...]

 

Zu wissen, was kompatibel ist, ist eine Sache. Versehentlich nicht etwas anderes zu benutzen, eine ganz andere. Ich war über mich selbst erstaunt, wieviele Fehler meine kompatibel geglaubten Skripte beim Umstieg bash->dash produziert haben. Sei es mal ein "&>/dev/null" statt eines ">/dev/null 2>&1" (das passiert mir jetzt nicht mehr), sei es mal ein Ausnutzen des nullglob-Features, oder sei es auch nur ein "shift" wenn kein Argument übergeben wurde (das übersieht man sehr leicht) - wenn einem die Shell nicht auf die Finger klopft, ist es schwer, sich solche Unarten abzugewöhnen.   :Wink: 

 *Quote:*   

>  *mv wrote:*   Die Frage kam aber im Zusammenhang mit Bash-Erweiterungen wie ${!VAR} auf, was eindeutig inkompatibel ist. 
> 
> Stimmt schon. Aber darum heisst das ja auch Bash-Erweiterung  

 

Müsste eigentlich ebenfalls ksh/zsh-Erweiterung heißen, denn die haben das m.W. zuerst eingeführt.

 *Quote:*   

>  *mv wrote:*   Für eine interaktive Shell (also sprich: als login-Shell) gibt es eigentlich gar keinen Grund, nicht zsh zu nehmen. 
> 
> Und ob es den gibt. Der wichtigste Grund ist die Verbreitung. Die meisten Linuxer verwenden nunmal bash weil "Ihre" Distribution diese Shell als default verwendet hat. Und wir wissen wohl alle, wie schwer es ist, einem Menschen (falsche) Angewohnheiten auszutreiben...

 

Die Argumente ziehen nicht, weil die zsh alles "versteht", was auch die bash versteht. Nur halt noch mehr. Also "umgewöhnen" muss man sich nicht.

 *Quote:*   

> Und der "versiertere" Linux Benutzer, der mal ein wenig mehr machen will und dabei Beispiele aus dem Internet holen will, ist froh, wenn er einfach loslegen kann. Das geht wiederum nur deshalb, weil vieles bash bezogen ist.

 

Wie gesagt: Das wird in zsh genauso gehen (es gibt zwar ein paar subtile Sachen, die anders laufen könnten, aber wenn man ein sehr komplexes Bash-Skript aus dem Internet hat, schreibt man am Anfang halt "#!/bin/bash" - deswegen braucht man nicht die interaktive Shell zu wechseln).

 *Quote:*   

> Ich persönlich benutze zum Beispiel deshalb die zsh nicht, weil ich bisher noch nie das Bedürfnis verspürt habe etwas anderes als die bash zu nutzen. Bisher konnte ich alle Probleme mit der bash lösen ohne irgendwelche "Wursteleien" produzieren zu müssen. Warum sollte ich also zur zsh wechseln wollen?

 

So hatte ich bis vor ein paar Monaten auch gedacht (und jahrelang mit bash gearbeitet), bis ich mir mal "einfach so" die zsh angeschaut habe. Gerade was die interaktive Bedienung angeht, weiß man gar nicht, was man alles mit der bash versäumt hat: mehr als bash-completion und einfache history und prompt expansion gibt es dort ja nicht. Keine farbigen Directories, in denen man scrollen und auf Tastendruck die Filenamen übernehmen kann, keine ausführbaren Directories und Extensions, kein rekursives Übergeben von Unterdirectories als Argumente, keine bequemen aliase innerhalb einer Zeile, keine Default-Handlung bei leeren Redirection-Kommandos, ...

Leider ist das meiste davon bei der zsh per Default nicht an, aber wenn man sich das einmal eingerichtet und daran gewöhnt hat, ärgert man sich wirklich über die Zeit, in der man sich mit den bash-workarounds behelfen musste.

Und wer schon mal etwas komplexere Skripte geschrieben hat, dem ist es sicher auch schon mal so gegangen, dass er ein Skript, das "eigentlich" ein Shell-Skript sein sollte in perl o.ä. geschrieben hat, nur weil er für eine Teilaufgabe mal assoziative Arrays o.ä. benötigt hat.

 *Quote:*   

> Versteh mich nicht falsch. Ich will damit nicht sagen, dass bash besser ist als die zsh. Ich will eigentlich nur damit sagen, dass sie vielleicht nicht alles richtig macht aber auch nicht so viel falsch. Und darauf kommt es an.

 

Gerade bei einer interaktiven Shell nicht nur. Da kommt es auch schon darauf an, wieviel unnötige Zeichen man für eine bestimmte Standard-Aufgabe tippen muss. Ob ich jetzt also 

```
for i in * do; mv -- "$i" "$i.bak" done

find . -name ".*" -prune -o -exec grep Bla {} +

cd x

emacs y.txt

Bla ... >/dev/null
```

 tippen muss oder auch auch einfach 

```
for i in *; mv -- $i $i.bak

grep Bla **/*

x

y.txt

Bla ... NIL
```

 schreiben kann, läppert sich in der täglichen Arbeit schon zusammen.

 *Quote:*   

> Wir kennen schliesslich alle so ein Beispiel. Microsoft Windowd versus KDE/GNOME/XFCE und wie sie alle heissen. Jeder könnte sofort eine Unmenge an nachweislichen Gründen aufzeigen warum KDE/GNOME/WHATEVER besser ist als Microsofts Windows.

 

Der Vergleich passt deswegen nicht, weil Windows wesentliche Funktionen hat, die bei unixoiden Systemen vollkommen anders funktionieren, oder für die es vielleicht nicht einmal einen Ersatz gibt.

Ein passenderer Vergleich wäre vielleicht notepad (=bash) gegenüber einem luxuriösen Editor: Laden/Speichern/on-screen editieren (=POSIX) und auch Blocks markieren/verschieben/löschen (=bash-completion, History-Mechanismus) funktioniert alles mit notepad, und wenn man noch keinen anderen Editor gesehen hat, vermisst man eigentlich nichts - alles Wichtige geht, und es ist auch nicht sehr schwer. Trotzdem wird man sich ärgern, sich jahrelang darauf beschränkt zu haben, wenn man auf einmal wirkliche Editoren sieht.

Damit das nicht allzu vielen Leuten so (wie mir) mit bash so geht, gebe ich diese Erkenntnis bei Gelegenheiten wie dieser gerne weiter,.

 *Quote:*   

> Und doch benutzt immer noch einen Grossteil der Bevölkerung Windows und ist mehrheitlich ganz zufrieden damit.

 

Und trotzdem wird man (zumindest befreundete) Leute darauf hinweisen, dass es etwas Besseres gibt (wobei man bei Windows aufgrund der anderen Funktionsweise diskutieren kann, was "besser" ist; bei zsh hingegen sehe ich diese Frage nicht, weil ein "Wechsel" keine wirklichen Nachteile aber viele Vorteile hat.)

----------

## Necoro

 *mv wrote:*   

> 
> 
> ```
> for i in *; mv -- $i $i.bak
> ```
> ...

 

Noch kürzer:

for i in *; mv -- $i{,.bak}  :Smile: 

----------

## 69719

 *Necoro wrote:*   

>  *mv wrote:*   
> 
> ```
> for i in *; mv -- $i $i.bak
> ```
> ...

 

gleich lang :p

----------

## think4urs11

ROFL

genaugenommen müßte ich die letzten beiden Posts nach 'Ironie im Forum' abspalten   :Mr. Green: 

----------

