Hi, ich habe mir ein kleines Skript angefungen: ,----[ test.sh ]- | #! /bin/sh | | ps aux > .tmp | running="FALSE" | cat .tmp | grep "java" | while read line | do | running="TRUE" | echo $running | done | echo $running | rm .tmp `---- Die Ausgabe lautet dann z.B.: ,----[ out ]- | TRUE | FALSE `---- Das TRUE kommt aus der Schleife, das FALSE danach. Ich wollte noch ein if [[ $running = "TRUE" ]] ; then ... dranhängen, aber das kommt ja nie durch!? Ich bin's immer gewöhnt, das die Sichtbarkeit einer globalen Variable (ich nenn $running jetzt mal so), auch immer so ist, aber running in der Schleife ist scheinbar ein anderes running als ausserhalb. Wie komm ich an den Wert ran? Ciao Sascha -- http://www.livingit.de linux at programmers-world dot com http://www.mobile-bookmarks.info http://www.programmers-world.com Famous last words: (1) Don't unplug it, it will just take a moment to fix. (2) Let's take the shortcut, he can't see us from there. (3) What happens if you touch these two wires tog-- (4) We won't need reservations. (5) It's always sunny there this time of the year. (6) Don't worry, it's not loaded. (7) They'd never (be stupid enough to) make him a manager.
Am Son, 2002-08-04 um 18.11 schrieb Sascha Andres:
Hi,
ich habe mir ein kleines Skript angefungen:
,----[ test.sh ]- | #! /bin/sh | | ps aux > .tmp | running="FALSE" | cat .tmp | grep "java" | while read line | do | running="TRUE" | echo $running | done | echo $running | rm .tmp `----
Die Ausgabe lautet dann z.B.:
,----[ out ]- | TRUE | FALSE `----
Das TRUE kommt aus der Schleife, das FALSE danach. Ich wollte noch ein if [[ $running = "TRUE" ]] ; then ... dranhängen, aber das kommt ja nie durch!?
Ich bin's immer gewöhnt, das die Sichtbarkeit einer globalen Variable (ich nenn $running jetzt mal so), auch immer so ist, aber running in der Schleife ist scheinbar ein anderes running als ausserhalb. Wie komm ich an den Wert ran?
Folgende Syntax funktioniert (getestet) running="FALSE" OLD_IFS="$IFS" IFS=" " for zeile in $(ps aux|grep java|grep -v grep) do running="TRUE" echo $running done IFS="$OLD_IFS" echo $running Warum das running in der while-loop nur lokal ist, weis ich leider auch nicht -- Matthias Hentges [www.hentges.net] "Thats what sucks about windows, you can't say that you rooted some one. Saying "I ADMINISTRATORED YOU!" just doesnt sound cool."
Hallo Sascha, * Sascha Andres [04.08.02 18:11]:
,----[ test.sh ]- | #! /bin/sh | | ps aux > .tmp | running="FALSE" | cat .tmp | grep "java" | while read line | do | running="TRUE" | echo $running | done | echo $running | rm .tmp `----
,----[ ]- | #!/bin/sh | | var1=`ps -ax | grep "java" | grep -v grep` | if [ -z "$var1" ] ; then | echo FALSE | else | echo TRUE | fi | `---- Tuts das? Gruss, Andreas -- "Mit Befremden sehe ich, wie Leute, die Windows einsetzen, täglich abstürzen, sich Viren einfangen oder ihr System neu installieren müssen." Gefunden bei heise.de/newsticker
On Son, 04 Aug 2002 at 18:11 (+0200), Sascha Andres wrote:
ich habe mir ein kleines Skript angefungen:
,----[ test.sh ]- | #! /bin/sh | | ps aux > .tmp | running="FALSE" | cat .tmp | grep "java" | while read line
useless use of cat award ;-) Das geht auch so: grep "java" .tmp | while read line oder noch kürzer (und ohne Umwege über eine temp. Datei): ps aux | grep "java" | while read line
| do | running="TRUE" | echo $running | done | echo $running | rm .tmp `----
Die Ausgabe lautet dann z.B.:
,----[ out ]- | TRUE | FALSE `----
Das TRUE kommt aus der Schleife, das FALSE danach. Ich wollte noch ein if [[ $running = "TRUE" ]] ; then ... dranhängen, aber das kommt ja nie durch!?
Ich kann mir diesen Effekt im Moment nicht erklären (denn eine Subshell liegt offenbar nicht vor - $running ist innerhalb der Schleife bekannt). Ich würde aber wegen sowas keine Schleife aufbauen, man kann das so machen: export running=FALSE ps aux | grep -v grep | grep -q java && export running=TRUE Das nutzt aus, dass grep einen Returncode != 0 wirft, wenn das Suchmuster nicht gefunden wird. Jan P.S.: Man kann Deine Scripts besser kopieren und selber testen, wenn Du die | am Zeilenanfang weglässt. Mache einfach eine Marke, die den Anfang und das Ende des Scripts kennzeichnet.
Jan Trippler schrieb:
[...] useless use of cat award ;-) Das geht auch so: grep "java" .tmp | while read line
oder noch kürzer (und ohne Umwege über eine temp. Datei): ps aux | grep "java" | while read line
Achtung: Damit kannst Du unvorhergesehene Dinge produzieren,
weil Du evtl. auch das
[...] Ich würde aber wegen sowas keine Schleife aufbauen, man kann das so machen:
export running=FALSE ps aux | grep -v grep | grep -q java && export running=TRUE
Hier hast Du obiges Problem abgefangen durch die Option -v, das sollte zuverlaessiger funktionieren. Was macht denn die Option -q, die finde ich gar nicht in der Man-Page...? Gruesse, Thomson -- Thomas Hertweck, Geophysicist Geophysical Institute, University of Karlsruhe
* On Sun, 04 Aug 2002 at 20:24 +0200, Thomas Hertweck wrote:
Jan Trippler schrieb: [...]
[...] Ich würde aber wegen sowas keine Schleife aufbauen, man kann das so machen:
export running=FALSE ps aux | grep -v grep | grep -q java && export running=TRUE
Hier hast Du obiges Problem abgefangen durch die Option -v, das sollte zuverlaessiger funktionieren. Was macht denn die Option -q, die finde ich gar nicht in der Man-Page...?
Warum nicht so? ps aux | grep -q [j]ava && export running=TRUE || export running=FALSE -- just my $0.02, Adalbert PGP welcome, request public key: mailto:adalbert+key@lopez.at
On Son, 04 Aug 2002 at 22:10 (+0200), Adalbert Michelic wrote: [...]
Warum nicht so?
ps aux | grep -q [j]ava && export running=TRUE || export running=FALSE
Diese ... && ... || ... Geschichte habe ich mir ehrlich gesagt abgewöhnt, weil ich ein paar Mal mit Nebeneffekten gekämpft habe. Tausch mal die Reihenfolge aus, und Du erlebst Dein blaues Wunder: ls nicht_existierende_datei || echo nicht da && echo ist da Was ich wieder nicht verstehe: wieso kann man mit [] verhindern, dass grep selbst ein true liefert? Jan
Am Mon, 2002-08-05 um 02.01 schrieb Jan Trippler:
On Son, 04 Aug 2002 at 22:10 (+0200), Adalbert Michelic wrote: [...]
Warum nicht so?
ps aux | grep -q [j]ava && export running=TRUE || export running=FALSE
Diese ... && ... || ... Geschichte habe ich mir ehrlich gesagt abgewöhnt, weil ich ein paar Mal mit Nebeneffekten gekämpft habe. Wirf mal einen Blick in das "Shellology" Kapitel in autoconf.info eines autoconf >= 2.50. Es gibt dort einen eigenen Abschnitt zu diesem Thema.
BTW: grep -q ist ebenfalls eine äusserst fragwürdige Angelegenheit. Aus man grep: -q, --quiet, --silent Quiet; suppress normal output. The scanning will stop on the first match. Also see the -s or --no-messages option below. [..] -s, --no-messages Suppress error messages about nonexistent or unreadable files. Portability note: unlike GNU grep, traditional grep did not conform to POSIX.2, because traditional grep lacked a -q option and its -s option behaved like GNU grep's -q option. Shell scripts intended to be portable to traditional grep should avoid both -q and -s and should redirect output to /dev/null instead.
Tausch mal die Reihenfolge aus, und Du erlebst Dein blaues Wunder: ls nicht_existierende_datei || echo nicht da && echo ist da Nimm test und if/then/else/fi .. ist deutlich zuverlässiger ;)
Was ich wieder nicht verstehe: wieso kann man mit [] verhindern, dass grep selbst ein true liefert? Würde mich auch interessieren - Ich tippe auf Bug.
Ralf
* On Mon, 05 Aug 2002 at 8:16 +0200, Ralf Corsepius wrote:
Am Mon, 2002-08-05 um 02.01 schrieb Jan Trippler:
On Son, 04 Aug 2002 at 22:10 (+0200), Adalbert Michelic wrote: [...] Tausch mal die Reihenfolge aus, und Du erlebst Dein blaues Wunder: ls nicht_existierende_datei || echo nicht da && echo ist da
Das ist klar; wenn Du so ein Konstrukt verwendest, solltest Du Dir schon darüber klar, welche Befehle wo stehen, und welche return-Codes die zurückgeben.
Nimm test und if/then/else/fi .. ist deutlich zuverlässiger ;)
Was ich wieder nicht verstehe: wieso kann man mit [] verhindern, dass grep selbst ein true liefert? Würde mich auch interessieren - Ich tippe auf Bug.
Würde ich nicht sagen. Wenn grep als Ausdruck [j]ava bekommt, steht in der Ausgabe von ps ebenfalls [j]ava. Der reguläre Ausdruck [j]ava matcht aber nicht auf [j]ava, sondern nur auf java. Ergo greppt grep sich nicht selbst heraus. -- Adalbert PGP welcome, request public key: mailto:adalbert+key@lopez.at
* On Mon, 05 Aug 2002 at 10:28 +0200, Adalbert Michelic wrote:
* On Mon, 05 Aug 2002 at 8:16 +0200, Ralf Corsepius wrote:
Am Mon, 2002-08-05 um 02.01 schrieb Jan Trippler:
On Son, 04 Aug 2002 at 22:10 (+0200), Adalbert Michelic wrote: [...] Tausch mal die Reihenfolge aus, und Du erlebst Dein blaues Wunder: ls nicht_existierende_datei || echo nicht da && echo ist da
Das ist klar; wenn Du so ein Konstrukt verwendest, solltest Du Dir schon darüber klar, welche Befehle wo stehen, und welche return-Codes die zurückgeben.
Nimm test und if/then/else/fi .. ist deutlich zuverlässiger ;)
Was ich wieder nicht verstehe: wieso kann man mit [] verhindern, dass grep selbst ein true liefert? Würde mich auch interessieren - Ich tippe auf Bug.
Würde ich nicht sagen. Wenn grep als Ausdruck [j]ava bekommt, steht in der Ausgabe von ps ebenfalls [j]ava. Der reguläre Ausdruck [j]ava matcht aber nicht auf [j]ava, sondern nur auf java. Ergo greppt grep sich nicht selbst heraus.
Achso, dem [j]ava sollte man noch Anführungszeichen spendieren, falls man nicht ausschließen kann, daß sich im aktuellen Verzeichnis mal ein File namens java tummelt ... -- Adalbert PGP welcome, request public key: mailto:adalbert+key@lopez.at
On Mon, 05 Aug 2002 at 10:28 (+0200), Adalbert Michelic wrote:
* On Mon, 05 Aug 2002 at 8:16 +0200, Ralf Corsepius wrote:
Am Mon, 2002-08-05 um 02.01 schrieb Jan Trippler:
On Son, 04 Aug 2002 at 22:10 (+0200), Adalbert Michelic wrote: [...] Tausch mal die Reihenfolge aus, und Du erlebst Dein blaues Wunder: ls nicht_existierende_datei || echo nicht da && echo ist da
Das ist klar; wenn Du so ein Konstrukt verwendest, solltest Du Dir schon darüber klar, welche Befehle wo stehen, und welche return-Codes die zurückgeben.
Mit ist das Zustandekommen des Ergebnis schon klar. Ich wollte damit nur demonstrieren, warum ich bei diesen Konstrukten vorsichtig mit dem Einsatz bin. Es ist eben _keine_ Kurzform von if - then - else (bzw. if ! - then - else) wie die C-Variante "bedingung ? ja : nein". Jan
On Mon, 05 Aug 2002 at 08:16 (+0200), Ralf Corsepius wrote:
Am Mon, 2002-08-05 um 02.01 schrieb Jan Trippler:
On Son, 04 Aug 2002 at 22:10 (+0200), Adalbert Michelic wrote: [...]
Warum nicht so?
ps aux | grep -q [j]ava && export running=TRUE || export running=FALSE
Diese ... && ... || ... Geschichte habe ich mir ehrlich gesagt abgewöhnt, weil ich ein paar Mal mit Nebeneffekten gekämpft habe. Wirf mal einen Blick in das "Shellology" Kapitel in autoconf.info eines autoconf >= 2.50. Es gibt dort einen eigenen Abschnitt zu diesem Thema.
BTW: grep -q ist ebenfalls eine äusserst fragwürdige Angelegenheit. Aus man grep: -q, --quiet, --silent Quiet; suppress normal output. The scanning will stop on the first match. Also see the -s or --no-messages option below.
Da ja nicht die Ausgabe interessiert, ist es in diesem Fall sogar gut, wenn grep nach dem ersten Treffer aufhört. Sprich: grep soll nur feststellen, _dass_ mind. 1 java-Prozess existiert.
[..] -s, --no-messages Suppress error messages about nonexistent or unreadable files. Portability note: unlike GNU grep, traditional grep did not conform to POSIX.2, because traditional grep lacked a -q option and its -s option behaved like GNU grep's -q option. Shell scripts intended to be portable to traditional grep should avoid both -q and -s and should redirect output to /dev/null instead.
Das spielt in dieser Konstruktion keine Rolle. grep liest nicht aus einer Datei, sondern von stdin, also ist mir die Fehlermeldung über nicht vorhandene Dateien wurscht. Jan
Am Mon, 2002-08-05 um 19.56 schrieb Jan Trippler:
On Mon, 05 Aug 2002 at 08:16 (+0200), Ralf Corsepius wrote:
Am Mon, 2002-08-05 um 02.01 schrieb Jan Trippler:
On Son, 04 Aug 2002 at 22:10 (+0200), Adalbert Michelic wrote: [...]
Warum nicht so?
ps aux | grep -q [j]ava && export running=TRUE || export running=FALSE
Diese ... && ... || ... Geschichte habe ich mir ehrlich gesagt abgewöhnt, weil ich ein paar Mal mit Nebeneffekten gekämpft habe. Wirf mal einen Blick in das "Shellology" Kapitel in autoconf.info eines autoconf >= 2.50. Es gibt dort einen eigenen Abschnitt zu diesem Thema.
BTW: grep -q ist ebenfalls eine äusserst fragwürdige Angelegenheit. Aus man grep: -q, --quiet, --silent Quiet; suppress normal output. The scanning will stop on the first match. Also see the -s or --no-messages option below.
Da ja nicht die Ausgabe interessiert, ist es in diesem Fall sogar gut, wenn grep nach dem ersten Treffer aufhört. Sprich: grep soll nur feststellen, _dass_ mind. 1 java-Prozess existiert.
[..] -s, --no-messages Suppress error messages about nonexistent or unreadable files. Portability note: unlike GNU grep, traditional grep did not conform to POSIX.2, because traditional grep lacked a -q option and its -s option behaved like GNU grep's -q option. Shell scripts intended to be portable to traditional grep should avoid both -q and -s and should redirect output to /dev/null instead.
Das spielt in dieser Konstruktion keine Rolle. grep liest nicht aus einer Datei, sondern von stdin, also ist mir die Fehlermeldung über nicht vorhandene Dateien wurscht.
Es geht um -q Lange Rede, kurzer Sinn -q ist nicht portabel. statt "grep -q pattern" besser "grep pattern >/dev/null" => Dein Script funktioniert auf vielen Systemen nicht. z.B.: SunOS4: SYNOPSIS grep [ -bchilnsvw ] [ -e expression ] [ filename... ] z.B. Solaris2.7: SYNOPSIS /usr/bin/grep [ -bchilnsvw ] limited-regular-expression [ filename ... ] /usr/xpg4/bin/grep [-E | -F ] [-c | -l | -q ] [ -bhinsvwx ] -e pattern_list ... [ -f pattern_file ... ] [ file ... ] Ralf
* Jan Trippler schrieb am 05.Aug.2002:
On Son, 04 Aug 2002 at 22:10 (+0200), Adalbert Michelic wrote: [...]
Warum nicht so?
ps aux | grep -q [j]ava && export running=TRUE || export running=FALSE
Was ich wieder nicht verstehe: wieso kann man mit [] verhindern, dass grep selbst ein true liefert?
Es wird nach Zeilen gesucht, in der java steht, nicht nach solchen, in denen [j]ava steht. ;) Bernd -- Alle meine Signaturen sind rein zufällig und haben nichts mit dem Text oder dem Schreiber zu tun, dem ich antworte. Falls irgendwelche Unrichtigkeiten dabei sein sollten, so bedauere ich das. Es wäre nett, wenn Du mich benachrichtigen würdest. |Zufallssignatur 0
Am Mon, 2002-08-05 um 14.51 schrieb Bernd Brodesser:
* Jan Trippler schrieb am 05.Aug.2002:
On Son, 04 Aug 2002 at 22:10 (+0200), Adalbert Michelic wrote: [...]
Warum nicht so?
ps aux | grep -q [j]ava && export running=TRUE || export running=FALSE
Was ich wieder nicht verstehe: wieso kann man mit [] verhindern, dass grep selbst ein true liefert?
Es wird nach Zeilen gesucht, in der java steht, nicht nach solchen, in denen [j]ava steht. ;) Ebend, zumindest nach meinem Verständnis sollte [j]ava eine Regex sein, die als "java" interpretiert wird.
Doch trotzdem findet sich bei mir der grep selbst ... # ps aux | grep -q foobar && echo "JA" || echo "NEIN" JA .. was die ganze Konstruktion in Frage stellt ;) Ralf
Hi, Ralf Corsepius wrote:
Am Mon, 2002-08-05 um 14.51 schrieb Bernd Brodesser:
* Jan Trippler schrieb am 05.Aug.2002:
On Son, 04 Aug 2002 at 22:10 (+0200), Adalbert Michelic wrote: [...]
Warum nicht so?
ps aux | grep -q [j]ava && export running=TRUE || export running=FALSE
Was ich wieder nicht verstehe: wieso kann man mit [] verhindern, dass grep selbst ein true liefert?
Es wird nach Zeilen gesucht, in der java steht, nicht nach solchen, in denen [j]ava steht. ;) Ebend, zumindest nach meinem Verständnis sollte [j]ava eine Regex sein, die als "java" interpretiert wird.
Doch trotzdem findet sich bei mir der grep selbst ... # ps aux | grep -q foobar && echo "JA" || echo "NEIN" JA
Ist doch auch richtig so, denn : #ps aux | grep foobar [Rest gelöscht] grep foobar findet folgerichtig "grep foobar". "NEIN" sollte folgender Ausdruck liefern und das tut er auch: #ps aux | grep -q [f]oobar && echo "JA" || echo "NEIN" NEIN Denn grep sucht nach "foobar", in der Kommandozeile von grep steht aber "[f]oobar" und das entspricht eben nicht dem Suchmuster !
.. was die ganze Konstruktion in Frage stellt ;) Nö.
Ich verwende meistens eine weitere pipe, die das "grep" einfach "rausfiltert" : Also: # ps aux | grep foobar|grep -v grep && echo "JA" || echo "NEIN" NEIN Gruß Harry
Am Mon, 2002-08-05 um 16.44 schrieb Harry Rüter:
Hi,
Ralf Corsepius wrote:
Am Mon, 2002-08-05 um 14.51 schrieb Bernd Brodesser:
* Jan Trippler schrieb am 05.Aug.2002:
On Son, 04 Aug 2002 at 22:10 (+0200), Adalbert Michelic wrote: [...]
Warum nicht so?
ps aux | grep -q [j]ava && export running=TRUE || export running=FALSE
Was ich wieder nicht verstehe: wieso kann man mit [] verhindern, dass grep selbst ein true liefert?
Es wird nach Zeilen gesucht, in der java steht, nicht nach solchen, in denen [j]ava steht. ;) Ebend, zumindest nach meinem Verständnis sollte [j]ava eine Regex sein, die als "java" interpretiert wird.
Denn grep sucht nach "foobar", in der Kommandozeile von grep steht aber "[f]oobar" und das entspricht eben nicht dem Suchmuster !
.. was die ganze Konstruktion in Frage stellt ;) Nö. OK, Ok, der Groschen ist gefallen ... ;)
Danke, Ralf
* Harry Rüter schrieb am 05.Aug.2002:
Ich verwende meistens eine weitere pipe, die das "grep" einfach "rausfiltert" :
Also:
# ps aux | grep foobar|grep -v grep && echo "JA" || echo "NEIN" NEIN
Damit verbräts Du aber einen weiteren Prozeß. grep [f]oobar ist somit besser. Bernd -- Alle meine Signaturen sind rein zufällig und haben nichts mit dem Text oder dem Schreiber zu tun, dem ich antworte. Falls irgendwelche Unrichtigkeiten dabei sein sollten, so bedauere ich das. Es wäre nett, wenn Du mich benachrichtigen würdest. |Zufallssignatur 0
On Mon, 05 Aug 2002 at 02:01 (+0200), Jan Trippler wrote: [...] Verflixt - kam die Mail 2x oder spinnt nur mein mutt? Jan
* Thomas Hertweck schrieb am 04.Aug.2002:
Hier hast Du obiges Problem abgefangen durch die Option -v, das sollte zuverlaessiger funktionieren. Was macht denn die Option -q, die finde ich gar nicht in der Man-Page...?
Es wird keine Ausgabe ausgegeben, nur ein Returncode. Bernd -- Bitte die Etikette beachten: http://www.suse-etikette.de.vu/etikette.html Bitte Realnamen angeben, kein Vollquoting, kein Html, PGP oder Visitenkarten benutzen. Signatur mit "-- " abtrennen, bei Antworten "Re: " voranstellen, sonst nichts. |Zufallssignatur 4
On Son, 04 Aug 2002 at 20:24 (+0200), Thomas Hertweck wrote:
Jan Trippler schrieb:
[...] useless use of cat award ;-) Das geht auch so: grep "java" .tmp | while read line
oder noch kürzer (und ohne Umwege über eine temp. Datei): ps aux | grep "java" | while read line
Achtung: Damit kannst Du unvorhergesehene Dinge produzieren, weil Du evtl. auch das
in der Ausgabe von ps mitbekommst. Das passiert manchmal, manchmal auch nicht, ist wohl mehr oder weniger zufaellig verteilt.
Korrekt. Hatte ich vergessen. Danke für den Hinweis.
[...] Ich würde aber wegen sowas keine Schleife aufbauen, man kann das so machen:
export running=FALSE ps aux | grep -v grep | grep -q java && export running=TRUE
Hier hast Du obiges Problem abgefangen durch die Option -v, das sollte zuverlaessiger funktionieren. Was macht denn die Option -q, die finde ich gar nicht in der Man-Page...?
Bei meinem grep steht sie drin (schon immer ;-): -q, --quiet, --silent Quiet; suppress normal output. The scanning will stop on the first match. Also see the -s or --no- messages option below. Ich brauche nur den Returncode von grep und nicht die Ausgabe, also kommt sie in die Tonne. Ein >/dev/null tuts auch. Jan
Am Sonntag, 4. August 2002 19:35 schrieb Jan Trippler:
On Son, 04 Aug 2002 at 18:11 (+0200), Sascha Andres wrote:
ich habe mir ein kleines Skript angefungen:
,----[ test.sh ]-
| #! /bin/sh | | ps aux > .tmp | running="FALSE" | cat .tmp | grep "java" | while read line ...... Ich kann mir diesen Effekt im Moment nicht erklären (denn eine Subshell liegt offenbar nicht vor - $running ist innerhalb der Schleife bekannt).
Hi Nur mal so interessehalber. Ich kann zwar noch nicht richtig skripten, aber dazu hab' ich jetzt doch ne Frage. Wieso keine Subshell? Habe gerade nochmal in "info bash" geschaut. Ich interpretiere das so, dass jeder Befehl in der Pipe in einer Subshell ausgeführt wird. Ich habe das bisher auch nie bezweifelt, denn die Befehle laufen ja eigentlich parallel. Was stimmt denn nun? Subshell oder nicht Subshell. mfg Axel
Am Son, 2002-08-04 um 22.47 schrieb Axel Heinrici:
Am Sonntag, 4. August 2002 19:35 schrieb Jan Trippler:
On Son, 04 Aug 2002 at 18:11 (+0200), Sascha Andres wrote:
ich habe mir ein kleines Skript angefungen:
,----[ test.sh ]-
| #! /bin/sh | | ps aux > .tmp | running="FALSE" | cat .tmp | grep "java" | while read line ...... Ich kann mir diesen Effekt im Moment nicht erklären (denn eine Subshell liegt offenbar nicht vor - $running ist innerhalb der Schleife bekannt).
Hi
Nur mal so interessehalber. Ich kann zwar noch nicht richtig skripten, aber dazu hab' ich jetzt doch ne Frage. Wieso keine Subshell? Habe gerade nochmal in "info bash" geschaut. Ich interpretiere das so, dass jeder Befehl in der Pipe in einer Subshell ausgeführt wird. Ich habe das bisher auch nie bezweifelt, denn die Befehle laufen ja eigentlich parallel. Was stimmt denn nun? Subshell oder nicht Subshell.
Die Befehle in der Pipe werden in Subschells ausgeführt, und zwar nacheinander (seriell). Hier ging es aber um die Variable "running" die ja nicht aus der Pipe kommt, sondern von der while-Schleife erzeugt wird. Die while-Schleife sollte eigentlich nicht in einer Subshell laufen, was sie aber anscheinend doch macht, da die Variable lokal auf die while-Schleife begrenzt ist - zumindest im angegebenen Beispiel. Ich persönlich nehme fast immer for-loops. Da treten solche Probleme nicht auf. -- Matthias Hentges [www.hentges.net] "Thats what sucks about windows, you can't say that you rooted some one. Saying "I ADMINISTRATORED YOU!" just doesnt sound cool."
Hi Am Sonntag, 4. August 2002 23:39 schrieb Matthias Hentges:
Am Son, 2002-08-04 um 22.47 schrieb Axel Heinrici:
Am Sonntag, 4. August 2002 19:35 schrieb Jan Trippler:
On Son, 04 Aug 2002 at 18:11 (+0200), Sascha Andres wrote:
ich habe mir ein kleines Skript angefungen:
,----[ test.sh ]-
| #! /bin/sh | | ps aux > .tmp | running="FALSE" | cat .tmp | grep "java" | while read line
......
Ich kann mir diesen Effekt im Moment nicht erklären (denn eine Subshell liegt offenbar nicht vor - $running ist innerhalb der Schleife bekannt).
Hi
Nur mal so interessehalber. Ich kann zwar noch nicht richtig skripten, aber dazu hab' ich jetzt doch ne Frage. Wieso keine Subshell? Habe gerade nochmal in "info bash" geschaut. Ich interpretiere das so, dass jeder Befehl in der Pipe in einer Subshell ausgeführt wird. Ich habe das bisher auch nie bezweifelt, denn die Befehle laufen ja eigentlich parallel. Was stimmt denn nun? Subshell oder nicht Subshell.
Die Befehle in der Pipe werden in Subschells ausgeführt, und zwar nacheinander (seriell).
Hmm Ich habe gerade mal zu testen folgendes eingegeben (mp3 ist relativ groß und der tar alleine dauert schon minuten): tar -c mp3 |bzip2 >test.test In ner anderen shell sehe ich dann im top oder mit ps tar und bzip2 gleichzeitig laufen.
Hier ging es aber um die Variable "running" die ja nicht aus der Pipe kommt, sondern von der while-Schleife erzeugt wird.
Die while-Schleife sollte eigentlich nicht in einer Subshell laufen, was sie aber anscheinend doch macht, da die Variable lokal auf die while-Schleife begrenzt ist - zumindest im angegebenen Beispiel.
Auf die Gefahr hin, dass ich mich für doof haltet: In dem Skript steht: "cat .tmp | grep "java" | while read line" Ich verstehe das so, dass grep und die while-Schleife jeweils in einer Subshell laufen. ***verwirrt sei****
Ich persönlich nehme fast immer for-loops. Da treten solche Probleme nicht auf.
Wie auch immer. Für mich sieht das immernoch so aus als ob es an den "|" liegt und nichts an den Eigenschaften der while-loop. Vielleicht raff' ich es morgen. Es ist ja auch schon spät :-) mfg Axel
Am Mon, 2002-08-05 um 00.06 schrieb Axel Heinrici:
Hi
Am Sonntag, 4. August 2002 23:39 schrieb Matthias Hentges:
Am Son, 2002-08-04 um 22.47 schrieb Axel Heinrici:
Am Sonntag, 4. August 2002 19:35 schrieb Jan Trippler:
On Son, 04 Aug 2002 at 18:11 (+0200), Sascha Andres wrote:
ich habe mir ein kleines Skript angefungen:
,----[ test.sh ]-
| #! /bin/sh | | ps aux > .tmp | running="FALSE" | cat .tmp | grep "java" | while read line
......
Ich kann mir diesen Effekt im Moment nicht erklären (denn eine Subshell liegt offenbar nicht vor - $running ist innerhalb der Schleife bekannt).
Hi
Nur mal so interessehalber. Ich kann zwar noch nicht richtig skripten, aber dazu hab' ich jetzt doch ne Frage. Wieso keine Subshell? Habe gerade nochmal in "info bash" geschaut. Ich interpretiere das so, dass jeder Befehl in der Pipe in einer Subshell ausgeführt wird. Ich habe das bisher auch nie bezweifelt, denn die Befehle laufen ja eigentlich parallel. Was stimmt denn nun? Subshell oder nicht Subshell.
Die Befehle in der Pipe werden in Subschells ausgeführt, und zwar nacheinander (seriell).
Hmm Ich habe gerade mal zu testen folgendes eingegeben (mp3 ist relativ groß und der tar alleine dauert schon minuten): tar -c mp3 |bzip2 >test.test
In ner anderen shell sehe ich dann im top oder mit ps tar und bzip2 gleichzeitig laufen.
Hmmmm. Dann habe ich da wohl nen Denkfehler. Du hast Recht und ich behaupte von nun an das Gegenteil :)
Hier ging es aber um die Variable "running" die ja nicht aus der Pipe kommt, sondern von der while-Schleife erzeugt wird.
Die while-Schleife sollte eigentlich nicht in einer Subshell laufen, was sie aber anscheinend doch macht, da die Variable lokal auf die while-Schleife begrenzt ist - zumindest im angegebenen Beispiel.
Auf die Gefahr hin, dass ich mich für doof haltet:
In dem Skript steht: "cat .tmp | grep "java" | while read line"
Ich verstehe das so, dass grep und die while-Schleife jeweils in einer Subshell laufen. ***verwirrt sei****
Ich persönlich nehme fast immer for-loops. Da treten solche Probleme nicht auf.
Wie auch immer. Für mich sieht das immernoch so aus als ob es an den "|" liegt und nichts an den Eigenschaften der while-loop. Vielleicht raff' ich es morgen. Es ist ja auch schon spät :-)
Ich glaube da hast du des Rätsels Lösung gefunden. Ich wusste bis heute garnicht, dass man while als pipe aufrufen kann lol. Aber *da* es hier in der Pipe ist *muss* es ja in einer Subschell laufen. Asche auf mein Haupt und eine Krone auf deins ;) -- Matthias Hentges [www.hentges.net] "Thats what sucks about windows, you can't say that you rooted some one. Saying "I ADMINISTRATORED YOU!" just doesnt sound cool."
On Mon, 05 Aug 2002 at 00:06 (+0200), Axel Heinrici wrote:
Am Sonntag, 4. August 2002 23:39 schrieb Matthias Hentges: [...]
Hier ging es aber um die Variable "running" die ja nicht aus der Pipe kommt, sondern von der while-Schleife erzeugt wird.
Die while-Schleife sollte eigentlich nicht in einer Subshell laufen, was sie aber anscheinend doch macht, da die Variable lokal auf die while-Schleife begrenzt ist - zumindest im angegebenen Beispiel.
Auf die Gefahr hin, dass ich mich für doof haltet:
In dem Skript steht: "cat .tmp | grep "java" | while read line"
Ich verstehe das so, dass grep und die while-Schleife jeweils in einer Subshell laufen. ***verwirrt sei****
Bin ich bei dem Thema auch ;-) Ich kann mich nebulös erinnern, dass ich mal bei einem ziemlich dicken Script mit genau diesem Problem auf die Schnauze gefallen bin - eine Variable aus einer while-Schleife kommt einfach nicht außerhalb der Schleife an. Dass die Schleife nicht in einer Subshell läuft, kann man relativ einfach prüfen: Definiere vor der Schleife eine Variable, ohne sie zu exportieren, dann darf sie nur in der aktuellen Shell bekannt sein. Frage sie innerhalb der while-Schleife ab. Noch verrückter: Verändere sie innerhalb der Schleife nach der Abfrage und schau sie Dir dann an. v=42 while test $v -eq 42; do echo $v v=`expr $v + 624` echo $v done echo $v Das ergibt: 42 666 666 OK, so erwartet man das. Nächster Versuch: v=42 echo $v | while read x; do echo $v $x v=`expr $x + 624` echo $v done echo $v Jetzt sehen wir: 42 42 666 42 Und da komme ich nicht mehr mit! Jan P.S.: Ich bin damals den Weg des geringsten Widerstands gegangen und habe Perl genutzt ;-)
Hallo On Monday 05 August 2002 00:30, Jan Trippler wrote:
On Mon, 05 Aug 2002 at 00:06 (+0200), Axel Heinrici wrote:
Am Sonntag, 4. August 2002 23:39 schrieb Matthias Hentges:
.............
In dem Skript steht: "cat .tmp | grep "java" | while read line"
Ich verstehe das so, dass grep und die while-Schleife jeweils in einer Subshell laufen. ***verwirrt sei****
Bin ich bei dem Thema auch ;-) Ich kann mich nebulös erinnern, dass ich mal bei einem ziemlich dicken Script mit genau diesem Problem auf die Schnauze gefallen bin - eine Variable aus einer while-Schleife kommt einfach nicht außerhalb der Schleife an. Dass die Schleife nicht in einer Subshell läuft, kann man relativ einfach prüfen: Definiere vor der Schleife eine Variable, ohne sie zu exportieren, dann darf sie nur in der aktuellen Shell bekannt sein. Frage sie innerhalb der while-Schleife ab. Noch verrückter: Verändere sie innerhalb der Schleife nach der Abfrage und schau sie Dir dann an.
v=42 while test $v -eq 42; do echo $v v=`expr $v + 624` echo $v done echo $v
Das ergibt: 42 666 666
Hier lief die while-Schleife in der Shell in der das Skript selbst läuft.
OK, so erwartet man das.
Nächster Versuch:
v=42 echo $v | while read x; do echo $v $x v=`expr $x + 624` echo $v done echo $v
Jetzt sehen wir: 42 42 666 42
Und da komme ich nicht mehr mit!
Und hier läuft while in einer Subshell, weil es ein einer pipe ist. Deswegen kommt der Wert der in v ist da nicht raus. Ich finde es verwirrender das die Variablen in der Subshell offenbar erstmal die Werte haben, die in der Hauptshell definiert wurden und nicht leer sind. Jetzt fügt sich bei mir alles wieder zusammen. mfg Axel
* Jan Trippler schrieb am 05.Aug.2002:
v=42 echo $v | while read x; do echo $v $x v=`expr $x + 624` echo $v done echo $v
Jetzt sehen wir: 42 42 666 42
Und da komme ich nicht mehr mit!
Bau in den echos auch noch mal $$ ein, und Du wirst sehen, daß es sich um den gleichen Prozeß handelt. Alles sehr strange. Bernd -- ROTFL = Rolling On The Floor, Laughing = Auf dem Boden wälzen, lachend. SCNR = Sorry, Could Not Resist = Sorry, Ich konte nicht wiederstehen. AFAIK = As Far As I Know = So weit ich weis|BTW = By The Way = Nebenbei bemerkt IMHO = In My Humble Opinion = meiner bescheidenen Meinung nach |Zufallssig. 9
On Sun, 4 Aug 2002 19:35:01 +0200 Jan.Trippler@t-online.de (Jan Trippler) wrote:
On Son, 04 Aug 2002 at 18:11 (+0200), Sascha Andres wrote:
ich habe mir ein kleines Skript angefungen: [...] Das TRUE kommt aus der Schleife, das FALSE danach. Ich wollte noch ein if [[ $running = "TRUE" ]] ; then ... dranhängen, aber das kommt ja nie durch!?
Ich kann mir diesen Effekt im Moment nicht erklären (denn eine Subshell liegt offenbar nicht vor - $running ist innerhalb der Schleife bekannt). Ich würde aber wegen sowas keine Schleife aufbauen, man kann das so machen:
Ja, diese Frage taucht immer wieder auf, ich habe aber seit Jahren keine andere Antwort gefunden, als dass die while Schleife eine Subshell ist. Nicht nur in der BASH, mir ist das zum Ersten mal mit der Shell von SCO 3.2 untergekommen. Was aber hilft[1] ist: ---------8<------------- declare running=FALSE while ... ... done hmm, jetzt wollte ich das grade bei mir nachvollziehen... denkste es funktioniert. Sowohl in der Kommandozeile wie als Script. --------8<-------- [bernd@burdon]-5-xterm-color ~ 560 > i=3;echo $i;while test $i -lt 10 ; do i=$(expr $i + 1 );done;echo $i GNU bash, version 2.04.0(1)-release (i386-suse-linux) Copyright 1999 Free Software Foundation, Inc. ---------8<---------- Da bin ich platt ;) Mit dem Script von Sascha gehts nicht, auch nicht mit declare. Allerdings: ---------8<---------- ps aux | grep "bash" > .tmp running="FALSE" while read line do running="TRUE" echo $running done < .tmp echo $running rm .tmp ---------8<---------- geht wieder. Es liegt wohl an der seltsamen (und unnötigen) Konstruktion mit der Pipe.. ps aux > .tmp running="FALSE" cat .tmp | grep "java" | while read line ... [1] Ja das hat sich wohl etwas relativiert ;) -- so long... bernd ------------------------------------------------------------------------
Bernd Obermayr schrieb:
[...] Da bin ich platt ;)
Mit dem Script von Sascha gehts nicht, auch nicht mit declare. Allerdings: ---------8<---------- ps aux | grep "bash" > .tmp running="FALSE" while read line do running="TRUE" echo $running done < .tmp echo $running rm .tmp ---------8<---------- geht wieder. Es liegt wohl an der seltsamen (und unnötigen) Konstruktion mit der Pipe..
Aus dem Manual zu "bash": Each command in a pipeline is executed as a separate process (i.e., in a subshell). [...] If a command is terminated by the control operator &, the shell executes the command in the background in a subshell. [...] "(list)": list is executed in a subshell. [...] Command substitution and asynchronous commands are invoked in a subshell environment that is a duplicate of the shell environment, except that traps caught by the shell are reset to the values that the shell inherited from its parent at invocation. Builtin commands that are invoked as part of a pipeline are also executed in a subshell environment. Changes made to the subshell environment cannot affect the shell's execution environment. Da stehts eigentlich, oder? :-) Gruesse, Thomson *...der hier wieder mal was gelernt hat* -- Thomas Hertweck, Geophysicist Geophysical Institute, University of Karlsruhe
On Mon, 05 Aug 2002 at 14:42 (+0200), Thomas Hertweck wrote: [...]
Aus dem Manual zu "bash":
Each command in a pipeline is executed as a separate process (i.e., in a subshell). [...] If a command is terminated by the control operator &, the shell executes the command in the background in a subshell. [...] "(list)": list is executed in a subshell. [...] Command substitution and asynchronous commands are invoked in a subshell environment that is a duplicate of the shell environment, except that traps caught by the shell are reset to the values that the shell inherited from its parent at invocation. Builtin commands that are invoked as part of a pipeline are also executed in a subshell environment. Changes made to the subshell environment cannot affect the shell's execution environment.
Da stehts eigentlich, oder? :-)
Mist - man sollte sich selbst ab und zu eine Mail mit dem Inhalt *RTFM* schicken ;-) Also _ist_ es eine Subshell (gleiche Prozess-ID - siehe Bernds Mail deshalb, weil while ein Shell-Builtin ist), die aber die Umgebung der startenden Shell kopiert kriegt (also doch keine richtige Subshell?). Der Trick, wenn man eine Schleife braucht, ist also, wie Lars gezeigt hat, auf die Pipes zu verzichten und stattdessen stdin umzuleiten. Wieder was gelernt (und die Verwirrung etwas abgebaut). Jan
On Mon, 05 Aug 2002 14:42:12 +0200
Thomas Hertweck
Bernd Obermayr schrieb: [...]
Es liegt wohl an der seltsamen (und unnötigen) Konstruktion mit der Pipe..
Aus dem Manual zu "bash":
Each command in a pipeline is executed as a separate process (i.e., in a subshell). [...] If a command is terminated by the control operator &, the shell executes the command in the background in a subshell. [...] "(list)": list is executed in a subshell. [...] Command substitution and asynchronous commands are invoked in a subshell environment that is a duplicate of the shell environment, except that traps caught by the shell are reset to the values that the shell inherited from its parent at invocation. Builtin commands that are invoked as part of a pipeline are also executed in a subshell environment. Changes made to the subshell environment cannot affect the shell's execution environment.
Da stehts eigentlich, oder? :-)
Jaja ;)
Gruesse, Thomson *...der hier wieder mal was gelernt hat*
-- so long... bernd *...der auch was gelernt hat* ------------------------------------------------------------------------
Hi, Am 04.08.2002 (19:35) schrieb Jan Trippler:
export running=FALSE ps aux | grep -v grep | grep -q java && export running=TRUE
Danke für die vielen Antworten. So hab ichs dann gemacht. Ciao Sascha -- http://www.livingit.de linux at programmers-world dot com http://www.mobile-bookmarks.info http://www.programmers-world.com Das große Karthago führte drei Kriege. Nach dem ersten war es noch mächtig. Nach dem zweiten war es noch bewohnbar. Nach dem dritten war es nicht mehr zu finden. -- Bertold Brecht
Hallo Sascha, hallo Leute, Sascha, darf ich Dir ein paar Preise verleihen? Am Sonntag, 4. August 2002 18:11 schrieb Sascha Andres:
ich habe mir ein kleines Skript angefungen:
,----[ test.sh ]- | #! /bin/sh | | ps aux > .tmp
Das gibt erstmal den "Useless use of temp-file award" ;-) Außerdem ist es evtl. ein Risiko, einen so allgemeinen Namen für ein Tempfile zu verwenden (z. B. Überschneidung mit anderen Programmen/Scripten, Datenverlust durch "boshafte" SymLinks [1], ...) Apropos Tempfile: Die Datei .tmp wird bei Deinem Script im aktuellen Verzeichnis erstellt, was wohl nicht unbedingt sinnvoll ist. Für sowas gibt es ja schließlich /tmp ;-)
| running="FALSE" | cat .tmp | grep "java" | while read line
Hiermit verleihe ich Dir den "Useless use of cat award" ;-) Übrigens wirst Du garantiert immer TRUE erhalten, da zumindest die Zeile "grep java" von ps gelistet wird -> deshalb grep -v grep
| do | running="TRUE" | echo $running | done
Ach ja, einen "Useless use of while ... do ... done award" verleihe ich Dir auch gleich noch. Für diesen Zweck braucht man doch wirklich keine Schleife ;-)
| echo $running | rm .tmp `----
Soweit die Preisverleihung ;-) *SCNR* Als Kurzform (und nicht preisverdächtig ;-) würde ich folgendes Konstrukt empfehlen: #!/bin/sh running="FALSE" ps aux | grep java | grep -v grep > /dev/null && running="TRUE" echo $running Kurze Erklärung: - ps aux wird direkt an grep java [2] gepipt - die Ausgabe des ersten grep geht direkt an ein grep -v grep (würde man diesen Schritt auslassen, würde die Zeile grep java aus der ps-Ausgabe einen "false positive" erzeugen. - > /dev/null (also ins digitale Nirwana) geht das Ganze, weil mich nur der Exitcode (auch mit echo $? abzufragen) interessiert - && bedeutet, dass das Folgende nur ausgeführt wird, wenn der vorhergehende Prozess den Exitcode 0 hinterlassen hat [3] [4] - running="TRUE" setzt schließlich $running auf TRUE Ach so, die Variable $running könntest Du evtl. noch einsparen, indem Du das running="TRUE" gleich durch den Befehl ersetzt, der ausgeführt werden soll. (also ... && tue_etwas statt ... && running="TRUE") Allerdings kann das etwas unübersichtlich werden, falls Du mehrere Befehle ausführen möchtest. Für diesen Fall ist eine eigentlich überflüssige Variable die besser lesbare Lösung ;-) Gruß Christian Boltz [1] z. B. /tmp/.tmp -> /home/Mail/inbox :-| [2] grep java benötigt keine " um java - die brauchst Du nur, wenn der Suchtext Leerzeichen oder Sonderzeichen, die die Shell interpretieren möchte (z. B. * und ?) enthält. Wenn Dein Suchstring für grep auch ein $irgendwas enthält, wird die Verwendung von ' (Shift + #) als Quotingzeichen interessant, da die Bash bei grep "$text" $text durch den Inhalt der Variable $text ersetzt. grep '$text' sucht wirklich nach $text als Text. Wenn ein $ am Ende des Suchstrings steht, wird es übrigens als Zeilenende interpretiert. Um also z. B. nach test$ als Text zu greppen, rufst Du grep 'test\$' auf. [3] in diesem Fall der Prozess grep -v grep Exitcodes von grep: 0 - mindestens eine Fundstelle 1 - keine Fundstelle [4] Das Gegenteil von && ist übrigens || - dann wird der Rest der Zeile nur ausgeführt, wenn der Exitcode ungleich 0 ist -- Registrierter Linux-Nutzer #239431 Linux - life is too short for reboots.
On Son, 04 Aug 2002 at 23:40 (+0200), Christian Boltz wrote:
Am Sonntag, 4. August 2002 18:11 schrieb Sascha Andres:
ich habe mir ein kleines Skript angefungen:
,----[ test.sh ]- | #! /bin/sh | | ps aux > .tmp
Das gibt erstmal den "Useless use of temp-file award" ;-)
Im ersten Moment gebe ich Dir recht - nur weiss man ja nicht, ob er später die gleiche Datei noch mal nutzt. Ich habe die temp. Datei auch in Frage gestellt, aber preisverdächtig ist das noch nicht (der ps ist ziemlich lange unterwegs, es kann sich schon lohnen, die Ausgabe in einer Datei vorzuhalten).
Außerdem ist es evtl. ein Risiko, einen so allgemeinen Namen für ein Tempfile zu verwenden (z. B. Überschneidung mit anderen Programmen/Scripten, Datenverlust durch "boshafte" SymLinks [1], ...)
ACK. Abhilfe: tempnam und Co.
Apropos Tempfile: Die Datei .tmp wird bei Deinem Script im aktuellen Verzeichnis erstellt, was wohl nicht unbedingt sinnvoll ist. Für sowas gibt es ja schließlich /tmp ;-)
Jein. Das Script sagt nichts zum Ausführungsort - das kann auch /tmp sein. Und ganz nebenbei kann das auch dem Problem der Überschneidung mit anderen Programmen abhelfen. Nutze ich ein privates Verzeichnis, ist die Gefahr einer Namenskollision geringer. Ich würde es aber auch nicht so machen - ich räume nun mal nicht gern ständig auf ;-)
| running="FALSE" | cat .tmp | grep "java" | while read line
Hiermit verleihe ich Dir den "Useless use of cat award" ;-)
Jepp - aber den hat er schon von mir *fg*
Übrigens wirst Du garantiert immer TRUE erhalten, da zumindest die Zeile "grep java" von ps gelistet wird -> deshalb grep -v grep
Nö, eben nicht. Da die Ausgabe des ps _vor_ der Schleife mit dem grep kommt, kann er da auch nicht auftauchen (es sei denn, das Script lief zufälligerweise zur gleichen Zeit auf einem anderen Terminal). Da hat mal die temp. Datei die Nase vorn :-) Jan P.S.: Unter SuSE ist checkproc (und seine Vettern startproc und killproc) einen Blick wert.
Am Sonntag, 4. August 2002 18:11 schrieb Sascha Andres: ...
Das TRUE kommt aus der Schleife, das FALSE danach. Ich wollte noch ein if [[ $running = "TRUE" ]] ; then ... dranhängen, aber das kommt ja nie durch!?
Ich bin's immer gewöhnt, das die Sichtbarkeit einer globalen Variable (ich nenn $running jetzt mal so), auch immer so ist, aber running in der Schleife ist scheinbar ein anderes running als ausserhalb. Wie komm ich an den Wert ran?
Ciao Sascha
Das Problem ist IMHO, daß durch die Pipes ein jeweiliges fork() der aktuellen Shell erfolgt und somit die Kommandos in einzelnen Subshells laufen. Die Variable running wäre somit in der Schleife eine lokale Definition. Änderst Du dagegen das Skript nur leicht ab, so läuft die Schleife in der aufgerufenen Shell: #! /bin/sh ps aux > .tmp declare running="FALSE" cat .tmp | grep "java" > .tmp1 while read line do running="TRUE" echo $running done < .tmp1 echo $running rm .tmp*
participants (13)
-
Adalbert Michelic -
Andreas Kneib -
Axel Heinrici -
B.Brodesser＠t-online.de -
Bernd Obermayr -
Christian Boltz -
Harry Rüter -
Jan.Trippler＠t-online.de -
Lars Zimmermann -
Matthias Hentges -
Ralf Corsepius -
Sascha Andres -
Thomas Hertweck