Hallo liste, habe folgendes Problem. Habe eine Textdatei in der gewisse Zeichen durhc eine zeichenkette ersetzt werden sollen. Die neue Zeichenkette soll aber nicht interpretiert werden sondern genau so eingetragen werden. Beispiel: Im Text "Rückmeldung" soll das ü durch "\201" ersetzt werden. Das sieht ann so aus: "R\201ckmeldung also das \201 soll nicht als oktales Ascii zeichen interpretiert werden. Hat da jemand eine Löung, wie ich das am einfachsten in einer Textdatei hin bekomme? es sollen natürlich alle vorkommen ersetzt werden und die Datei dann wieder abgespeichert werden. Gruss und Danke Günter -------------------------------------------- PS Automation GmbH Gesellschaft für Antriebtechnik Philip-Krämer-Ring 13 67098 Bad Dürkheim Tel.: 06322/6003-0 Fax.: 06322/6003-20
hi, vielleicht so etwas ? vorsicht für linebreaks hnz ------------------------------------ #!/bin/sh # replace $1 with $2 in $* # usage: replace "old-pattern" "new-pattern" file [file...] OLD=$1 # first parameter of the script NEW=$2 # second parameter shift ; shift # discard the first 2 parameters: the next are the file names for file in $* # for all files given as parameters do # replace every occurrence of OLD with NEW, save on a temporary file sed "s/$OLD/$NEW/g" ${file} > ${file}.new # rename the temporary file as the original file /bin/mv ${file}.new ${file} done ---------------------------------------- On Thursday 19 September 2002 13:02, Günter Denz wrote:
Habe eine Textdatei in der gewisse Zeichen durhc eine zeichenkette ersetzt werden sollen. Die neue Zeichenkette soll aber nicht interpretiert werden sondern genau so eingetragen werden.
-- hnz geeratz mail: staff@room23.de web: www.room23.de
Hallo Günter, Günter Denz schrieb:
Hallo liste,
habe folgendes Problem.
Habe eine Textdatei in der gewisse Zeichen durhc eine zeichenkette ersetzt werden sollen. Die neue Zeichenkette soll aber nicht interpretiert werden sondern genau so eingetragen werden.
Beispiel:
Im Text "Rückmeldung" soll das ü durch "\201" ersetzt werden. Das sieht ann so aus: "R\201ckmeldung also das \201 soll nicht als oktales Ascii zeichen interpretiert werden.
Hat da jemand eine Löung, wie ich das am einfachsten in einer Textdatei hin bekomme? es sollen natürlich alle vorkommen ersetzt werden und die Datei dann wieder abgespeichert werden.
z.B. cat dateiname | sed -e "s/ü/\\/201/g" > datei_ohne_umlaut_u Gruß Martin
Zitat von Günter Denz
habe folgendes Problem.
Habe eine Textdatei in der gewisse Zeichen durhc eine zeichenkette ersetzt werden sollen. Die neue Zeichenkette soll aber nicht interpretiert werden sondern genau so eingetragen werden.
Beispiel:
Im Text "Rückmeldung" soll das ü durch "\201" ersetzt werden. Das sieht ann so aus: "R\201ckmeldung also das \201 soll nicht als oktales Ascii zeichen interpretiert werden.
Hat da jemand eine Löung, wie ich das am einfachsten in einer Textdatei hin bekomme? es sollen natürlich alle vorkommen ersetzt werden und die Datei dann wieder abgespeichert werden.
mit mktemp eine Temporärdatei erzeugen, mit sed da reinfiltern und anschließend die Dateien umbenennen bzw. löschen. Genauere Infos gibts auf man sed und man mktemp. -- Erhard Schwenk http://www.fto.de - http://www.akkordeonjugend.de ------------------------------------------------- This mail sent through FTO WebMail
Moin Moin,
From: "Günter Denz"
Habe eine Textdatei in der gewisse Zeichen durhc eine zeichenkette ersetzt werden sollen. Die neue Zeichenkette soll aber nicht interpretiert werden sondern genau so eingetragen werden. Im Text "Rückmeldung" soll das ü durch "\201" ersetzt werden. Das sieht ann so aus: "R\201ckmeldung also das \201 soll nicht als oktales Ascii zeichen interpretiert werden.
perl -p -i -e 's/alt/neu/g' datei.txt man perl,sed,awk Ciao Andre
Das sollte über sed gehen, also "man sed". Die genaue Syntax kenne ich im Moment aber auch nicht. Die manpage ist auch in Detsch verfügbar unter: http://www.infodrom.north.de/cgi-bin/man2html?page=sed§ion=1&language=de
Hallo liste,
habe folgendes Problem.
Habe eine Textdatei in der gewisse Zeichen durhc eine zeichenkette ersetzt werden sollen. Die neue Zeichenkette soll aber nicht interpretiert werden sondern genau so eingetragen werden.
Beispiel:
Im Text "Rückmeldung" soll das ü durch "\201" ersetzt werden. Das sieht ann so aus: "R\201ckmeldung also das \201 soll nicht als oktales Ascii zeichen interpretiert werden.
Hat da jemand eine Löung, wie ich das am einfachsten in einer Textdatei hin bekomme? es sollen natürlich alle vorkommen ersetzt werden und die Datei dann wieder abgespeichert werden.
Gruss und Danke Günter
-------------------------------------------- PS Automation GmbH Gesellschaft für Antriebtechnik Philip-Krämer-Ring 13 67098 Bad Dürkheim
Tel.: 06322/6003-0 Fax.: 06322/6003-20
-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com
Im Text "Rückmeldung" soll das ü durch "\201" ersetzt werden. also das \201 soll nicht als oktales Ascii zeichen interpretiert werden. [..] .. es sollen natürlich alle vorkommen ersetzt werden und die Datei dann wieder abgespeichert werden.
cat file|sed -e 's/ü/\\201/g'>file # oder perl -i -pe 's/ü/\\201/g' file
On Fre, 20 Sep 2002 at 20:00 (+0200), Achim Hoffmann wrote:
Im Text "Rückmeldung" soll das ü durch "\201" ersetzt werden. also das \201 soll nicht als oktales Ascii zeichen interpretiert werden. [..] .. es sollen natürlich alle vorkommen ersetzt werden und die Datei dann wieder abgespeichert werden.
cat file|sed -e 's/ü/\\201/g'>file
Noch ein *useless use of cat award* und außerdem überschreibst Du Dir Deine Eingabedatei. Das wird schiefgehen :-( <schnipp> jan@k500:~/tmp> for i in `seq 1 10000`; do
echo "über vülen üblen Tüpen würgt üzgüz ürre dürre füsse" >>file done jan@k500:~/tmp> ll insgesamt 509 -rw-r--r-- 1 jan users 520000 Sep 20 21:35 file jan@k500:~/tmp> cp file datei jan@k500:~/tmp> cat file|sed -e 's/ü/\\201/g'>file jan@k500:~/tmp> ll insgesamt 525 -rw-r--r-- 1 jan users 520000 Sep 20 21:35 datei -rw-r--r-- 1 jan users 12917 Sep 20 21:35 file jan@k500:~/tmp> sed -e 's/ü/\\201/g' datei >datei.neu && mv datei.neu datei jan@k500:~/tmp> ll insgesamt 821 -rw-r--r-- 1 jan users 820000 Sep 20 21:37 datei -rw-r--r-- 1 jan users 12917 Sep 20 21:35 file <schnapp>
Leute, ich kann es langsam nicht mehr sehen. Ihr gewöhnt Euch eine furchtbar umständliche Art und Weise an, mit Linux umzugehen, wenn Ihr dauernd den cat anschmeisst. So viele Kommandos können mit Dateinamen umgehen, also nutzt das doch! sed -e 's/ü/\\201/g' datei >datei.neu && mv datei.neu datei SCNR Jan
On Fri, 20 Sep 2002, Jan Trippler wrote:
cat file|sed -e 's/ü/\\201/g'>file
Noch ein *useless use of cat award* und außerdem überschreibst Du Dir Deine Eingabedatei. Das wird schiefgehen :-(
ok, ich gebe zu dass ich den Sonderfall "Linux *und* bash *und* File ab bestimmter Groesse" nicht getestet habe. Schande ueber mich. Das heisst aber nicht, dass es prinzipiell falsch ist (siehe unten). Das Beispiel mit dem temporaeren File ist in den meisten Faellen (SHELL, OS, grosse Files) das universellste. So, damit ist gut, der Rest ist off-topic. Achim =========================================================================== Nachdem ich nun einen Award gewonnen habe, muss ich natuerlich auch eine Rede halten, wer sich dabei durch meine bissigen und/oder sarkastischen Bemerkungen angesprochen fuehlt, ist **selbstverstaendlich** gemeint ;-) Vielleicht bin ich einfach zu alt fuer so moderne Sachen wie Linux und bash und GHz-CPUs, etc., das "cat file|sed ... >file" Beispiel benutze ich seit Jahren mit csh auf SunOS, und es funktioniert (auch Files >> 10MB). Weil die Frage nach "ersetzen" war, und man oft keinen Platz fuer eine Kopie hat, habe ich halt schlicht Copy&Paste gemacht, ich haette testen ... aber das sagte ich schon. Shit happens .. Kurz gesagt: es sollte eine Loesung sein die das File on-the-fly aendert, ohne temporaere Kopie. Jan, leider hast du nicht gesagt warum *dein* Beispiel mit *meinem* Vorschlag nicht funktioniert. Es funktioniert unter bestimmten Bedingungen. Nennen wir diese Bedingung einfach Funktion: f(SHELL,OS,CPU). Und hier eine Loesung die mit f(bash,Linux,i386) funktioniert: # --- (alles in einer Zeile:) /bin/ls -l file|/bin/awk '{x=$5/8100;printf"(/bin/cat %s)", $NF;}END{for(i=1;i<=x;i++){printf "|/bin/cat"};print "|/bin/sed -e '"'"'s/ü/\\\\201/g'"'"'>file"}'|/bin/sh # --- Dieses command-line-Monstrum hat nichts mehr mit der urspruenglichen Frage zu tun (auch wenn es dafuer funktioniert), es soll einfach nur zeigen warum mein award-winning Vorschlag mit grossen Files nicht geht, dieses Monstrum aber schon. Wer genau hinschaut sieht den Grund ... .. ich gebe nur einen Tip: 8100 ist das Ergebnis von f(bash,Linux,i386) ;-) Ausser fuer f(*,HP-UX,*) duerfte es fuer die meisten Varianten gehen, 8100 muss halt entsprechend angepasst werden (viel Spass beim Ausprobieren). Es soll aber nicht verschwiegen werden dass es auch hier Grenzen gibt: user && file-sze && [u]limit && command-line buffer-size && #process/user && #process/system && swap-size && RAM-size && etc. (diskutieren wir lieber nicht weiter, never-ending story ...) Ausserdem versteht man jetzt warum ich (vielleicht) fuer den falschen Award nomminiert wurde. Uberschreiben kann passieren (siehe oben), aber cat hat schon seinen Sinn (zumin. in meinem Beispiel). "cat file|sed ... >file" ist nur die Kurzform des Monstrums, und funktioniert dann eben nur wenn alle Bedingungen erfuellt sind, was bei f(bash,Linux,i386) leider nicht der Fall ist :-(
.. eine furchtbar umständliche Art und Weise an, mit Linux umzugehen, wenn Ihr dauernd den cat anschmeisst.
Ich unterstelle dem Schreiber einfach, dass er den Trick nicht verstanden hat. Schade, aber gut ich hatte es ja auch nicht explizit erklaert. Ich haette vielleicht besser schreiben sollen: (cat file)|sed ... >file denn ich habe ja nicht --wie in einem anderen Posting-- geschrieben: cat file|sed ... >tmp.file; mv tmp.file file (das ist in der Tat ein *usless use of cat* und *useless waste of resources*) Soweit alles klar? Einen *useless ... award* fuer eine funktionierende (Sonder-)Loesung, muss ich den jetzt zurueckgeben? :-]] =========================================================================== Gut, wo wir schon bei Awards sind, dann koennte man noch den *Don't KISS Award* verleihen. Und zwar fuer dieses Konstrukt:
for f in `seq 1 10000`;do echo 'text'>>file;done
Ohne lange nachzudenken wuerde ich das so schreiben: #----------- perl -e 'print "text\n"x10000;'>file awk 'BEGIN{for(i=1;i<=10000;i++){print "text"}}'>file csh -c 'repeat 10000 echo "text"'>file #----------- KISS - keep it small and simple Wobei KISS nicht nur was fuers Auge ist ;-) Entscheident ist, dass alle Losungen min. Faktor 5 (csh) bis 50 (perl) schneller sind; und das ohne das System nennenswert zu belasten (nur I/O). Wird aus 10000 jedoch 10000000, dann wird's spannend (ausreichend swap vorausgesetzt): perl und awk schaffen es immer noch in weniger als 1 Minute, aber das "for .. seq .." Beispiel haengt mit grosser Wahrscheinlichkeit den Rechner auf. Klasse. Also man koennte das so priorisieren (diese Beispile, nicht allgemein): csh wenn die Nachwelt verstehen soll was pasiert perl wenn es schnell gehen soll/muss awk wenn kein perl da ist (awk ist auf jedem UNIX) bash wenn ich das System ins Nirvana schicken will (-: alle 3 Beispiele funktionieren natuerlich auch unter Linux mit bash :-) Genug fuer heute bash# :(){ :; };: Achim P.S. es geht hier nicht um/gegen Linux, bash etc., sondern nur um die darin ausgefuehrten Kommandos
On Sam, 21 Sep 2002 at 20:17 (+0200), Achim Hoffmann wrote:
On Fri, 20 Sep 2002, Jan Trippler wrote:
cat file|sed -e 's/ü/\\201/g'>file
Noch ein *useless use of cat award* und außerdem überschreibst Du Dir Deine Eingabedatei. Das wird schiefgehen :-(
ok, ich gebe zu dass ich den Sonderfall "Linux *und* bash *und* File ab bestimmter Groesse" nicht getestet habe. Schande ueber mich.
(eine Zeile) jan@P75:~ > echo "über vülen üblen Tüpen würgt üzgüz ürre dürre füsse" >file jan@P75:~ > ll file -rw-r--r-- 1 jan users 52 Sep 21 23:24 file jan@P75:~ > cat file | sed -e 's/ü/\\201/g'>file jan@P75:~ > ll file -rw-r--r-- 1 jan users 0 Sep 21 23:25 file Soviel zum Thema "*und* File ab bestimmter Groesse". Dass in dieser Liste Linux und bash mitnichten einen Sonderfall darstellen, sollte ich Dir wohl noch verraten.
Das heisst aber nicht, dass es prinzipiell falsch ist (siehe unten).
Doch. Du verlässt Dich darauf, dass das Betriebssystem in einer bestimmten Art und Weise reagiert, die Du nicht kennst und auf die Du keinen Einfluss hast.
Das Beispiel mit dem temporaeren File ist in den meisten Faellen (SHELL, OS, grosse Files) das universellste.
So, damit ist gut, der Rest ist off-topic.
Achim
=========================================================================== Nachdem ich nun einen Award gewonnen habe, muss ich natuerlich auch eine Rede halten, wer sich dabei durch meine bissigen und/oder sarkastischen Bemerkungen angesprochen fuehlt, ist **selbstverstaendlich** gemeint ;-)
Aus Deinen nachfolgenden Auslassungen habe ich nur verstanden, dass Du Dich fürchterlich auf den Schlips getreten fühlst und ich weiss ehrlich gesagt nicht, warum. Dein vorgeschlagener Weg funktioniert nicht, der Anwender Deiner Befehlsfolge riskiert Datenverlust. Darf ich darauf nicht hinweisen?
Vielleicht bin ich einfach zu alt fuer so moderne Sachen wie Linux und bash und GHz-CPUs, etc., das "cat file|sed ... >file" Beispiel benutze ich seit Jahren mit csh auf SunOS, und es funktioniert (auch Files >> 10MB).
Du benutzt seit Jahren eine Konstruktion, die nur unter bestimmten Umständen funktioniert. Mein Test lief übrigens nicht auf einer GHz-CPU und dass wir hier von Linux reden, liegt wohl in der Natur dieser ML. Zur Info: Der obige Ausschnitt entstand auf einem Pentium 75 MHz, Kernel 2.2.10, 48 MB RAM. Gleiches Ergebnis auf AMD K6-2 500 MHz, Kernel 2.4.18, 512 MB RAM. Wenn gewünscht, reiche ich gerne noch Testergebnisse von 486 DX33, K6 233 und P4 1,4 GHz nach. [...]
Ich unterstelle dem Schreiber einfach, dass er den Trick nicht verstanden hat. Schade, aber gut ich hatte es ja auch nicht explizit erklaert.
Korrekt, diesen *Trick* habe ich nicht verstanden. Es ist IMHO falsch, auch wenn Du jetzt viele Zeilen auf einen Erklärungsversuch verwendet hast. Ich schreibe nun mal nicht in eine Datei, die ich zum Lesen geöffnet habe! Auf die Arbeitsweise von cat, Pipe und sed hast Du in der Shell keinen Einfluss, also solltest Du auch defensiv arbeiten, so dass derartige Implementierungs-Details keinen Einfluss auf Dein Ergebnis haben.
Einen *useless ... award* fuer eine funktionierende (Sonder-)Loesung, muss ich den jetzt zurueckgeben? :-]]
Herrjeh, wenn es Dich so wurmt, betrachte meine Mail als nicht geschrieben und mache mit Deiner (Sonder-)Loesung weiter, bis Du mal richtig auf die Nase fällst.
Gut, wo wir schon bei Awards sind, dann koennte man noch den *Don't KISS Award* verleihen. Und zwar fuer dieses Konstrukt:
for f in `seq 1 10000`;do echo 'text'>>file;done
Ohne lange nachzudenken wuerde ich das so schreiben:
#----------- perl -e 'print "text\n"x10000;'>file
awk 'BEGIN{for(i=1;i<=10000;i++){print "text"}}'>file
csh -c 'repeat 10000 echo "text"'>file #-----------
Es scheint Dich glücklich zu machen, also her damit. Ich werde allerdings auch in Zukunft für das Aufbauen von Testdaten weder perl noch awk anschmeissen noch meine Standard-Shell wechseln. Da ich solche Testdateien in der Regel nicht mehr als einmal pro Monat brauche, sind mir die Ausführungszeiten sch***egal - sorry. Ich nehme dann einfach das erste, was mir in die Finger kommt. Du wirst jetzt wahrscheinlich vor Entsetzen aufschreien, aber ich habe auch schon grafische Editoren zu diesem Zweck benutzt - huch!
Entscheident ist, dass alle Losungen min. Faktor 5 (csh) bis 50 (perl) schneller sind; und das ohne das System nennenswert zu belasten (nur I/O). Wird aus 10000 jedoch 10000000, dann wird's spannend (ausreichend swap vorausgesetzt): perl und awk schaffen es immer noch in weniger als 1 Minute, aber das "for .. seq .." Beispiel haengt mit grosser Wahrscheinlichkeit den Rechner auf. Klasse.
<Ironie> Ich bitte noch mal vielmals um Vergebung, dass ich beim Erzeugen der Testdatei, die das Nichtfunktionieren Deiner Lösung zeigt, so nachlässig war, nicht die perfekteste Version zu wählen. Beim nächsten Mal werde ich Dich natürlich vorher konsultieren. </Ironie> Jan
participants (8)
-
Achim Hoffmann -
Andre Heine -
Erhard Schwenk -
Günter Denz -
hnz geeratz -
Jan.Trippler＠t-online.de -
Martin Knipper -
Thomas Gräber