staging.inyokaproject.org

Moin,

ich versuche aus der folgenden Ausgabe zwei Variablen herauszulesen:

patadm 13024 1 0 May18 ? 00:00:00 /bin/sh /usr/sap/patrol/JavaAgent/bin/JavaAgent.sh -sid EDM -id 05

Die beiden Variablen nach -sid und -id sollen in einem Shellskript gespeichert werden. Es sollte dann etwa wie $SID=EDM und $ID=05 aussehen. Bisher habe ich die Ausgabe von ps -ef | grep patadm in eine Textdatei umgeleitet.

Vielen Dank im Voraus!

Würde ich spontan so machen:

ERG=$( ps -ef | grep patadm )

SID=$( echo $ERG | sed -e "s/.* -sid //g" | sed -e s"/ .*//g" )
ID=$( echo $ERG | sed -e "s/.* -id //g" )

echo "SID: $SID"
echo "ID:  $ID"

Sollte so klappen, solange man sich sicher ist, dass die Ausgabe von "ps -ef | grep patadm" immer eindeutige Ergebnisse liefert und sich nie ändert. Ansonsten sollte man diverse Fehlermöglichkeiten doch noch abfangen (was, wenn "ps-ef | grep patadm" mehr als einen Treffer liefert? Wenn sich die Ausgabe leicht ändert und mehrere Spaces liefert? )

Vermutlich geht's sogar ohne externem Programm (sed), mittels Parameter Expansion (http://wiki.bash-hackers.org/syntax/pe), da muesste ich aber selbst erst nachsehen ... 😉

herzlich willkommen im Forum!

Mavericks_Swish schrieb:

ich versuche aus der folgenden Ausgabe zwei Variablen herauszulesen:

patadm 13024 1 0 May18 ? 00:00:00 /bin/sh /usr/sap/patrol/JavaAgent/bin/JavaAgent.sh -sid EDM -id 05

Die beiden Variablen nach -sid und -id sollen in einem Shellskript gespeichert werden. Es sollte dann etwa wie $SID=EDM und $ID=05 aussehen. Bisher habe ich die Ausgabe von ps -ef | grep patadm in eine Textdatei umgeleitet.

Das kann die Shell selber:

1
2
3
4
5
6
7
8
9

input='patadm 13024 1 0 May18 ? 00:00:00 /bin/sh /usr/sap/patrol/JavaAgent/bin/JavaAgent.sh -sid EDM -id 05'

sid="${input##* -sid }"
sid="${sid%% -id*}"

id="${input##* -id }"

echo "sid=$sid"
echo "id=$id"

Das funktioniert, wenn die Reihenfolge immer gleich ist und "-id" immer am Ende steht. Die Lösung arbeitet übrigens so wie die von mike1963.

Sonst würde ich das mit sed so machen:

1
2
3
4
5
6
7

input='patadm 13024 1 0 May18 ? 00:00:00 /bin/sh /usr/sap/patrol/JavaAgent/bin/JavaAgent.sh -sid EDM -id 05'

sid=$(echo "$input" | sed -n 's#.*-sid \([^ ]*\).*#\1#p')
id=$(echo "$input" | sed -n 's#.*-id \([^ ]*\).*#\1#p')

echo "sid=$sid"
echo "id=$id"

mike1963 schrieb:

Würde ich spontan so machen:

ERG=$( ps -ef | grep patadm )

SID=$( echo $ERG | sed -e "s/.* -sid //g" | sed -e s"/ .*//g" )
ID=$( echo $ERG | sed -e "s/.* -id //g" )

echo "SID: $SID"
echo "ID:  $ID"

Ich würde hier "$ERG" ordentlich quoten. Außerdem brauchst Du keine zwei sed-Befehle. Das geht auch mit einem.

Sollte so klappen, solange man sich sicher ist, dass die Ausgabe von "ps -ef | grep patadm" immer eindeutige Ergebnisse liefert und sich nie ändert. Ansonsten sollte man diverse Fehlermöglichkeiten doch noch abfangen (was, wenn "ps-ef | grep patadm" mehr als einen Treffer liefert? Wenn sich die Ausgabe leicht ändert und mehrere Spaces liefert? )

👍

Vermutlich geht's sogar ohne externem Programm (sed), mittels Parameter Expansion (http://wiki.bash-hackers.org/syntax/pe), da muesste ich aber selbst erst nachsehen ... 😉

s.o. ☺

Super, vielen Dank! Hat funktioniert ☺

Die Möglichkeit, dass grep mehrere Ausgaben hat, habe ich erstmal mit einem weiterem grep abgefangen; sollte also erstmals funktionieren.

Mavericks_Swish schrieb:

Die Möglichkeit, dass grep mehrere Ausgaben hat, habe ich erstmal mit einem weiterem grep abgefangen; sollte also erstmals funktionieren.

Wieso "mit einem weiterem grep"? grep kann doch gar nicht zählen. Das kannst Du doch viel besser mit head -1 erledigen. Oder Du nimmst sed:

1

input=$(ps -ef | sed -n '/patadm/{p;q}')

PS: Ist immer gut, wenn man noch mal die Lösung postet, die man verwendet, wenn man sie noch selbst abgewandelt hat. Dann können auch andere profitieren.

rklm schrieb:

... Sonst würde ich das mit sed so machen:

1 2 3

... sid=$(echo "$input" | sed -n 's#.*-sid \([^ ]*\).*#\1#p') ...

mike1963 schrieb:

Würde ich spontan so machen:

... 
SID=$( echo $ERG | sed -e "s/.* -sid //g" | sed -e s"/ .*//g" )
... 

Ich würde hier "$ERG" ordentlich quoten. Außerdem brauchst Du keine zwei sed-Befehle. Das geht auch mit einem.

Zuerstmal mal Danke für Deine fachkundigen Hinweise. 👍

Ob beim sed aber tatsächlich der eine Befehl besser ist ... da bin ich mir ehrlich nicht ganz sicher. Aus dem einfachen Grund, weil ich (und viele andere) sicher nicht die Erfahrung bzw. das Wissen bzgl. der bash haben, welches Du hast. Und wenn ich in einem Jahr wieder mal in ein script reinschauen muss bzw. ändern muss, dann weiss zumindest ich bei der Befehlsfolge:

 echo $ERG | sed -e "s/.* -sid //g" | sed -e s"/ .*//g" 

binnen 3 Sekunden, was das tut, während ich beim Statement

 echo "$input" | sed -n 's#.*-id \([^ ]*\).*#\1#p' 

doch zweimal genauer hinschauen muss, um zu erkennen, was der sed da macht.

Natürlich ist Deine sed-Lösung mit nur einem Aufruf die deutlich "elegantere" und schnellere, und daher eigentlich zu bevorzugen - ich für mich (!) würde aber meinen, dass mir meine dennoch besser gefällt, da ich mit meinem begrenzten Wissen bei meinen beiden sed-Aufrufen deutlich schneller erkenne, was passiert.

Ist wohl auch ein bisschen Geschmackssache ☺

Bringt mich aber zu einem interessanten Thema: Wie schreibt man robuste, wartbare und möglichst systemneutrale Bash-Scripte, welche "ungeschriebenen Gesetze" sollte man beim Schreiben von bash-Skripten befolgen?

Das Thema interessiert mich wirklich - dazu werde ich bei Gelegenheit noch einen Thread eröffnen. 😉

mike1963 schrieb:

rklm schrieb:

Ich würde hier "$ERG" ordentlich quoten. Außerdem brauchst Du keine zwei sed-Befehle. Das geht auch mit einem.

Zuerstmal mal Danke für Deine fachkundigen Hinweise. 👍

Gerne.

Ob beim sed aber tatsächlich der eine Befehl besser ist ... da bin ich mir ehrlich nicht ganz sicher. Aus dem einfachen Grund, weil ich (und viele andere) sicher nicht die Erfahrung bzw. das Wissen bzgl. der bash haben, welches Du hast. Und wenn ich in einem Jahr wieder mal in ein script reinschauen muss bzw. ändern muss, dann weiss zumindest ich bei der Befehlsfolge:

 echo $ERG | sed -e "s/.* -sid //g" | sed -e s"/ .*//g" 

binnen 3 Sekunden, was das tut, während ich beim Statement

 echo "$input" | sed -n 's#.*-id \([^ ]*\).*#\1#p' 

doch zweimal genauer hinschauen muss, um zu erkennen, was der sed da macht.

Jetzt mischt Du Äpfel mit Birnen, vermutlich, weil ich damit angefangen habe. 😬 Du kannst ja auch Deine Lösung mit nur einem sed schreiben, weil Du dann einfach einen Prozess weniger benötigst. Das war der Hauptpunkt mit dem "einen Befehl":

1

echo "$ERG" | sed -e 's/.* -sid //g;s/ .*//g'

(Ich glaube, Du kannst die /g weglassen, weil die Ersetzungen jeweils sowieso nur ein Mal passieren.)

Natürlich ist Deine sed-Lösung mit nur einem Aufruf die deutlich "elegantere" und schnellere, und daher eigentlich zu bevorzugen - ich für mich (!) würde aber meinen, dass mir meine dennoch besser gefällt, da ich mit meinem begrenzten Wissen bei meinen beiden sed-Aufrufen deutlich schneller erkenne, was passiert.

Ob meine tatsächlich messbar schneller ist, steht noch auf einem anderen Blatt.

Ist wohl auch ein bisschen Geschmackssache ☺

Auch, klar.

Bringt mich aber zu einem interessanten Thema: Wie schreibt man robuste, wartbare und möglichst systemneutrale Bash-Scripte, welche "ungeschriebenen Gesetze" sollte man beim Schreiben von bash-Skripten befolgen?

Das Thema interessiert mich wirklich - dazu werde ich bei Gelegenheit noch einen Thread eröffnen. 😉

Ja, das ist auf jeden Fall besser, das als separates Thema zu starten! 👍