Ergebnis Befehl -> in Variable schreiben
Hi Leute, wie kann ich das Ergebnis eines Befehls, z.B. server:~ # tail /var/log/allmessages | awk '{ print $2 }' in eine Variable schreiben lassen? Ich rufe die Zeile also aus einem bash-script auf und möchte das Ergebnis dann in einer Variablen haben, um es weiterverwenden zu können. Michael
Hallo zusammen! Fragen rund ums Scripten mit bash: www.linuxdoc.org -> Hier gibt es bei den Guides auch die Advanced Bash Scripting Guide Bitte einfach einmal lesen. Ansonsten einfach einmal die Funktion der "´" nachlesen. Mit den besten Grüßen, Konrad Neitzel -- SoftMediaTec GmbH Tel: 0172 / 689 31 45 Fax: 069 / 90 50 99 53
Michael Jakscht wrote:
Hi Leute,
wie kann ich das Ergebnis eines Befehls, z.B.
server:~ # tail /var/log/allmessages | awk '{ print $2 }'
in eine Variable schreiben lassen? Ich rufe die Zeile also aus einem bash-script auf und möchte das Ergebnis dann in einer Variablen haben, um es weiterverwenden zu können.
Michael
#!/bin/bash Mit... result=`tail /var/log/allmessages | awk '{ print $2 }` erhaelst du die Ausgaben von awk in $result oder mit ... set `tail /var/log/allmessages | awk '{ print $2 }'` erhaeltst du die Ausgaben in den Positionsparametern der Shell ($1,$2, etc) jeweils kannst du mittels Abfrage der Bash Varaiblen '$?' ermitteln welcher Exitcode generiert wurde.( echo $?) Ansonsten mal in die man pages von bash reinschauen Daniel
Hi, myself@suse.de [mailto:myself@suse.de] schrieb am Thursday, April 11, 2002 3:28 PM:
result=`tail /var/log/allmessages | awk '{ print $2 }` erhaelst du die Ausgaben von awk in $result
Oi, ich hatte ergebnis = 'tail blabla | awk '{blabla}'' probiert. Hat natürlich auch nicht geklappt. Lag das auch an dem spacing zwischen ergebnis und dem befehl? Michi
Moin,
* Michael Jakscht
myself@suse.de [mailto:myself@suse.de] schrieb am Thursday, April 11, 2002 3:28 PM: Falsche Attributions sollte man niemals setzen.
result=`tail /var/log/allmessages | awk '{ print $2 }` erhaelst du die Ausgaben von awk in $result Oi, ich hatte
ergebnis = 'tail blabla | awk '{blabla}''
probiert. Hat natürlich auch nicht geklappt. Lag das auch an dem spacing zwischen ergebnis und dem befehl? Leerzeichen sind verboten. Ich kenne keine Shell, bei der das klappt.
Thorsten -- He who receives an idea from me, receives instruction himself without lessening mine; as he who lights his taper at mine, receives light without darkening me. - Thomas Jefferson
* Michael Jakscht schrieb am 11.Apr.2002:
Oi, ich hatte
ergebnis = 'tail blabla | awk '{blabla}''
probiert. Hat natürlich auch nicht geklappt. Lag das auch an dem spacing zwischen ergebnis und dem befehl?
Es lag vor allem an die falche Quotingzeichen. Richtig ist ` flasch ist ' '..' heißt, es wird alles so wie es ist genommen bis auf \ und ' selber. `..` heißt, alles was zwichen den ` ` steht wird ausgeführt und die Ausgabe des Befehls genommen. ergebnis='tail blabla | awk {blabla}' Hier steht in $ergebnis: tail blabla | awk {blabla} Also erstes Zeichen t, zweites a, drittes i usw. ergebnis=`tail blabla | awk '{blabla}'` Hier steht in $ergebnis die Ausgabe von awk Bernd -- LILO funktioniert nicht? Hast Du /etc/lilo.conf verändert und vergessen, lilo aufzurufen? Ist Deine /boot-Partition unter der 1024 Zylindergrenze? Bei anderen LILO Problemen mal in der SDB nachschauen: http://localhost/doc/sdb/de/html/rb_bootdisk.html |Zufallssignatur 6
B.Brodesser@t-online.de (Bernd Brodesser) [ Thu, 11 Apr 2002 18:08:33 +0200]:
`..` heißt, alles was zwichen den ` ` steht wird ausgeführt und die Ausgabe des Befehls genommen.
Wobei ich die Bash-Spezialität $() bevorzuge, denn da gibt es auch keine Probleme mit der Schachtelung. Philipp
On 14 Apr 2002 at 2:13, Philipp Thomas wrote:
B.Brodesser@t-online.de (Bernd Brodesser) [ Thu, 11 Apr 2002 18:08:33 +0200]:
`..` heißt, alles was zwichen den ` ` steht wird ausgeführt und die Ausgabe des Befehls genommen.
Wobei ich die Bash-Spezialität $() bevorzuge, denn da gibt es auch keine Probleme mit der Schachtelung.
Nur so 'ne kleine Anmerkung: Das ist mitnichten ein Bash-Spezialität. Ich kenne zwar csh, tcsh und deren Abkömmlinge nicht, aber die $() Schreibweise ist definitiv in der Kornshell enthalten. AFAIK allerdings nicht in der Bourneshell, so daß man manchmal aus Gründen der Kompatibilität doch darauf verzichten wird. Andreas
Moin,
* Michael Jakscht
server:~ # tail /var/log/allmessages | awk '{ print $2 }' (Der heißt nicht wirklich "server", oder?)
in eine Variable schreiben lassen? Ich rufe die Zeile also aus einem bash-script auf und möchte das Ergebnis dann in einer Variablen haben, um es weiterverwenden zu können. Mit der Bash oder Zsh: variable=$(tail /var/log/allmessages | awk '{ print $2 }') Mit jeder Shell: variable=`tail /var/log/allmessages | awk '{ print $2 }'`
Thorsten -- The opposite of the above statement is also true.
On Thu, Apr 11, 2002 at 02:54:16PM +0200, Michael Jakscht wrote:
wie kann ich das Ergebnis eines Befehls, z.B.
server:~ # tail /var/log/allmessages | awk '{ print $2 }'
in eine Variable schreiben lassen? Ich rufe die Zeile also aus einem bash-script auf und möchte das Ergebnis dann in einer Variablen haben, um es weiterverwenden zu können.
Z. B. mit Backticks: ,---- | #!/bin/sh | VAR=`tail /var/log/allmessages | awk '{ print $2 }'` | echo $VAR `---- MfG, Peter -- The trouble with superheros is what to do between phone booths. -- Ken Kesey
Hi, Peter Schneewind [mailto:peter@schneewind.net] schrieb am Thursday, April 11, 2002 3:29 PM:
On Thu, Apr 11, 2002 at 02:54:16PM +0200, Michael Jakscht wrote:
server:~ # tail /var/log/allmessages | awk '{ print $2 }'
Z. B. mit Backticks:
,---- | #!/bin/sh | VAR=`tail /var/log/allmessages | awk '{ print $2 }'` | echo $VAR `----
Sehr gut, danke danke, es funktioniert jetzt. Nur eine Frage habe ich noch: Wie kann ich erreichen, dass ich das 1. und das 2. Feld auslese? Klar, mit awk '{ print $1 $2 }', kein Thema. Da fehlt mir dann aber ein space zwischen den beiden Zeilen. Wie kann ich den dazwischenschieben? Michi
Hallo,
Hi,
Peter Schneewind [mailto:peter@schneewind.net] schrieb am Thursday, April 11, 2002 3:29 PM:
On Thu, Apr 11, 2002 at 02:54:16PM +0200, Michael Jakscht wrote:
server:~ # tail /var/log/allmessages | awk '{ print $2 }'
Z. B. mit Backticks:
,---- | #!/bin/sh | VAR=`tail /var/log/allmessages | awk '{ print $2 }'` | echo $VAR `----
Sehr gut, danke danke, es funktioniert jetzt. Nur eine Frage habe ich noch: Wie kann ich erreichen, dass ich das 1. und das 2. Feld auslese? Klar, mit awk '{ print $1 $2 }', kein Thema. Da fehlt mir dann aber ein space zwischen den beiden Zeilen. Wie kann ich den dazwischenschieben?
sollte so gehen: awk '{ print $1, " ", $2 }'
Michi
Gruß Alex
Am Donnerstag, 11. April 2002 16:04 schrieb Alexander Sommer:
Peter Schneewind [mailto:peter@schneewind.net] schrieb am Thursday,
Sehr gut, danke danke, es funktioniert jetzt. Nur eine Frage habe ich noch: Wie kann ich erreichen, dass ich das 1. und das 2. Feld auslese? Klar, mit awk '{ print $1 $2 }', kein Thema. Da fehlt mir dann aber ein space zwischen den beiden Zeilen. Wie kann ich den dazwischenschieben?
sollte so gehen:
awk '{ print $1, " ", $2 }'
Das ergibt _drei_ Leerzeichen. Eines erhältst Du mit
$ awk '{ print $1, $2 }' # oder mit
$ awk '{ print $1 " " $2 }'
Gruß
Bertram
--
Bertram Scharpf
Hey ;-)) Bin ich zu blöd?? Gucke gerade auch noch in meinem Buch nach, werde aber überhaupt nicht fündig, da steht's nit drin: Kann ich mit if keinen grösser/kleiner/gleich-Vergleich durchführen?????? Habe folgendes versucht (bash-shell) if [ "$test_variable" <= "10" ] ; then echo "$test_variable" fi Rufe ich das Script, in dem der if-Teil vorkommt auf, erhalte ich einen Fehler server:~ # ./script.sh: =: No such file or directory Nun jetzt verstehe ich die Welt nicht mehr. Wenn ich das < - Zeichen wegnehme und die Zahl einfach vergleichen lasse gehts, aber wieso nicht mit grösser/kleiner- Operatoren? Steh' mal wieder auf'm Schlauch... Grüsse, Michi
Michael Jakscht wrote:
Hey ;-))
Bin ich zu blöd?? Gucke gerade auch noch in meinem Buch nach, werde aber überhaupt nicht fündig, da steht's nit drin: Kann ich mit if keinen grösser/kleiner/gleich-Vergleich durchführen??????
Habe folgendes versucht (bash-shell)
if [ "$test_variable" <= "10" ] ; then echo "$test_variable" fi
Rufe ich das Script, in dem der if-Teil vorkommt auf, erhalte ich einen Fehler
server:~ # ./script.sh: =: No such file or directory
Nun jetzt verstehe ich die Welt nicht mehr. Wenn ich das < - Zeichen wegnehme und die Zahl einfach vergleichen lasse gehts, aber wieso nicht mit grösser/kleiner- Operatoren?
Steh' mal wieder auf'm Schlauch...
#!/bin/bash test_variable=11 if [ $test_variable -le 10 ] ; then echo "$test_variable" fi Daniel
Hey ;-)) Michael Jakscht [mailto:michael@jakscht.de] schrieb am Thursday, April 11, 2002 5:03 PM:
Kann ich mit if keinen grösser/kleiner/gleich-Vergleich durchführen??????
Hat sich erledigt, hab's hingekriegt. Natürlich nicht mit <= sondern mit -lt Wie gesagt, stand mal wieder auf' schlauch ;-)) Michi
Michael Jakscht wrote:
Hey ;-))
Michael Jakscht [mailto:michael@jakscht.de] schrieb am Thursday, April 11, 2002 5:03 PM:
Kann ich mit if keinen grösser/kleiner/gleich-Vergleich durchführen??????
Hat sich erledigt, hab's hingekriegt. Natürlich nicht mit <= sondern mit -lt
Eben nicht! 'lt' bedeutet 'lower than' und nicht 'lower or equal' - was 'le' waere!
Wie gesagt, stand mal wieder auf' schlauch ;-))
Michi
Daniel
Hi! myself@suse.de [mailto:myself@suse.de] schrieb am Thursday, April 11, 2002 5:27 PM:
Eben nicht! 'lt' bedeutet 'lower than' und nicht 'lower or equal' - was 'le' waere!
klar, weiss ich doch ;-)) und deswegen habe ich auch lt genommen. Heisst es nicht "less or equal" und "less than" ?? Und ob ich -lt 10 oder -le 9 mache ist in meinem fall vollkommen wurscht. anderes problem: wieso kann ich aus meinem script nicht folgenden befehl ausführen? cat $1 | grep '$2 $3' | grep '$4' sehr wohl aber tail $1 ?????? Ideen?? Michi
* Michael Jakscht schrieb am 11.Apr.2002:
wieso kann ich aus meinem script nicht folgenden befehl ausführen?
cat $1 | grep '$2 $3' | grep '$4'
Kanst Du sehr wohl, macht aber nicht das, was Du erwartest. '..' quotet alles was dazwichen steht. grep bekommt hier $2 $3 bzw. $4 mit, und nicht den Inhalt dieser Variablen. Es wirs somit nach der Zeichenkette $2 $3 gesucht und nicht nach dem zweiten und dritten Argument Deines Aufrufes. Was Du willst ist: cat $1 | grep "$2 $3" | grep "$4" Innerhalb einer ".." Umgebung werden Variablen ersetzt. Hier wird $2 und $3 durch ihre Inhalte ersetzt, aber das Leerzeichen dazwichen bleibt erhalten.
sehr wohl aber
tail $1
Hier wird gar nicht gequotet, könnte Problematisch werden, wenn der Inhalt von $1 Leerzeichen oder gar Zeilenumbrüche enthält. Bernd -- Probleme mit dem Drucker? Schon die Druckercheckliste beachtet? http://localhost/doc/sdb/de/html/drucker-howto.html | Auch lesenswert: Oder schon das Drucker-HOWTO gelesen? | man lpr file://usr/shar/doc/howto/de/DE-Drucker-HOWTO.txt.gz | Zufallssignatur 3
Hallo, Am Donnerstag, 11. April 2002 17:46 schrieb Michael Jakscht:
anderes problem:
wieso kann ich aus meinem script nicht folgenden befehl ausführen?
cat $1 | grep '$2 $3' | grep '$4'
sehr wohl aber
tail $1
??????
Ideen??
Jepp. Bei '$2' findet keine Expansion von $2 statt, anstelle dessen wird nach der Zeichenfolge $2 gegreppt. Setze mal oben "$2 $3" ein, dann sollte es gehen. Schöne Grüße, Stephan
Hallo, On Thu, 11 Apr 2002, Michael Jakscht wrote:
if [ "$test_variable" <= "10" ] ; then echo "$test_variable" fi
[ ist ein alias (oder so) auf test, und dazu sagt dir 'help [' bzw. 'help test' alles noetige... -dnh PS: ja, ich weiss, die Antwort ist ueberfluessig, ist aber allgemein gemuenzt!!! -- SprintLINK makes proton decay look fast. -- Jude Charles Giampaolo
Hallo, On Fri, 12 Apr 2002 at 09:02 (+0200), David Haller wrote:
On Thu, 11 Apr 2002, Michael Jakscht wrote:
if [ "$test_variable" <= "10" ] ; then echo "$test_variable" fi
[ ist ein alias (oder so) auf test, und dazu sagt dir 'help [' bzw. 'help test' alles noetige...
Darf man jetzt auf dieser Liste neuerdings kein [ ] mehr verwenden, bloß weil einige hier der Meinung sind, dass test besser wäre? Gruß, Bernhard -- ..Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and the Ugly). -- Matt Welsh
Hallo, On Fri, 12 Apr 2002, Bernhard Walle wrote:
On Fri, 12 Apr 2002 at 09:02 (+0200), David Haller wrote:
On Thu, 11 Apr 2002, Michael Jakscht wrote:
if [ "$test_variable" <= "10" ] ; then echo "$test_variable" fi
[ ist ein alias (oder so) auf test, und dazu sagt dir 'help [' bzw. 'help test' alles noetige...
Darf man jetzt auf dieser Liste neuerdings kein [ ] mehr verwenden, bloß weil einige hier der Meinung sind, dass test besser wäre?
Doch, natuerlich darf man -- wenn man weiss, dass dahinter 'test' steckt (was einem 'help [' auch verraet), und man somit in 'help test' oder 'man test' die Hilfe findet, die man braucht, um herauszufinden, warum o.g. Beispiel nicht klappt. -dnh -- 8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone. --- Eric S. Raymond, "The Cathedral and the Bazaar"
Am Sam, 2002-04-13 um 05.42 schrieb David Haller:
Hallo,
On Fri, 12 Apr 2002, Bernhard Walle wrote:
On Fri, 12 Apr 2002 at 09:02 (+0200), David Haller wrote:
On Thu, 11 Apr 2002, Michael Jakscht wrote:
if [ "$test_variable" <= "10" ] ; then echo "$test_variable" fi
[ ist ein alias (oder so) auf test, und dazu sagt dir 'help [' bzw. 'help test' alles noetige...
Darf man jetzt auf dieser Liste neuerdings kein [ ] mehr verwenden, bloß weil einige hier der Meinung sind, dass test besser wäre?
Doch, natuerlich darf man -- wenn man weiss, dass dahinter 'test' steckt (was einem 'help [' auch verraet), und man somit in 'help test' oder 'man test' die Hilfe findet, die man braucht, um herauszufinden, warum o.g. Beispiel nicht klappt.
<*g*> Zwei Gründe: 1. "<=" 2. Syntaxerror bei leerem "$test_variable" Drum: Nicht help [, sondern man test lesen. <pedantic> Es gibt verschiedene (gute) Gründe "[" nicht zu verwenden: 1. Es gibt (ältere) Systeme, auf denen "[" nicht vorhanden ist, test hingegen schon (Auch bei SuSE ist "[" ein Symlink auf /usr/bin/test - Spielt unter SuSE aber praktisch keine Rolle, da test und "[" Built-ins der meisten (aller?) Shells sind). 2. Es gibt (ältere) Systeme, auf denen "[]" ein "Path-Separator" ist (ähnlich '\' unter DOS, bzw. '/' unter Unix) 3. In grösseren Scripten ist "[ ... ]" nur schwer suchbar (mittels Editorsuchfunktionen, grep, sed u.ä.) 4. Verwechselungsgefahr mit Array-Indizes. Manche Leute gehen soweit, zu empfehlen in Scripten nur /usr/bin/test (mit absolutem Pfad) zu verwenden, da nur so sichergestellt werden kann, dass sich "test|[" in Scripten auch bei unterschiedlichen Shells deterministisch verhält, da es subtile Unterschiede (und Bugs) in den unterschiedlichen "test"-Implementierungen der unterschiedlichen Shells gibt. In autoconf-configure-Scripten kommt noch hinzu, dass autoconf '[]' als m4-Quoting-Zeichen (Als "Anführungszeichen") verwendet. </pedantic> Unter Linux spielt es aber kaum eine Rolle, ob man "test" oder "[" verwendet. Ralf.
Hallo, On Sat, 13 Apr 2002 at 07:18 (+0200), Ralf Corsepius wrote: Wie oft muss dieses Thema eigentlich noch durchgekaut werden? Könnt ihr nicht einfach akzeptieren, dass man [ _auch_ verwenden kann, als gleichberechtigtes Nebeneinander?
1. Es gibt (ältere) Systeme, auf denen "[" nicht vorhanden ist, test hingegen schon (Auch bei SuSE ist "[" ein Symlink auf /usr/bin/test - Spielt unter SuSE aber praktisch keine Rolle, da test und "[" Built-ins der meisten (aller?) Shells sind).
Was heißt 'älter'? Mir ist es ziemlich egal, ob meine Skripten, die wahrscheinlich meine Festplatte nie verlassen werden, auf Systemen von 1985 noch laufen!
2. Es gibt (ältere) Systeme, auf denen "[]" ein "Path-Separator" ist (ähnlich '\' unter DOS, bzw. '/' unter Unix)
Siehe oben. Außerdem: Welche Systeme wären das? Laufen darauf überhaupt Bash-Skripte? Und wieso soll es dadurch Probleme geben?
3. In grösseren Scripten ist "[ ... ]" nur schwer suchbar (mittels Editorsuchfunktionen, grep, sed u.ä.)
Wieso sollte ich nach "test" suchen?
4. Verwechselungsgefahr mit Array-Indizes.
Kann ich nicht nachvollziehen. Dann könnte man das Minuszeichen in einem arithmetischen Ausdruck genauso ablehnen, weil Parameter i. d. R. mit - anfangen, oder ...
Manche Leute gehen soweit, zu empfehlen in Scripten nur /usr/bin/test (mit absolutem Pfad) zu verwenden, da nur so sichergestellt werden kann, dass sich "test|[" in Scripten auch bei unterschiedlichen Shells deterministisch verhält, da es subtile Unterschiede (und Bugs) in den unterschiedlichen "test"-Implementierungen der unterschiedlichen Shells gibt.
Wodurch die Skripte ziemlich unportabel werden. Erstens garantiert mir keiner, dass /usr/bin/test immer zutrifft. Außerdem bin ich mir sicher, dass dieses Programm auch immer gleich ist. Es gibt GNU test und bestimmt bringt jedes Unix sein eigenes test mit substilen Unterschieden mit. Gruß, Bernhard -- Netscape is not a newsreader, and probably never shall be. -- Tom Christiansen
Hi, On Sam, 13 Apr 2002, Bernhard Walle sent incredible lines:
On Sat, 13 Apr 2002 at 07:18 (+0200), Ralf Corsepius wrote:
Wie oft muss dieses Thema eigentlich noch durchgekaut werden? Könnt ihr nicht einfach akzeptieren, dass man [ _auch_ verwenden kann, als gleichberechtigtes Nebeneinander?
man kann es nutzen, es ist aber nicht gleichberechtigt (siehe Mail von Ralf).
1. Es gibt (ältere) Systeme, auf denen "[" nicht vorhanden ist, test hingegen schon (Auch bei SuSE ist "[" ein Symlink auf /usr/bin/test - Spielt unter SuSE aber praktisch keine Rolle, da test und "[" Built-ins der meisten (aller?) Shells sind). Was heißt 'älter'? Mir ist es ziemlich egal, ob meine Skripten, die wahrscheinlich meine Festplatte nie verlassen werden, auf Systemen von 1985 noch laufen!
Das dachte ich auch mal, bis ich das erstemal in einer grossen Firma (niederländischer Elektronik Konzern) an einem bisschen grösseren Unix System rumgebastelt habe und feststellen durfte das fast alle meine Bash Scripte nicht mehr auf der KSH liefen. Ebenfalls problemtatisch wird das ganze dann in Verbindung mit Solaris einfacher sh. Da fängt man dann ganz fix an die portabelsten Konstrukte zu verwenden. Und wer weiss, vielleicht arbeitest du ja auch irgendwann mal bei einem solchen Konzern ;-)). [...]
2. Es gibt (ältere) Systeme, auf denen "[]" ein "Path-Separator" ist (ähnlich '\' unter DOS, bzw. '/' unter Unix) Siehe oben. Außerdem: Welche Systeme wären das? Laufen darauf überhaupt Bash-Skripte? Und wieso soll es dadurch Probleme geben? [...]
Gesehen habe ich das auch schon mal, ich weiss jetzt allerdings nicht mehr auf was für einem System (IIRC war das irgendwas im S/390 Umfeld). Zur Frage mit den Bash Scripten, zu 90% nein, was anderes ist es aber wenn du Shell Scripte schreibst. ... may the Tux be with you! =Thomas= -- Thomas Bendler \\:// ml@bendler-net.de Billwiese 22 (o -) http://www.bendler-net.de/ 21033 Hamburg ---ooO-(_)-Ooo--- tel.: 0 177 - 277 37 61 Germany Linux, enjoy the ride ...!
Am Mon, 15 Apr 2002 schrieb Thomas Bendler:
Hi,
On Sam, 13 Apr 2002, Bernhard Walle sent incredible lines:
On Sat, 13 Apr 2002 at 07:18 (+0200), Ralf Corsepius wrote:
1. Es gibt (ältere) Systeme, auf denen "[" nicht vorhanden ist, test hingegen schon (Auch bei SuSE ist "[" ein Symlink auf /usr/bin/test - Spielt unter SuSE aber praktisch keine Rolle, da test und "[" Built-ins der meisten (aller?) Shells sind). Was heißt 'älter'? Mir ist es ziemlich egal, ob meine Skripten, die wahrscheinlich meine Festplatte nie verlassen werden, auf Systemen von 1985 noch laufen!
Das dachte ich auch mal, bis ich das erstemal in einer grossen Firma (niederländischer Elektronik Konzern) an einem bisschen grösseren Unix System rumgebastelt habe und feststellen durfte das fast alle meine Bash Scripte nicht mehr auf der KSH liefen. Ebenfalls problemtatisch wird das ganze dann in Verbindung mit Solaris einfacher sh. Da fängt man dann ganz fix an die portabelsten Konstrukte zu verwenden. Und wer weiss, vielleicht arbeitest du ja auch irgendwann mal bei einem solchen Konzern ;-)).
Ja, hatte auch gerade diese Tage wieder meine Probleme, als ich jemandem, der mit Solaris arbeitet, schnell ein Skript frickeln sollte.
[...]
2. Es gibt (ältere) Systeme, auf denen "[]" ein "Path-Separator" ist (ähnlich '\' unter DOS, bzw. '/' unter Unix) Siehe oben. Außerdem: Welche Systeme wären das? Laufen darauf überhaupt Bash-Skripte? Und wieso soll es dadurch Probleme geben? [...]
Gesehen habe ich das auch schon mal, ich weiss jetzt allerdings nicht mehr auf was für einem System (IIRC war das irgendwas im S/390 Umfeld). Zur Frage mit den Bash Scripten, zu 90% nein, was anderes ist es aber wenn du Shell Scripte schreibst.
Auf VMS ist [] auch ein Bestandteil das Pfadnamens, Pfade sehen dort so aus LAUFWERK:[VERZEICHNIS.UNTERVERZEICHNIS.UNTERVERZEICHNIS2]DATEINAME Aber dort gibt es keine Unix-Shells, leider... Gruß Christoph -- Christoph Maurer - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
Am Mon, 2002-04-15 um 09.59 schrieb Christoph Maurer:
Am Mon, 15 Apr 2002 schrieb Thomas Bendler:
Hi,
On Sam, 13 Apr 2002, Bernhard Walle sent incredible lines:
On Sat, 13 Apr 2002 at 07:18 (+0200), Ralf Corsepius wrote:
1. Es gibt (ältere) Systeme, auf denen "[" nicht vorhanden ist, test hingegen schon (Auch bei SuSE ist "[" ein Symlink auf /usr/bin/test - Spielt unter SuSE aber praktisch keine Rolle, da test und "[" Built-ins der meisten (aller?) Shells sind). Was heißt 'älter'? Mir ist es ziemlich egal, ob meine Skripten, die wahrscheinlich meine Festplatte nie verlassen werden, auf Systemen von 1985 noch laufen!
Das dachte ich auch mal, bis ich das erstemal in einer grossen Firma (niederländischer Elektronik Konzern) an einem bisschen grösseren Unix System rumgebastelt habe und feststellen durfte das fast alle meine Bash Scripte nicht mehr auf der KSH liefen. Dann warte mal, bis Du auf die zsh-3.0.x (Bei einigen neueren OSen die Standard-Shell) oder die ash (Standard-Shell unter Cygwin) triffst ...
Ebenfalls problemtatisch wird das ganze dann in Verbindung mit Solaris einfacher sh. Da fängt man dann ganz fix an die portabelsten Konstrukte zu verwenden. Und wer weiss, vielleicht arbeitest du ja auch irgendwann mal bei einem solchen Konzern ;-)).
Ja, hatte auch gerade diese Tage wieder meine Probleme, als ich jemandem, der mit Solaris arbeitet, schnell ein Skript frickeln sollte.
:) Nur ist da "test" vs "[" nicht das Problem. Portabilitätsklassiker bez. Solaris vs. bash "test" sind SymLink-Checks (test -L), test -e und test ==. Daneben gibt es noch einige interessante Dinge bez. "||" (oder), "&&" (and) und "-a", "-o" und "!" (not). (vgl in autoconf.info, "Shellology") zu beachten. Bez "[" enthält die SunOS4-Manpage eine deutliche Warnung: [..] WARNING In the second form of the command (that is, the one that uses [], rather than the word test), [..] Some UNIX systems do not recognize the second form of the command. NOTES The test command is built into the Bourne shell, which chooses the 4.2 BSD or the System V version of test, depending on whether /usr/5bin appears before /usr/bin in the shell's PATH variable. This is consistent with the behavior of other commands present in both /usr/bin and /usr/5bin. [..] Die letzte Zeile macht test unter SunOS (und IIRC auch Solaris) erst recht spannend. :) Auch wenn manche jetzt glauben werden, dass SunOS4 keine Rolle mehr spiele - SunOS4 ist deutlich häufiger zu finden als man glaubt.
[...]
2. Es gibt (ältere) Systeme, auf denen "[]" ein "Path-Separator" ist (ähnlich '\' unter DOS, bzw. '/' unter Unix) Siehe oben. Außerdem: Welche Systeme wären das? Laufen darauf überhaupt Bash-Skripte? Und wieso soll es dadurch Probleme geben? [...]
Gesehen habe ich das auch schon mal, ich weiss jetzt allerdings nicht mehr auf was für einem System (IIRC war das irgendwas im S/390 Umfeld). Zur Frage mit den Bash Scripten, zu 90% nein, was anderes ist es aber wenn du Shell Scripte schreibst.
Auf VMS ist [] auch ein Bestandteil das Pfadnamens, Und wie ist das unter OpenVMS? Dort müsste es Unix-artige Shells geben.
Pfade sehen dort so aus LAUFWERK:[VERZEICHNIS.UNTERVERZEICHNIS.UNTERVERZEICHNIS2]DATEINAME Aber dort gibt es keine Unix-Shells, leider...
Ich bilde mir ein, es gab schon vor 10 Jahren (Seither hatte ich keine Kontakt mehr zu VMS) unter VMS eine Art (rudimentäre) /bin/sh, die mit VMS-Pfaden gearbeitet hat. Ausserdem gab zumindest Versuche, die bash auf VMS zu portieren - ob man das weitergetrieben hat, oder ganz aufgegeben hat, weiss ich leider nicht. Ralf
Am Mon, 15 Apr 2002 schrieb Ralf Corsepius:
Am Mon, 2002-04-15 um 09.59 schrieb Christoph Maurer:
Am Mon, 15 Apr 2002 schrieb Thomas Bendler:
On Sam, 13 Apr 2002, Bernhard Walle sent incredible lines:
On Sat, 13 Apr 2002 at 07:18 (+0200), Ralf Corsepius wrote: [test vs.[], Shell-Kompatibilität]
2. Es gibt (ältere) Systeme, auf denen "[]" ein "Path-Separator" ist (ähnlich '\' unter DOS, bzw. '/' unter Unix) Siehe oben. Außerdem: Welche Systeme wären das? Laufen darauf überhaupt Bash-Skripte? Und wieso soll es dadurch Probleme geben? [...]
Gesehen habe ich das auch schon mal, ich weiss jetzt allerdings nicht mehr auf was für einem System (IIRC war das irgendwas im S/390 Umfeld). Zur Frage mit den Bash Scripten, zu 90% nein, was anderes ist es aber wenn du Shell Scripte schreibst.
Auf VMS ist [] auch ein Bestandteil das Pfadnamens, Und wie ist das unter OpenVMS? Dort müsste es Unix-artige Shells geben.
mal schnell ein show system eingegeben ---------------schnipp---------------- [MA.SSH] $ sh sys OpenVMS V7.2 on node GBAXP0 -------------schnapp [MA.SSH] ist der aktuelle Pfadname... Ist also auch unter OpenVMS so...
Pfade sehen dort so aus LAUFWERK:[VERZEICHNIS.UNTERVERZEICHNIS.UNTERVERZEICHNIS2]DATEINAME Aber dort gibt es keine Unix-Shells, leider...
Ich bilde mir ein, es gab schon vor 10 Jahren (Seither hatte ich keine Kontakt mehr zu VMS) unter VMS eine Art (rudimentäre) /bin/sh, die mit VMS-Pfaden gearbeitet hat. Ausserdem gab zumindest Versuche, die bash auf VMS zu portieren - ob man das weitergetrieben hat, oder ganz aufgegeben hat, weiss ich leider nicht.
Vielleicht bin ich dann auch einfach nicht informiert genug, aber hier auf den Kisten bei uns an der Uni gibt es keine Unix-Shells nur diese Dec Command Language. Bin aber auch alles andere als ein VMS-Held und glücklich mit diesem System nur noch alle Schaltjahre arbeiten zu müssen. Gruß Christoph -- Christoph Maurer - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
On Mon, 15 Apr 2002 at 13:12 (+0200), Christoph Maurer wrote:
Am Mon, 15 Apr 2002 schrieb Ralf Corsepius:
Am Mon, 2002-04-15 um 09.59 schrieb Christoph Maurer:
Am Mon, 15 Apr 2002 schrieb Thomas Bendler:
On Sam, 13 Apr 2002, Bernhard Walle sent incredible lines:
On Sat, 13 Apr 2002 at 07:18 (+0200), Ralf Corsepius wrote: [test vs.[], Shell-Kompatibilität]
2. Es gibt (ältere) Systeme, auf denen "[]" ein "Path-Separator" ist (ähnlich '\' unter DOS, bzw. '/' unter Unix) Siehe oben. Außerdem: Welche Systeme wären das? Laufen darauf überhaupt Bash-Skripte? Und wieso soll es dadurch Probleme geben? [...]
Gesehen habe ich das auch schon mal, ich weiss jetzt allerdings nicht mehr auf was für einem System (IIRC war das irgendwas im S/390 Umfeld). Zur Frage mit den Bash Scripten, zu 90% nein, was anderes ist es aber wenn du Shell Scripte schreibst.
Auf VMS ist [] auch ein Bestandteil das Pfadnamens, Und wie ist das unter OpenVMS? Dort müsste es Unix-artige Shells geben.
mal schnell ein show system eingegeben ---------------schnipp---------------- [MA.SSH] $ sh sys OpenVMS V7.2 on node GBAXP0 -------------schnapp
[MA.SSH] ist der aktuelle Pfadname...
Ist also auch unter OpenVMS so... [...]
Schön langsam habt ihr es tatsächlich geschafft, mich zu überzeugen. ;-) Grundsätzlich verwende ich sowieso wenig Bash-Konstrukte, wenn ich weiß, dass es anders auch geht, z. B. `expr $i + 1` statt $(($i + 1)). Gruß, Bernhard -- Die, die ihre Kinder nicht säugen, weil das für die Mutter Tierquälerei wäre. -- Wau Holland
On 15 Apr 2002 at 17:14, Bernhard Walle wrote:
On Mon, 15 Apr 2002 at 13:12 (+0200), Christoph Maurer wrote:
Am Mon, 15 Apr 2002 schrieb Ralf Corsepius:
Am Mon, 2002-04-15 um 09.59 schrieb Christoph Maurer:
Am Mon, 15 Apr 2002 schrieb Thomas Bendler:
On Sam, 13 Apr 2002, Bernhard Walle sent incredible lines:
On Sat, 13 Apr 2002 at 07:18 (+0200), Ralf Corsepius wrote: [test vs.[], Shell-Kompatibilität] [...] Schön langsam habt ihr es tatsächlich geschafft, mich zu überzeugen. ;-)
Grundsätzlich verwende ich sowieso wenig Bash-Konstrukte, wenn ich weiß, dass es anders auch geht, z. B. `expr $i + 1` statt $(($i + 1)).
Wobei auch hier (nur der Vollständigkeit halber) anzumerken ist, das das mitnichten eine Bash Spezialität ist. Auch die ksh kann mit diesen Ausdrücken umgehen. Andreas PS: Ausserdem reicht bei mathematischen Ausdrücken die Variable, das '$' kann dann weggelassen werden. Also: $((i + 1)) reicht aus (sowohl in bash als auch in ksh!)
* Andreas Kyek schrieb am 16.Apr.2002:
On 15 Apr 2002 at 17:14, Bernhard Walle wrote:
Grundsätzlich verwende ich sowieso wenig Bash-Konstrukte, wenn ich weiß, dass es anders auch geht, z. B. `expr $i + 1` statt $(($i + 1)).
Wobei auch hier (nur der Vollständigkeit halber) anzumerken ist, das das mitnichten eine Bash Spezialität ist. Auch die ksh kann mit diesen Ausdrücken umgehen.
PS: Ausserdem reicht bei mathematischen Ausdrücken die Variable, das '$' kann dann weggelassen werden. Also: $((i + 1)) reicht aus (sowohl in bash als auch in ksh!)
Und bc ist so wie so besser als expr und bashinterner Rechner. 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 16 Apr 2002 at 10:21, Bernd Brodesser wrote:
* Andreas Kyek schrieb am 16.Apr.2002:
On 15 Apr 2002 at 17:14, Bernhard Walle wrote: [...] PS: Ausserdem reicht bei mathematischen Ausdrücken die Variable, das '$' kann dann weggelassen werden. Also: $((i + 1)) reicht aus (sowohl in bash als auch in ksh!)
Und bc ist so wie so besser als expr und bashinterner Rechner.
Yepp, aber nu' driften wir ab, oder? Andreas (Mein Windows ist besser als deins! Was, du hast gar keine Windows?. Kann tu meins haben)
Hi, On Fre, 12 Apr 2002, Bernhard Walle sent incredible lines:
On Fri, 12 Apr 2002 at 09:02 (+0200), David Haller wrote:
On Thu, 11 Apr 2002, Michael Jakscht wrote:
if [ "$test_variable" <= "10" ] ; then echo "$test_variable" fi [ ist ein alias (oder so) auf test, und dazu sagt dir 'help [' bzw. 'help test' alles noetige... Darf man jetzt auf dieser Liste neuerdings kein [ ] mehr verwenden, bloß weil einige hier der Meinung sind, dass test besser wäre?
naja, test ist besser da es verglichen mit [] portabler ist und auf mehr Unixen funktioniert. Das ist (IMHO) schon ein Vorteil und es kann nicht schaden wenn man diesen Umstand anmerkt. ... may the Tux be with you! =Thomas= -- Thomas Bendler \\:// ml@bendler-net.de Billwiese 22 (o -) http://www.bendler-net.de/ 21033 Hamburg ---ooO-(_)-Ooo--- tel.: 0 177 - 277 37 61 Germany Linux, enjoy the ride ...!
Michael Jakscht wrote:
Hi,
Peter Schneewind [mailto:peter@schneewind.net] schrieb am Thursday, April 11, 2002 3:29 PM:
On Thu, Apr 11, 2002 at 02:54:16PM +0200, Michael Jakscht wrote:
server:~ # tail /var/log/allmessages | awk '{ print $2 }'
Z. B. mit Backticks:
,---- | #!/bin/sh | VAR=`tail /var/log/allmessages | awk '{ print $2 }'` | echo $VAR `----
Sehr gut, danke danke, es funktioniert jetzt. Nur eine Frage habe ich noch: Wie kann ich erreichen, dass ich das 1. und das 2. Feld auslese? Klar, mit awk '{ print $1 $2 }', kein Thema. Da fehlt mir dann aber ein space zwischen den beiden Zeilen. Wie kann ich den dazwischenschieben?
tail /var/log/allmessages | awk '{ print $1, " ", $2}' Daniel
participants (16)
-
Alexander Sommer -
Andreas Kyek -
B.Brodesser＠t-online.de -
Bernhard Walle -
Bertram Scharpf -
Christoph Maurer -
D.Wolpert -
David Haller -
Konrad Neitzel -
Michael Jakscht -
Peter Schneewind -
Philipp Thomas -
Ralf Corsepius -
Stephan Hakuli -
Thomas Bendler -
Thorsten Haude