expertenaustausch > comp.os.* > comp.os.unix.shell

Jan Novak (09.10.2018, 10:48)
Hallo,

ich suche nach einer Lösung, warum ein grep über das Syslog in der bash
590 Zeilen findet, aber in einem bash script alles in eine Zeile wirft.
Ein
IFS=$'\n'
schafft keine Abhilfe.
Erschwerend kommt hinzu, dass es sich um ein Ubuntu 10.04 (!) mit Kernel
2.6.32-21-generic-pae handelt, welches nicht upgedatet werden kann.

Jan

p.s. Ich bin mir der Problematik mit einer so alten BS Version durchaus
bewusst, jedoch liegt es nicht in meinem Arbeitsbereich, daran etwas
ändern zu können. Der Server steht auch nicht direkt im Internet.
Helmut Waitzmann (09.10.2018, 18:48)
Jan Novak <repcom>:

>ich suche nach einer Lösung, warum ein grep über das Syslog in der
>bash 590 Zeilen findet, aber in einem bash script alles in eine Zeile
>wirft.
>Ein
> IFS=$'\n'
>schafft keine Abhilfe.


Die Shell?Variable IFS wird nur von den Shells verwendet. »grep«
macht sich nichts daraus.

Könntest Du das Shell?Skript zeigen?

Auch wäre es wäre interessant, zu sehen, was heraus kommt, wenn Du
das Syslog durch das Kommando

od -N 160 -t cx1 -w10

schiebst.

So, ganz ohne Anhaltspunkte, ist Diagnose und Medikation
schwierig.

>Erschwerend kommt hinzu, dass es sich um ein Ubuntu 10.04 (!) mit
>Kernel 2.6.32-21-generic-pae handelt


Ich nehme an, dass das nicht die Ursache ist.
Ralf Damaschke (10.10.2018, 03:08)
Jan Novak schrieb:

> ich suche nach einer Lösung, warum ein grep über das Syslog in der bash
> 590 Zeilen findet, aber in einem bash script alles in eine Zeile wirft.


Nur der Vollständigkeit halber:
Du schreibst nicht das Ergebnis in eine Variable und gibst diese dann
ohne Doppel-Anführungszeichen aus?
Jan Novak (10.10.2018, 07:56)
Am 09.10.18 um 18:48 schrieb Helmut Waitzmann:
> Jan Novak <repcom>:
> Die Shell?Variable IFS wird nur von den Shells verwendet. »grep«
> macht sich nichts daraus.
> Könntest Du das Shell?Skript zeigen?
> Auch wäre es wäre interessant, zu sehen, was heraus kommt, wenn Du
> das Syslog durch das Kommando
> od -N 160 -t cx1 -w10
> schiebst.


Hier mein Script:

#!/bin/bash
SYSLOG="/arc/syslog"
out=$(grep "PdfColorAnalyser.py" $SYSLOG)
# das gibt mir die korrekte Anzahl der Zeilen wieder
echo "$out"|wc -l

# hier kommt alles in einer Zeile
for z in "$out"; do
echo e "$z"
done

hier der Dump:
# od -N 160 -t cx1 -w10 ./syslog
0000000 O c t 5 0 6 :
4f 63 74 20 20 35 20 30 36 3a
0000012 3 9 : 4 0 b e u t
33 39 3a 34 30 20 62 65 75 74
0000024 h B e u t h A M S
68 20 42 65 75 74 68 41 4d 53
0000036 : l a s t m e s
3a 20 6c 61 73 74 20 6d 65 73
0000050 s a g e r e p e a
73 61 67 65 20 72 65 70 65 61
0000062 t e d 1 6 t i m
74 65 64 20 31 36 20 74 69 6d
0000074 e s \n O c t 5
65 73 0a 4f 63 74 20 20 35 20
0000106 0 6 : 3 9 : 4 0 b
30 36 3a 33 39 3a 34 30 20 62
0000120 e u t h r s y s l
65 75 74 68 20 72 73 79 73 6c
0000132 o g d : [ o r i g
6f 67 64 3a 20 5b 6f 72 69 67
0000144 i n s o f t w a r
69 6e 20 73 6f 66 74 77 61 72
0000156 e = " r s y s l o g
65 3d 22 72 73 79 73 6c 6f 67
0000170 d " s w V e r s i
64 22 20 73 77 56 65 72 73 69
0000202 o n = " 4 . 2 . 0 "
6f 6e 3d 22 34 2e 32 2e 30 22
0000214 x - p i d = " 8 4
20 78 2d 70 69 64 3d 22 38 34
0000226 3 " x - i n f o =
33 22 20 78 2d 69 6e 66 6f 3d
0000240

Jan
Jan Novak (10.10.2018, 07:57)
Am 10.10.18 um 03:08 schrieb Ralf Damaschke:
> Jan Novak schrieb:
>> ich suche nach einer Lösung, warum ein grep über das Syslog in der bash
>> 590 Zeilen findet, aber in einem bash script alles in eine Zeile wirft.

> Nur der Vollständigkeit halber:
> Du schreibst nicht das Ergebnis in eine Variable und gibst diese dann
> ohne Doppel-Anführungszeichen aus?


Habe ich gemacht (siehe voriger Post mit dem Beispiel Script).

Jan
Helmut Waitzmann (10.10.2018, 14:06)
Jan Novak <repcom>:

>Hier mein Script:
>#!/bin/bash
>SYSLOG="/arc/syslog"
>out=$(grep "PdfColorAnalyser.py" $SYSLOG)
># das gibt mir die korrekte Anzahl der Zeilen wieder
>echo "$out"|wc -l


Das vorstehende Kommando gibt nur zufällig ? abhängig vom Inhalt
des Syslogs ? die korrekte Anzahl der Zeilen wieder.

># hier kommt alles in einer Zeile
>for z in "$out"; do
> echo e "$z"
>done


Der Schleifenrumpf und damit »echo« wird nur ein einziges Mal
aufgerufen, weil in der Schleife zwischen dem Schlüsselwort »in«
und dem Schlüsselwort »do« nur ein einziges Wort, nämlich der Wert
des Shell?Ausdrucks »"$out"«, steht.

In Deinem Skript sehe ich jetzt nichts, wo ich auf den ersten
Blick sagen würde: Da ist die Ursache. Generell aber hat das
Skript ein paar Schwächen, die ich (vorbeugend) abstellen würde,
um mir nicht überlegen zu müssen, ob sie in diesem speziellen Fall
vielleicht zuschlagen oder nicht. Deswegen hier der Vorschlag
einer geänderten Fassung:

#!/bin/bash
SYSLOG='/arc/syslog'
out="$(
grep -F -e 'PdfColorAnalyser.py' -- "$SYSLOG"
exitstatus="$?"
echo .
exit "$exitstatus"
)"
out="${out%.}"
# das gibt mir die korrekte Anzahl der Zeilen wieder
printf '%s'|wc -l
for z in "$out"
do
printf '%s' "e $z"
done

Bemerkungen zu den Änderungen im Skript:

Beim Quoting mit »"« gibt es einige Einschränkungen, die Du meiner
Vermutung nach nicht beabsichtigt hattest. Deshalb habe ich es an
gewissen Stellen durch Quoting mit »'« ersetzt.

Variablenauswertungen (»$variable«) erfahren, wenn sie nicht in
»"« stehen, eine Sonderbehandlung, die Du sicher hicht
beabsichtigt hattest. Deshalb habe ich sie durch »"$variable"«
ersetzt.

»grep« versteht den ersten Parameter nicht als Suchmuster, wenn er
mit einem »-« beginnt. Das ist in Deinem Beispiel zwar nicht der
Fall, geht aber gerne vergessen, wenn man es nicht stets im
Hinterkopf behält. Im Gegensatz dazu hat »grep -e Suchmuster«
diese Einschränkung nicht.

»-F« bei »grep« bedeutet, dass das Suchmuster kein regulärer
Ausdruck ist sondern wörtlich gesucht wird.

»echo« hat einige Besonderheiten, je nachdem, wie die
auszugebenden Wörter aussehen. Diese Besonderheiten sind nicht
einmal in allen Unixen gleich. Deswegen ist es schwierig, bei
»echo« ein vollständig bestimmtes Verhalten im POSIX?Standard
festzuklopfen. »printf« wurde zu dem Zweck geschaffen, »echo«
mitsamt seinen Besonderheiten in den Ruhestand schicken zu können.

Hier übergibst Du »echo« einen Parameter, der nicht von vorne
herein bekannt ist. Es kann demnach nicht ausgeschlossen werden,
dass Besonderheiten von »echo« zum Tragen kommen und die Ausgabe
verfälschen.

Das Shell?Konstrukt »"$( ein Kommando )"« wirft von den Daten, die
»ein Kommando« ausgibt, alle am Ende der Ausgabe sich befindenden
Zeilenvorschübe (Linefeeds) weg (so ist das Verhalten von
»"$(...)"« festgelegt), also alle Leerzeilen am Ende der Ausgabe
und auch noch den Zeilenvorschub am Ende der letzten nicht?leeren
Zeile.

Deswegen stelle ich mit dem Hinzufügen des Kommandos

»echo .«

sicher, dass die Ausgabe nicht mit einer leeren Zeile sondern
einer, die nur einen Punkt enthält, endet. Dadurch wird nur der
Zeilenvorschub dieser angefügten Zeile weggeworfen. Weil ich den
Punkt aber schließlich nicht an der Ausgabe haben möchte, entferne
ich ihn noch mit dem nachfolgenden Kommando

»out="${out%.}"«.

Das Kommando »echo .« ist von den oben angedeuteten
»echo«?Besonderheiten nicht betroffen. (Wenn Du möchtest, kannst
Du aber statt dessen auch »printf '%s\n' .« schreiben.)

Das Shell?Konstrukt »$(...)« liefert als Exitstatus den des
letzten darin ausgeführten Kommandos, im originalen Shell?Skript
also den des »grep«?Kommandos. Weil der »grep«?Exitstatus durch
das hinzugefügte »echo .« aber vergessen wird, speichere ichihn
zuerst in der Variablen »exitstatus« und stelle ihn als Letztes
mit dem Kommando

»exit "$exitstatus"«

wieder her.

Vermute ich richtig, dass Du in der Schleife jede Zeile mit einem
vorangestellten »e «, ansonsten aber unverändert ausgeben
möchtest?

Dann würde ich Dir statt der Schleife einfach »sed« empfehlen:

grep -F -e 'PdfColorAnalyser.py' -- "$SYSLOG" |
sed -e 's/^/e /'

Wenn man »PdfColorAnalyser.py« händisch in einen passenden
regulären Ausdruck umsetzt (beachte den »\« vor dem Punkt!),kann
man die Aufgabe des »grep«?Aufrufs auch gleich von »sed«
miterledigen lassen. Dann schmilzt das ganze Shell?Skript auf
eine Zeile zusammen:

sed -n -e '/PdfColorAnalyser\.py/s/^/e /p' -- "$SYSLOG"

Es stellt vor jede Zeile aus dem »"$SYSLOG"«, in der der Text
»PdfColorAnalyser.py« vorkommt, den Text »e « und gibt sie aus.
Alle anderen Zeilen werden nicht ausgegeben.

Oder ist die Ausgabe mit vorangestelltem »e « nur eine
Demonstration, und Du möchtest eigentlich etwas anderes mit jeder
Zeile anstellen?

[..]
>0000062 t e d 1 6 t i m
> 74 65 64 20 31 36 20 74 69 6d
>0000074 e s \n O c t 5


[?]

Da kann ich nichts Außergewöhnliches erkennen, insbesondere sind
ganz normale Linefeed?Zeichen drin. Das syslog scheint nicht die
Ursache zu sein.
Helmut Waitzmann (10.10.2018, 14:11)
Jan Novak <repcom>:

>Hier mein Script:
>#!/bin/bash
>SYSLOG="/arc/syslog"
>out=$(grep "PdfColorAnalyser.py" $SYSLOG)
># das gibt mir die korrekte Anzahl der Zeilen wieder
>echo "$out"|wc -l


Das vorstehende Kommando gibt nur zufällig ? abhängig vom Inhalt
des Syslogs ? die korrekte Anzahl der Zeilen wieder.

># hier kommt alles in einer Zeile
>for z in "$out"; do
> echo e "$z"
>done


Der Schleifenrumpf und damit »echo« wird nur ein einziges Mal
aufgerufen, weil in der Schleife zwischen dem Schlüsselwort »in«
und dem Schlüsselwort »do« nur ein einziges Wort, nämlich der Wert
des Shell?Ausdrucks »"$out"«, steht.

In Deinem Skript sehe ich jetzt nichts, wo ich auf den ersten
Blick sagen würde: Da ist die Ursache. Generell aber hat das
Skript ein paar Schwächen, die ich (vorbeugend) abstellen würde,
um mir nicht überlegen zu müssen, ob sie in diesem speziellen Fall
vielleicht zuschlagen oder nicht. Deswegen hier der Vorschlag
einer geänderten Fassung:

#!/bin/bash
SYSLOG='/arc/syslog'
out="$(
grep -F -e 'PdfColorAnalyser.py' -- "$SYSLOG"
exitstatus="$?"
echo .
exit "$exitstatus"
)"
out="${out%.}"
# das gibt mir die korrekte Anzahl der Zeilen wieder
printf '%s'|wc -l
for z in "$out"
do
printf '%s' "e $z"
done

Bemerkungen zu den Änderungen im Skript:

Beim Quoting mit »"« gibt es einige Einschränkungen, die Du meiner
Vermutung nach nicht beabsichtigt hattest. Deshalb habe ich es an
gewissen Stellen durch Quoting mit »'« ersetzt.

Variablenauswertungen (»$variable«) erfahren, wenn sie nicht in
»"« stehen, eine Sonderbehandlung, die Du sicher hicht
beabsichtigt hattest. Deshalb habe ich sie durch »"$variable"«
ersetzt.

»grep« versteht den ersten Parameter nicht als Suchmuster, wenn er
mit einem »-« beginnt. Das ist in Deinem Beispiel zwar nicht der
Fall, geht aber gerne vergessen, wenn man es nicht stets im
Hinterkopf behält. Im Gegensatz dazu hat »grep -e Suchmuster«
diese Einschränkung nicht.

»-F« bei »grep« bedeutet, dass das Suchmuster kein regulärer
Ausdruck ist sondern wörtlich gesucht wird.

»echo« hat einige Besonderheiten, je nachdem, wie die
auszugebenden Wörter aussehen. Diese Besonderheiten sind nicht
einmal in allen Unixen gleich. Deswegen ist es schwierig, bei
»echo« ein vollständig bestimmtes Verhalten im POSIX?Standard
festzuklopfen. »printf« wurde zu dem Zweck geschaffen, »echo«
mitsamt seinen Besonderheiten in den Ruhestand schicken zu können.

Hier übergibst Du »echo« einen Parameter, der nicht von vorne
herein bekannt ist. Es kann demnach nicht ausgeschlossen werden,
dass Besonderheiten von »echo« zum Tragen kommen und die Ausgabe
verfälschen.

Das Shell?Konstrukt »"$( ein Kommando )"« wirft von den Daten, die
»ein Kommando« ausgibt, alle am Ende der Ausgabe sich befindenden
Zeilenvorschübe (Linefeeds) weg (so ist das Verhalten von
»"$(...)"« festgelegt), also alle Leerzeilen am Ende der Ausgabe
und auch noch den Zeilenvorschub am Ende der letzten nicht?leeren
Zeile.

Deswegen stelle ich mit dem Hinzufügen des Kommandos

»echo .«

sicher, dass die Ausgabe nicht mit einer leeren Zeile sondern
einer, die nur einen Punkt enthält, endet. Dadurch wird nur der
Zeilenvorschub dieser angefügten Zeile weggeworfen. Weil ich den
Punkt aber schließlich nicht an der Ausgabe haben möchte, entferne
ich ihn noch mit dem nachfolgenden Kommando

»out="${out%.}"«.

Das Kommando »echo .« ist von den oben angedeuteten
»echo«?Besonderheiten nicht betroffen. (Wenn Du möchtest, kannst
Du aber statt dessen auch »printf '%s\n' .« schreiben.)

Das Shell?Konstrukt »$(...)« liefert als Exitstatus den des
letzten darin ausgeführten Kommandos, im originalen Shell?Skript
also den des »grep«?Kommandos. Weil der »grep«?Exitstatus durch
das hinzugefügte »echo .« aber vergessen wird, speichere ichihn
zuerst in der Variablen »exitstatus« und stelle ihn als Letztes
mit dem Kommando

»exit "$exitstatus"«

wieder her.

Vermute ich richtig, dass Du in der Schleife jede Zeile mit einem
vorangestellten »e «, ansonsten aber unverändert ausgeben
möchtest?

Dann würde ich Dir statt der Schleife einfach »sed« empfehlen:

grep -F -e 'PdfColorAnalyser.py' -- '/arc/syslog' |
sed -e 's/^/e /'

Wenn man »PdfColorAnalyser.py« (händisch) in einen passenden
regulären Ausdruck umsetzt (beachte den »\« vor dem Punkt!),kann
man die Aufgabe des »grep«?Aufrufs auch gleich von »sed«
miterledigen lassen. Dann schmilzt das ganze Shell?Skript auf
eine Zeile zusammen:

sed -n -e '/PdfColorAnalyser\.py/s/^/e /p' -- '/arc/syslog'

Es stellt vor jede Zeile aus »/arc/syslog«, in der der Text
»PdfColorAnalyser.py« vorkommt, den Text »e « und gibt sie aus.
Alle anderen Zeilen werden nicht ausgegeben.

Oder ist die Ausgabe mit vorangestelltem »e « nur eine
Demonstration, und Du möchtest eigentlich etwas anderes mit jeder
Zeile anstellen?

[..]
> 74 65 64 20 31 36 20 74 69 6d
>0000074 e s \n O c t 5
> 65 73 0a 4f 63 74 20 20 35 20


[?]

Da kann ich nichts Außergewöhnliches erkennen, insbesondere sind
ganz normale Linefeed?Zeichen drin. Das syslog scheint nicht die
Ursache zu sein.
Helmut Waitzmann (10.10.2018, 18:08)
Jan Novak <repcom>:

>Hier mein Script:
>#!/bin/bash
>SYSLOG="/arc/syslog"
>out=$(grep "PdfColorAnalyser.py" $SYSLOG)
># das gibt mir die korrekte Anzahl der Zeilen wieder
>echo "$out"|wc -l


Das vorstehende Kommando gibt nur zufällig ? abhängig vom Inhalt
des Syslogs ? die korrekte Anzahl der Zeilen wieder.

># hier kommt alles in einer Zeile
>for z in "$out"; do
> echo e "$z"
>done


Der Schleifenrumpf und damit »echo« wird nur ein einziges Mal
aufgerufen, weil in der Schleife zwischen dem Schlüsselwort »in«
und dem Schlüsselwort »do« nur ein einziges Wort, nämlich der Wert
des Shell?Ausdrucks »"$out"«, steht.

In Deinem Skript sehe ich jetzt nichts, wo ich auf den ersten
Blick sagen würde: Da ist die Ursache. Generell aber hat das
Skript ein paar Schwächen, die ich (vorbeugend) abstellen würde,
um mir nicht überlegen zu müssen, ob sie in diesem speziellen Fall
vielleicht zuschlagen oder nicht. Deswegen hier der Vorschlag
einer geänderten Fassung:

#!/bin/bash
SYSLOG='/arc/syslog'
out="$(
grep -F -e 'PdfColorAnalyser.py' -- "$SYSLOG"
exitstatus="$?"
echo .
exit "$exitstatus"
)"
out="${out%.}"
# das gibt mir die korrekte Anzahl der Zeilen wieder
printf '%s' "$out" |wc -l
for z in "$out"
do
printf '%s' "e $z"
done

Bemerkungen zu den Änderungen im Skript:

Beim Quoting mit »"« gibt es einige Einschränkungen, die Du meiner
Vermutung nach nicht beabsichtigt hattest. Deshalb habe ich es an
gewissen Stellen durch Quoting mit »'« ersetzt.

Variablenauswertungen (»$variable«) erfahren, wenn sie nicht in
»"« stehen, eine Sonderbehandlung, die Du sicher hicht
beabsichtigt hattest. Deshalb habe ich sie durch »"$variable"«
ersetzt.

»grep« versteht den ersten Parameter nicht als Suchmuster, wenn er
mit einem »-« beginnt. Das ist in Deinem Beispiel zwar nicht der
Fall, geht aber gerne vergessen, wenn man es nicht stets im
Hinterkopf behält. Im Gegensatz dazu hat »grep -e Suchmuster«
diese Einschränkung nicht.

»-F« bei »grep« bedeutet, dass das Suchmuster kein regulärer
Ausdruck ist sondern wörtlich gesucht wird.

»echo« hat einige Besonderheiten, je nachdem, wie die
auszugebenden Wörter aussehen. Diese Besonderheiten sind nicht
einmal in allen Unixen gleich. Deswegen ist es schwierig, bei
»echo« ein vollständig bestimmtes Verhalten im POSIX?Standard
festzuklopfen. »printf« wurde zu dem Zweck geschaffen, »echo«
mitsamt seinen Besonderheiten in den Ruhestand schicken zu können.

Hier übergibst Du »echo« einen Parameter, der nicht von vorne
herein bekannt ist. Es kann demnach nicht ausgeschlossen werden,
dass Besonderheiten von »echo« zum Tragen kommen und die Ausgabe
verfälschen.

Das Shell?Konstrukt »"$( ein Kommando )"« wirft von den Daten, die
»ein Kommando« ausgibt, alle am Ende der Ausgabe sich befindenden
Zeilenvorschübe (Linefeeds) weg (so ist das Verhalten von
»"$(...)"« festgelegt), also alle Leerzeilen am Ende der Ausgabe
und auch noch den Zeilenvorschub am Ende der letzten nicht?leeren
Zeile.

Deswegen stelle ich mit dem Hinzufügen des Kommandos

»echo .«

sicher, dass die Ausgabe nicht mit einer leeren Zeile sondern
einer, die nur einen Punkt enthält, endet. Dadurch wird nur der
Zeilenvorschub dieser angefügten Zeile weggeworfen. Weil ich den
Punkt aber schließlich nicht an der Ausgabe haben möchte, entferne
ich ihn noch mit dem nachfolgenden Kommando

»out="${out%.}"«.

Das Kommando »echo .« ist von den oben angedeuteten
»echo«?Besonderheiten nicht betroffen. (Wenn Du möchtest, kannst
Du aber statt dessen auch »printf '%s\n' .« schreiben.)

Das Shell?Konstrukt »$(...)« liefert als Exitstatus den des
letzten darin ausgeführten Kommandos, im originalen Shell?Skript
also den des »grep«?Kommandos. Weil der »grep«?Exitstatus durch
das hinzugefügte »echo .« aber vergessen wird, speichere ichihn
zuerst in der Variablen »exitstatus« und stelle ihn als Letztes
mit dem Kommando

»exit "$exitstatus"«

wieder her.

Vermute ich richtig, dass Du in der Schleife jede Zeile mit einem
vorangestellten »e «, ansonsten aber unverändert ausgeben
möchtest?

Dann würde ich Dir statt der Schleife einfach »sed« empfehlen:

grep -F -e 'PdfColorAnalyser.py' -- '/arc/syslog' |
sed -e 's/^/e /'

Wenn man »PdfColorAnalyser.py« (händisch) in einen passenden
regulären Ausdruck umsetzt (beachte den »\« vor dem Punkt!),kann
man die Aufgabe des »grep«?Aufrufs auch gleich von »sed«
miterledigen lassen. Dann schmilzt das ganze Shell?Skript auf
eine Zeile zusammen:

sed -n -e '/PdfColorAnalyser\.py/s/^/e /p' -- '/arc/syslog'

Es stellt vor jede Zeile aus »/arc/syslog«, in der der Text
»PdfColorAnalyser.py« vorkommt, den Text »e « und gibt sie aus.
Alle anderen Zeilen werden nicht ausgegeben.

Oder ist die Ausgabe mit vorangestelltem »e « nur eine
Demonstration, und Du möchtest eigentlich etwas anderes mit jeder
Zeile anstellen?

[..]
> 74 65 64 20 31 36 20 74 69 6d
>0000074 e s \n O c t 5
> 65 73 0a 4f 63 74 20 20 35 20


[?]

Da kann ich nichts Außergewöhnliches erkennen, insbesondere sind
ganz normale Linefeed?Zeichen drin. Das syslog scheint nicht die
Ursache zu sein.
Jan Novak (11.10.2018, 07:25)
Am 10.10.18 um 18:08 schrieb Helmut Waitzmann:
....
[..]
> printf '%s' "e $z"
> done
> Bemerkungen zu den Änderungen im Skript:


....

Danke für die ausführliche Erklärung!

[..]
> miterledigen lassen. Dann schmilzt das ganze Shell?Skript auf
> eine Zeile zusammen:
> sed -n -e '/PdfColorAnalyser\.py/s/^/e /p' -- '/arc/syslog'


Das macht es natürlich noch einfacher...

> Es stellt vor jede Zeile aus »/arc/syslog«, in der der Text
> »PdfColorAnalyser.py« vorkommt, den Text »e « und gibt sie aus.
> Alle anderen Zeilen werden nicht ausgegeben.
> Oder ist die Ausgabe mit vorangestelltem »e « nur eine
> Demonstration, und Du möchtest eigentlich etwas anderes mit jeder
> Zeile anstellen?


Korekt. Das war nur ein Test, welchen ich so auch gar nicht hier posten
wollte.
Ich versuche jetzt mal, das sed Kommando zu nutzen.

Vielen Dank für deine Ausführungen.

Jan
Joerg.Schilling (11.10.2018, 12:25)
In article <87tvlvawvw.fsf>,
Helmut Waitzmann <oe.throttle> wrote:

> od -N 160 -t cx1 -w10


Ich hoffem Dir ist klar, daß dies auf UNIX nicht funktioniert:

Die Closed Source Implementierung von Sun/IBM/HP:

od -N 160 -t cx1 -w10
usage: od [-bcCdDfFoOsSvxX] [-] [file] [offset_string]
od [-bcCdDfFoOsSvxX] [-t type_string]... [-A address_base] [-j skip] [-N count] [-] [file...]

Meine auf OpenSolaris genutzte OSS Reimplementierung:

/opt/schily/bin/od -N 160 -t cx1 -w10
Bad flag: '-w10'.
Usage: od [options] [file] [[+]starting address[.][b|B]]
Usage: od [options] [-t type]... [-A base] [-j skip] [-N count] [file...]
Options:
-A c Set address base c ('d', 'o', 'n' or 'x')
-j skip Skip input for the files
-N n Only process n bytes
-t type Specify output format type
-a Display content also in characters
-b Display content in bytes
-c Display content as single byte quoted characters
-C Display content as single or multi byte quoted characters
-d Display content in decimal -tu2
-D Display content in decimal -tu4
-f Display content as floats
-F Display content as doubles
-o Display content in octal -to2
-O Display content in octal -to4
-s Display content in decimal -td2
-S Display content in decimal -td4
-v Show all data even if it is identical
-x Display content in hexadecimal -tx2
-X Display content in hexadecimal -tx4
-help Print this help.
-version Print version number.
'b' after starting address multiplies with 512
Jan Novak (11.10.2018, 14:53)
Am 11.10.18 um 12:25 schrieb Joerg.Schilling:
> In article <87tvlvawvw.fsf>,
> Helmut Waitzmann <oe.throttle> wrote:
>> od -N 160 -t cx1 -w10

> Ich hoffem Dir ist klar, daß dies auf UNIX nicht funktioniert:


Aber davon war auch nie die Rede.
In meinem ursprünglichen Post habe ich das Betriebssystem benannt ...
Somit "braucht" es auch unter Unix gar nicht zu funktionieren ;-)

Jan
Helmut Waitzmann (11.10.2018, 15:06)
Joerg.Schilling:
>In article <87tvlvawvw.fsf>,
>Helmut Waitzmann <oe.throttle> wrote:
>> od -N 160 -t cx1 -w10

>Ich hoffem Dir ist klar, daß dies auf UNIX nicht funktioniert:


Ja. Und ich habe folgende Überlegung angestellt:

* Alle Optionen dieses Kommandos außer »-w10« sind vom
POSIX?Standard abgesegnet.

* »-w10« ermöglicht es Jan, die Ausgabe des Kommandos direktins
Usenet zu stellen, ohne, dass Zitate der Ausgabe gleich zu zu
langen Zeilen führen.

* Das Kommando ist nicht Teil der Lösung des Problems sondern
nur Teil des Über?die?Schulter?Schauens.

* Jan verwendet ein Ubuntu?Linux 10. Zu jener Zeit kannte meiner
Erinnerung nach selbst das Debian?»od« diese Option. Dadarf ich
davon ausgehen, dass sein »od« die Option »-w10« ebenfalls
versteht.

* Im POSIX?Standard konnte ich keine Aussage dazu finden, wie man
die Zeilenlänge sonst (etwa über die Umgebungsvariable
»COLUMNS«) einstellen könnte.
Joerg.Schilling (11.10.2018, 15:44)
In article <87lg74zl6v.fsf>,
Helmut Waitzmann <oe.throttle> wrote:

>* »-w10« ermöglicht es Jan, die Ausgabe des Kommandos direkt ins
> Usenet zu stellen, ohne, dass Zitate der Ausgabe gleich zu zu
> langen Zeilen führen.


Also ein Standardkonformes od(1) w?rde hier 71 Zeichen Pro Zeile erzeugen, da
sind noch 8 Zeichen Reserve....
Helmut Waitzmann (12.10.2018, 01:04)
Joerg.Schilling:
>In article <87lg74zl6v.fsf>,
>Helmut Waitzmann <oe.throttle> wrote:


>Also ein Standardkonformes od(1) würde hier 71 Zeichen Pro Zeile
>erzeugen, da sind noch 8 Zeichen Reserve....


Ich habe jetzt nicht nochmal nachgesehen, aber ich meine mich zu
erinnern, nirgends eine Angabe über die Länge der Zeilen gefunden
zu haben. Außerdem waren mir 71 Zeichen pro Zeile für Zeilen, die
man nachträglich nur mit größter Mühe neu umbrechen kann, für
einen Usenet?Beitrag etwas zu wenig Reserve. Darüber hinaus
wollte ich eine im Dezimalsystem runde Zahl von verarbeiteten
Zeichen pro Zeile.
Ähnliche Themen