30
Mit Linux am ende einer Datei eine Leerzeile einfügen
Tach ihr alle,
Ich wollte mal einen etwas aufwendigen Script schreiben welches via Cronejob zur bestimmten Zeiten ausgeführt werden soll.
Geschweige von anderen Problemen, habe ich das Problem, dass ich nicht wirklich die Möglichkeit finde eine normale Leerzeile am Ende allen Datein einfügen kann.
Setzt eine Leerzeile welche unter Notepad zusehen ist leider aber auch noch ein Zeilenumbruch welches unter WordPad erkennbar ist. D.h. Ich habe zwei Leerzeilen.
Habt Ihr eine andere Idee?
Wichtig ist, es darf kein Leerzeichen oder sonstiges sein, denn das ist der Anfang für die nächste Datei welche an diese Stelle an gehangen werden soll.
Grüße Ich
Ich wollte mal einen etwas aufwendigen Script schreiben welches via Cronejob zur bestimmten Zeiten ausgeführt werden soll.
Geschweige von anderen Problemen, habe ich das Problem, dass ich nicht wirklich die Möglichkeit finde eine normale Leerzeile am Ende allen Datein einfügen kann.
sed -i '$a\' /samba/ELSendEx20*.txt Setzt eine Leerzeile welche unter Notepad zusehen ist leider aber auch noch ein Zeilenumbruch welches unter WordPad erkennbar ist. D.h. Ich habe zwei Leerzeilen.
Habt Ihr eine andere Idee?
Wichtig ist, es darf kein Leerzeichen oder sonstiges sein, denn das ist der Anfang für die nächste Datei welche an diese Stelle an gehangen werden soll.
Grüße Ich
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 318098
Url: https://administrator.de/contentid/318098
Ausgedruckt am: 25.11.2024 um 07:11 Uhr
30 Kommentare
Neuester Kommentar
Mit echo kann man einen Zeilenumbruch einfügen:
Einfach \r\n durch den richtigen Escape Sequenz ersetzen, je nach Betriebssystem LINK
echo -e -n '\r\n' >> /path/to/file.txt Einfach \r\n durch den richtigen Escape Sequenz ersetzen, je nach Betriebssystem LINK
Zitat von @OIOOIOOIOIIOOOIIOIIOIOOO:
Setzt eine Leerzeile welche unter Notepad zusehen ist leider aber auch noch ein Zeilenumbruch welches unter WordPad erkennbar ist. D.h. Ich habe zwei Leerzeilen.
Setzt eine Leerzeile welche unter Notepad zusehen ist leider aber auch noch ein Zeilenumbruch welches unter WordPad erkennbar ist. D.h. Ich habe zwei Leerzeilen.
Definiere mal, was für Textformat du hast? Und welche Zeilenende-Kodierung dur brauchst? CR CRLF oder nur LF?
Soll einfach nur ein Zeilenende angefügt werden? oder eine ohne zelen ende?
Ansonsten mach man da einfach echo "" >>zieldatei.txt
hint:
- echo -n -e "\n" >> zieldatei.txt
- echo -n -e "\r" >> zieldatei.txt
- echo -n -e "\r\n" >> zieldatei.txt
lks
Hallo,
Auch bei Unix/Linux idte ein CR (Carriage Return) ein CR sowie ein LF (Line Feed) auch ein LF. Es unterscheiden sich nur die fälle wann es angewendet wird.
http://www.cs.toronto.edu/~krueger/csc209h/tut/line-endings.html
https://de.wikipedia.org/wiki/Zeilenumbruch#ASCII
http://stackoverflow.com/questions/1552749/difference-between-cr-lf-lf- ...
http://www.cyberciti.biz/faq/howto-unix-linux-convert-dos-newlines-cr-l ...
http://unix.stackexchange.com/questions/153091/how-to-add-a-carriage-re ...
Notepad = Windows OSe
Notepaddqq = Linux OSe
https://itsfoss.com/notepad-alternatives-for-linux/
Gruß,
Peter
Zitat von @OIOOIOOIOIIOOOIIOIIOIOOO:
dass ich nicht wirklich die Möglichkeit finde eine normale Leerzeile am Ende allen Datein einfügen kann.
Wenn du eine Leerzeile an deine Datenzeile anfpgst hast du keine leerzeile mehr. dass ich nicht wirklich die Möglichkeit finde eine normale Leerzeile am Ende allen Datein einfügen kann.
Habt Ihr eine andere Idee?
Wechselst du immer zwichen Unix/Windows hin und her? in beiden OSe wird ein Carriage Return und Line Feed eben anders generiert bzw. grundlegend angewendet.Auch bei Unix/Linux idte ein CR (Carriage Return) ein CR sowie ein LF (Line Feed) auch ein LF. Es unterscheiden sich nur die fälle wann es angewendet wird.
http://www.cs.toronto.edu/~krueger/csc209h/tut/line-endings.html
https://de.wikipedia.org/wiki/Zeilenumbruch#ASCII
http://stackoverflow.com/questions/1552749/difference-between-cr-lf-lf- ...
http://www.cyberciti.biz/faq/howto-unix-linux-convert-dos-newlines-cr-l ...
http://unix.stackexchange.com/questions/153091/how-to-add-a-carriage-re ...
Notepad = Windows OSe
Notepaddqq = Linux OSe
https://itsfoss.com/notepad-alternatives-for-linux/
Wichtig ist, es darf kein Leerzeichen oder sonstiges sein,
Aber ein LF "\n" oder in Win ein CRLF "\r\n" darf es schon sein.Gruß,
Peter
Zitat von @Cloudy:
Mit echo kann man einen Zeilenumbruch einfügen:
Mit echo kann man einen Zeilenumbruch einfügen:
echo -e -n '\r\n' >> /path/to/file.txt [root@xxx]# echo -n -e "\r\n" >> /samba/ELSendEx20*.txt
-bash: /samba/ELSendEx20*.txt: Mehrdeutige Umlenkung.
Zitat von @Lochkartenstanzer:
Definiere mal, was für Textformat du hast? Und welche Zeilenende-Kodierung dur brauchst? CR CRLF oder nur LF?
Definiere mal, was für Textformat du hast? Und welche Zeilenende-Kodierung dur brauchst? CR CRLF oder nur LF?
\r\n ist richtig, oder wenn ich es richtig verstanden hab CRLF. Jedoch funktioniert es leider nicht, da die Datein immer anders heißen. Darum hab ich es mit sed probiert.
Ja es wird mit Linux und Windows verarbeitet.
Hallo,
Dein * sollte dir jetzt mal zu denken geben. Es muss ein eindeutiges Ziel sein und mit * ist es das nicht mehr. Du wirst deine Ziele schon einzeln ansprechen müssen.
Beispiel: hier die gleiche Datei welche nur ein 32 0A (SP LF) enthält zwischen dem "1" und dem 2014.
Ansicht im Norton Commander wie es innerhalb der Datei geschrieben ist
Ansicht im Notepad (Win) - kein Umbruch der Zeile beim Darstellung
Ansicht im Wordpad (Win) - Umbruch der Zeile beim Darstellen
Linux oder Windows, das ist hier die Frage Wichtig ist also nicht nur das Darstellen sondern auch wie die Datei gespeichert wird.
Gruß,
Peter
Dein * sollte dir jetzt mal zu denken geben. Es muss ein eindeutiges Ziel sein und mit * ist es das nicht mehr. Du wirst deine Ziele schon einzeln ansprechen müssen.
\r\n ist richtig, oder wenn ich es richtig verstanden hab CRLF. Jedoch funktioniert es leider nicht, da die Datein immer anders heißen. Darum hab ich es mit sed probiert.
Du solltest dir klar werden wie ein Linux/Unix oder Windows Textdateien / Dateien im allgemeinen handhabt.Ja es wird mit Linux und Windows verarbeitet.
Und das ist dein Problem.<code type = plain>Bei im Textmodus geöffneten Dateien erfolgt eine Übersetzung von \n in die auf dem jeweiligen System üblichen Steuerzeichen für den Zeilenumbruch. Somit erfolgt in unixartigen Betriebssystem keine Umsetzung, da dort LF bereits für den Zeilenumbruch steht. Dagegen findet unter Windows eine Substitution durch CR LF statt. Die resultierenden Dateien sind folglich nicht identisch. Ist die Datei im Binärmodus geöffnet, erfolgt keine Übersetzung, sondern es wird stets ein LF in die Datei geschrieben.Beispiel: hier die gleiche Datei welche nur ein 32 0A (SP LF) enthält zwischen dem "1" und dem 2014.
Ansicht im Norton Commander wie es innerhalb der Datei geschrieben ist
Ansicht im Notepad (Win) - kein Umbruch der Zeile beim Darstellung
Ansicht im Wordpad (Win) - Umbruch der Zeile beim Darstellen
Linux oder Windows, das ist hier die Frage
Wichtig ist also nicht nur das Darstellen sondern auch wie die Datei gespeichert wird.Gruß,
Peter
Ok vielen Dank für deine Erklärung nun habe ich aber zwei Fragen.
Warum erreiche ich mit dem folgendem Befehl das gewünschte Ergebnis in eine Einzelne Datei?:
Wie kann ich das Ergebnis auf unterschiedlich benannte Dateien umlegen?
Es ist ja kein Geheimnis.
Die Dateien werden an den rot markierten Stellen unter Linux und Windows gleich dargestellt. Der einzige Unterschied ist unter VIM zusehen in dunkelblau "^M" aber das muss ich ja glücklicherweise nicht anfassen.
Warum erreiche ich mit dem folgendem Befehl das gewünschte Ergebnis in eine Einzelne Datei?:
echo -e -n '\r\n' >> /path/to/file.txt Wie kann ich das Ergebnis auf unterschiedlich benannte Dateien umlegen?
Es ist ja kein Geheimnis.
Die Dateien werden an den rot markierten Stellen unter Linux und Windows gleich dargestellt. Der einzige Unterschied ist unter VIM zusehen in dunkelblau "^M" aber das muss ich ja glücklicherweise nicht anfassen.
Hallo,
Standard Ausgabe umleiten und am Ende anhängen https://de.wikibooks.org/wiki/Batch-Programmierung:_Batch-Operatoren#.3E ...
Dein Bild zeigt ein Auschnitt einer CSV Datei. Allerding ist hier nicht erkennbar ob es sich um 1 Einen) Datensatz oder gleich mehrer handelt. Wir sehen (durch deinen verwendetes CSV Betrachtungsprogramm) ja gar nicht was an den entscheidenden Stellen tatsächlich innerhalb der Datei gespeichert ist. Auch ein Linux zeigt dir nicht so ohne weiteres diese eben Nicht darstellbaren Zeichen an. Oftmals sieht man noch Hieroglyphen wenn man glück hat. dann sollte man schon wissen wenn man CSV Dateien betrachtet wo denn ein Datensatz afängt oder endet. Nur weil dort nichts zu sehen ist.... Somit ist dein Bild als Informationsgehalt bezüglich eines CR LF (0D 0A) absolut zwecklos.
Der einzige Unterschied ist unter VIM zusehen in dunkelblau "^M" aber das muss ich ja glücklicherweise nicht anfassen.
Umlaute oder sowas an den Stellen zu Erwarten? Sonderzeichen wie ein ° oder so etwas. Wenn ein VIM meint es nicht darstellen zu können - dann passiert genau dies - du siehst hier dann Hieroglyphen. OS und Editor entsprechend auf verwendeten zeichensatz einstellen...
Hier mal ein anderes Beispiel. Eine Konfig einer Fritte
Dargestellt im Notepad mit Zeilenumbruch
Dargestellt im Notepad ohne zeilenumbruch
Dargestellt in Wordpad ohne Zeilenumbruch
Dargestellt im Norton Commander (F4 und Text Modus)
Dargestellt im Norton Commander (F4 und HEX Modus). Hier sieht man tatsächlich was innerhalb der Datei drin steht und wieso ein Zeilenumbruch erfolgt. Das 0A ist der auslöser und diese Datei wurde in ein Linux erzeugt und in Windows versucht darzustellen bzw. zu editieren. Und auch dein >> hat in Windows Probleme beim auffinden der tatsächlichen Zeilenumbrüche wenn dort nicht* ein 0D 0A** steht. Linux geht da anders dran.
Es ist nicht entscheidend was man nicht sieht, entscheidend ist was dort enthalten ist was man nicht sieht.
Nimm mal einen Hexeditor, schreibe in einer leeren Datei direkt 20 mal 07 0D 0A rein, danach speichern und mit Notepad öffnen. Sehen tust du nichts, aber deine Ohren klingel (sofern Lautsprecher etc. Vorhanden und in Betrieb) https://de.wikipedia.org/wiki/American_Standard_Code_for_Information_Int ...
Gruß,
Peter
Zitat von @OIOOIOOIOIIOOOIIOIIOIOOO:
Warum erreiche ich mit dem folgendem Befehl das gewünschte Ergebnis in eine Einzelne Datei?:
Weil ein >>Pfad\Datei immer am Ende einer Datei anhängt. Wenn die Datei nicht existiert wird eben eine erzeugt zum anhängen Warum erreiche ich mit dem folgendem Befehl das gewünschte Ergebnis in eine Einzelne Datei?:
Standard Ausgabe umleiten und am Ende anhängen https://de.wikibooks.org/wiki/Batch-Programmierung:_Batch-Operatoren#.3E ...Wie kann ich das Ergebnis auf unterschiedlich benannte Dateien umlegen?
Du musst natürlich die Unterschiede deiner OSe beachten. Linux kann und tut ein Zeilenumbruch anders auswerten als ein DOS/Windows. Windows kann nur ein OD OA (CR LF) ohne besondere Anweisungen Korrekt darstellen. Gutes Beispiel ist einmal dein Notepad (Win7 usw) zu nutzen und dann die gleiche Datei mal mit dein Wordpad zu nutzen. Beide stellen ein einziges 0A (LF) anders dar.Dein Bild zeigt ein Auschnitt einer CSV Datei. Allerding ist hier nicht erkennbar ob es sich um 1 Einen) Datensatz oder gleich mehrer handelt. Wir sehen (durch deinen verwendetes CSV Betrachtungsprogramm) ja gar nicht was an den entscheidenden Stellen tatsächlich innerhalb der Datei gespeichert ist. Auch ein Linux zeigt dir nicht so ohne weiteres diese eben Nicht darstellbaren Zeichen an. Oftmals sieht man noch Hieroglyphen wenn man glück hat.
dann sollte man schon wissen wenn man CSV Dateien betrachtet wo denn ein Datensatz afängt oder endet. Nur weil dort nichts zu sehen ist.... Somit ist dein Bild als Informationsgehalt bezüglich eines CR LF (0D 0A) absolut zwecklos.Die Dateien werden an den rot markierten Stellen unter Linux und Windows gleich dargestellt.
Als was werden die Stellen denn dargestellt? Du weisst das es gar Wortumbrüche, Zeilenumbrüche, Absätze usw. auch in eine einfaches Textdokument geibt wenn das betrachtungsprg. solche Features eingebaut hat. Dazu ist kein Code bzw. Zeichen im Quelltext notwendig. Viele Editoren machen das als Standard - es liesst sich besser, aber sagt nicht wirklich aus was an Zeichen im Quelltext tatsächlich enthalten sind.Der einzige Unterschied ist unter VIM zusehen in dunkelblau "^M" aber das muss ich ja glücklicherweise nicht anfassen.
Umlaute oder sowas an den Stellen zu Erwarten? Sonderzeichen wie ein ° oder so etwas. Wenn ein VIM meint es nicht darstellen zu können - dann passiert genau dies - du siehst hier dann Hieroglyphen. OS und Editor entsprechend auf verwendeten zeichensatz einstellen...
Hier mal ein anderes Beispiel. Eine Konfig einer Fritte
Es ist nicht entscheidend was man nicht sieht, entscheidend ist was dort enthalten ist was man nicht sieht.
Nimm mal einen Hexeditor, schreibe in einer leeren Datei direkt 20 mal 07 0D 0A rein, danach speichern und mit Notepad öffnen. Sehen tust du nichts, aber deine Ohren klingel (sofern Lautsprecher etc. Vorhanden und in Betrieb) https://de.wikipedia.org/wiki/American_Standard_Code_for_Information_Int ...
Gruß,
Peter
Guten Morgen,
verstehe. Danke dir, habe endlich einen Grund gefunden nach einen Hexeneditor für Linux zu suchen. Es ist Kette 0D 0A welche ich brauche.
PS 20x Biep hat nicht funktioniert. :/ Ist jetzt aber nicht das Wesentliche
verstehe. Danke dir, habe endlich einen Grund gefunden nach einen Hexeneditor für Linux zu suchen. Es ist Kette 0D 0A welche ich brauche.
PS 20x Biep hat nicht funktioniert. :/ Ist jetzt aber nicht das Wesentliche
Guten Abend noch einmal.
Irgend wie funktioniert es nicht so wie ich es möchte.
Hat jemand eine Lösung für mich?
SET und ECHO kommt leider nicht in Frage, da die betroffenen Dateien mit nur ersten sechs Zeichen gleich sind, d.H. ich muss Platzhalter * verwenden und das kann weder SET noch ECHO.
Bis jetzt habe ich PERL und AWK probiert, nur fehlt mir hier die passende Operation.
perl -pi -e '{print "\r\n"}' /home/ELSendEx20*.txt
Macht vor jede Zeile eine neue Zeile, gewünscht ist aber am Ende der Datei (eine neue Zeile).
Grüße
Ich
Irgend wie funktioniert es nicht so wie ich es möchte.
Hat jemand eine Lösung für mich?
SET und ECHO kommt leider nicht in Frage, da die betroffenen Dateien mit nur ersten sechs Zeichen gleich sind, d.H. ich muss Platzhalter * verwenden und das kann weder SET noch ECHO.
Bis jetzt habe ich PERL und AWK probiert, nur fehlt mir hier die passende Operation.
perl -pi -e '{print "\r\n"}' /home/ELSendEx20*.txt
Macht vor jede Zeile eine neue Zeile, gewünscht ist aber am Ende der Datei (eine neue Zeile).
Grüße
Ich
Zitat von @OIOOIOOIOIIOOOIIOIIOIOOO:
SET und ECHO kommt leider nicht in Frage, da die betroffenen Dateien mit nur ersten sechs Zeichen gleich sind, d.H. ich muss Platzhalter * verwenden und das kann weder SET noch ECHO.
Bis jetzt habe ich PERL und AWK probiert, nur fehlt mir hier die passende Operation.
perl -pi -e '{print "\r\n"}' /home/ELSendEx20*.txt
SET und ECHO kommt leider nicht in Frage, da die betroffenen Dateien mit nur ersten sechs Zeichen gleich sind, d.H. ich muss Platzhalter * verwenden und das kann weder SET noch ECHO.
Bis jetzt habe ich PERL und AWK probiert, nur fehlt mir hier die passende Operation.
perl -pi -e '{print "\r\n"}' /home/ELSendEx20*.txt
ls /home/ELSendEx20*.txt | xargs -l1 -I PLATZHALTERFUERDATEI echo -n -e "\r\n" >>PLATZHALTERFUERDATEI
lks
Vielen Dank für deine Antwort. Fehlt da nicht noch was?
irgend wie findet es keinen Abschluss.
irgend wie findet es keinen Abschluss.
Tippfehler: Das schließende "Gänsefüßchen". Hättest aber selbst eigentlich drauf kommen können.
lks
Ja das habe ich auch gesehen. Das meinte ich nicht. Es erwartet weitere Eingaben. :/
[root@stor ~]# ls /home/ELSendEx20*.txt | xargs -l1 -I PLATZHALTERFUERDATEI echo -n -e "\r\n\" >>PLATZHALTERFUERDATEI
>
>
>
>
> ^CZitat von @OIOOIOOIOIIOOOIIOIIOIOOO:
Ja das habe ich auch gesehen. Das meinte ich nicht. Es erwartet weitere Eingaben. :/
Ja das habe ich auch gesehen. Das meinte ich nicht. Es erwartet weitere Eingaben. :/
Dann versuch mal:
ls /home/ELSendEx20*.txt | xargs -l1 -I PLATZHALTERFUERDATEI echo 'echo -n -e "\r\n" >>PLATZHALTERFUERDATEI' | tee echoscript.sh
source echoscript.sh
lks
muß "\r\n" heißen!
Ein wenig mitdenken hätte ich schon erwartet.
lks
Tut mir leid. Ich muss mich hier echt auf fremde Hilfe verlassen. 
Dank "Pjordorf" habe ich erst über "\r\n" erfahren.
Also jetzt hat es zwar den Befehl beendet und ausgeführt an der originalen Datei hat sich jedoch nichts verändert und es wurde eine neue Datei erstellt namens "PLATZHALTERFUERDATEI" mit vier leereren Zeilen.
Dank "Pjordorf" habe ich erst über "\r\n" erfahren.
Also jetzt hat es zwar den Befehl beendet und ausgeführt an der originalen Datei hat sich jedoch nichts verändert und es wurde eine neue Datei erstellt namens "PLATZHALTERFUERDATEI" mit vier leereren Zeilen.
Liest Du egentlich, was ich schreibe?
Außerdem solltest Du Dir als erstes das zu Gemüte führen, wenn Du bash-skripte verstehen und schreiben willst. Das gehört zu den Grundlagen.
lks
Außerdem solltest Du Dir als erstes das zu Gemüte führen, wenn Du bash-skripte verstehen und schreiben willst. Das gehört zu den Grundlagen.
lks
ooh man, danke dir Ich habe das echo übersehen, Es funktioniert und zwar so wie ich es haben wollte. Auch einen großen Dank für deinen Link. Es sind wirklich coole Informationen dabei. DANKE DANKE
Ich habe das echo übersehen, Es funktioniert und zwar so wie ich es haben wollte. Auch einen großen Dank für deinen Link. Es sind wirklich coole Informationen dabei. DANKE DANKE
Du solltest beachten, daß das nur zwei schnell "hingerotzte" Zeilen ohne Rücksicht auf verluste und ohne sicherheitsgurt und Luftsack sind.
Wenn Du diese Zeilen öfters produktiv einsetzen willst, mußt Du da noch sicherheitsrelevante Abfragen einbauen ob zb die temporäre datei schon existiert
lks
Wenn Du diese Zeilen öfters produktiv einsetzen willst, mußt Du da noch sicherheitsrelevante Abfragen einbauen ob zb die temporäre datei schon existiert
lks
Ich lass die "echoscript.sh" nach jedem Ausführen löschen, aber ja du hast recht ich sollte vor dem Ausführen noch prüfen lassen ob diese wirklich nicht da ist. Danke.
Du mußt auch sicherstellen, daś die dateinamen keine leer-oder sonderzeichen haben oder diese entsprechend abfangen und daß die dateien keine links sind mit denen man die sytemsicherheit gefährdet.
lks
lks
Vielen Dank auch für diesen Hinweis. Jetzt habe ich allerdings ein anderes Problem.
Echt alles doof.
Jetzt wo ich eine Schleife gebastelt habe bekommen die Dateien am Ende zwei leerere Zeilen. Die Anzahl der Zeilen erhöht sich mit den Anzahl der Dateien im Verzeichnis.
Den Abschnitt "&& gawk -F: '{ print $0 }' $MOUNTFOLDER/ELSendEx20*.txt > $BACKUPFOLDER/heute.txt && mv $BACKUPFOLDER/Rueck$BACKUPDATE.txt $BACKUPFOLDER/letzte.txt && cat $BACKUPFOLDER/letzte.txt $BACKUPFOLDER/heute.txt > $BACKUPFOLDER/Rueck$BACKUPDATE.txt && rm $BACKUPFOLDER/letzte.txt " kann man auch ignorieren, denn auch ohne wird es nicht besser.
Echt alles doof.
Jetzt wo ich eine Schleife gebastelt habe bekommen die Dateien am Ende zwei leerere Zeilen.
Die Anzahl der Zeilen erhöht sich mit den Anzahl der Dateien im Verzeichnis.for file in $MOUNTFOLDER/ELSendEx20*; do
if [ -f ${file} ] ; then
grep -a -h ';;;01;Lager;;;;' $MOUNTFOLDER/ELSendEx20*.txt > $TOLKORUECK/Rueck$TODAY.txt && grep -a -h ';;;02;Biglager;;;;' $MOUNTFOLDER/ELSendEx20*.txt > $MEGARUECK/Rueck$TODAY.txt && ls $MOUNTFOLDER/ELSendEx20*.txt | xargs -l1 -I PLATZHALTERFUERDATEI echo 'echo -n -e "\r\n" >>PLATZHALTERFUERDATEI' | tee /root/echoscript.sh && source /root/echoscript.sh && rm -f /root/echoscript.sh && gawk -F: '{ print $0 }' $MOUNTFOLDER/ELSendEx20*.txt > $BACKUPFOLDER/heute.txt && mv $BACKUPFOLDER/Rueck$BACKUPDATE.txt $BACKUPFOLDER/letzte.txt && cat $BACKUPFOLDER/letzte.txt $BACKUPFOLDER/heute.txt > $BACKUPFOLDER/Rueck$BACKUPDATE.txt && rm $BACKUPFOLDER/letzte.txt
else
break
fi
doneDen Abschnitt "&& gawk -F: '{ print $0 }' $MOUNTFOLDER/ELSendEx20*.txt > $BACKUPFOLDER/heute.txt && mv $BACKUPFOLDER/Rueck$BACKUPDATE.txt $BACKUPFOLDER/letzte.txt && cat $BACKUPFOLDER/letzte.txt $BACKUPFOLDER/heute.txt > $BACKUPFOLDER/Rueck$BACKUPDATE.txt && rm $BACKUPFOLDER/letzte.txt " kann man auch ignorieren, denn auch ohne wird es nicht besser.
Zitat von @OIOOIOOIOIIOOOIIOIIOIOOO:
grep -a -h ';;;01;Lager;;;;' $MOUNTFOLDER/ELSendEx20*.txt ...
for file in $MOUNTFOLDER/ELSendEx20*; do
if [ -f ${file} ] ; thengrep -a -h ';;;01;Lager;;;;' $MOUNTFOLDER/ELSendEx20*.txt ...
Wenn Du schon eien forschleife machst, soltest Du statt der Wildcards "$MOUNTFOLDER/ELSendEx20*.txt einfach nur **$file* nehmen.
Irgendwie ist Deine Programmlogik nicht sauber.
lks
Das funktionierte mit GREP und GAWK nicht, es hat immer nur eine Zeile aus der Datei gegriffen, daher habe ich es bei ls nicht einmal probiert. Jetzt fügt es mir zwar eine Zeile (0D 0A) zu viel in die "$BACKUPFOLDER/heute.txt" zu viel ein aber damit kann ich gerade noch so leben. Beschäftige mich aber trotzdem damit, das da raus zu bekommen.
Wie ich programmiere ... frag lieber nicht. Ich versuche es erst mal zu verstehen.
EDIT: Nee anders Rueck$BACKUPDATE wird $BACKUPFOLDER/heute.txt an die $BACKUPFOLDER/letzte.txt zwei mal angefügt.
cat $BACKUPFOLDER/letzte.txt $BACKUPFOLDER/heute.txt > $BACKUPFOLDER/Rueck$BACKUPDATE.txt
Wie ich programmiere ... frag lieber nicht. Ich versuche es erst mal zu verstehen.
EDIT: Nee anders Rueck$BACKUPDATE wird $BACKUPFOLDER/heute.txt an die $BACKUPFOLDER/letzte.txt zwei mal angefügt.
cat $BACKUPFOLDER/letzte.txt $BACKUPFOLDER/heute.txt > $BACKUPFOLDER/Rueck$BACKUPDATE.txt
Hallo,
Es mag zwar Intelligent wirken nach möglichkeit alle Befehle in einer Zeile zu packen, aber das ist es nicht. Deine Vorgehensweise ist nicht dazu geeignet einen Fehler zu finden. Du solltest die Art wie du vorgehst aufbrechen bzw. in kleinere Schritte einpacken, dann wäre auch ein einfaches Debuggen deinerseits möglich.
Stelle zuerst fest welche Dateien im Ordner $MOUNTFOLDER/ enthalten sind und vor allem was die Dateien enthalten die du beabsichtigst zu bearbeiten. Nicht das einer deiner unerwünschten \r\n schon zu wirken beginnt. Danach kannst du dann dein erstes Grep laufen lassen und du schaust dir an was in der Datei $TOLKORUECK/Rueck$TODAY.txt nun tatsächlich drinsteht. Erst nachdem hier noch dein gewünschtes Resultat zu erkennen ist mit deinem nächsten Grep weitermachen. Beachte aber: dein verwendetes && zur Befehlsverkettung dürfte immer eine 0 zurückgeben da dein grep ja erfolgreich ausgeführt wird sofern kein Datenträgerfehler plötzlich vorliegt. Das sagt aber nichts über den Inhalt der neu erzeugten Dateien aus. Nutze z.B. Echo $? und IF .... then oder Schleifenstrukturen um deinen Einzeiler aufzubrechen. Siehe auch http://linuxcommand.org/wss0150.php. Und wenn du dann dir die Inhalte deiner erzeugten Dateien ($TOLKORUECK/Rueck$TODAY.txt, $MEGARUECK/Rueck$TODAY.txt, PLATZHALTERFUERDATEI) angeschaut hast (diekt nach der Erzeugung und du dir klar bist warum du einmal ein >> verwendet hast, dann solltest du sehen an welcher Stelle dir die \r\n eingepappt werden.
Es ist nicht alleine damit getan nur Einzeile zu schreiben, du musst die nach 6 Monaten aber auch entschlüßeln können. Daher nutzt man weniger Einzeiler als vielmehr Strukturietes Programmieren um die lesbarkeit für den Menschen zu erhöhen und Kommentare umd zu erklären was man den beabsichtigt. Zur erhöhung der lesbarkeit gehört aber auch das Module, Funktionen, usw. alle auf einer Bildschirmseite appsen sollen ohne zu Scrollen. Das ist teils aufwendiger und schwieriger als nur ein Einzeiler hinzuknallen und andere dazu zu verdonnern meinen Kartoffelsalat wieder in seine Ursprungsteile wieder zurück zu Verwandeln.
Gruß,
Peter
Es mag zwar Intelligent wirken nach möglichkeit alle Befehle in einer Zeile zu packen, aber das ist es nicht. Deine Vorgehensweise ist nicht dazu geeignet einen Fehler zu finden. Du solltest die Art wie du vorgehst aufbrechen bzw. in kleinere Schritte einpacken, dann wäre auch ein einfaches Debuggen deinerseits möglich.
Stelle zuerst fest welche Dateien im Ordner $MOUNTFOLDER/ enthalten sind und vor allem was die Dateien enthalten die du beabsichtigst zu bearbeiten. Nicht das einer deiner unerwünschten \r\n schon zu wirken beginnt. Danach kannst du dann dein erstes Grep laufen lassen und du schaust dir an was in der Datei $TOLKORUECK/Rueck$TODAY.txt nun tatsächlich drinsteht. Erst nachdem hier noch dein gewünschtes Resultat zu erkennen ist mit deinem nächsten Grep weitermachen. Beachte aber: dein verwendetes && zur Befehlsverkettung dürfte immer eine 0 zurückgeben da dein grep ja erfolgreich ausgeführt wird sofern kein Datenträgerfehler plötzlich vorliegt. Das sagt aber nichts über den Inhalt der neu erzeugten Dateien aus. Nutze z.B. Echo $? und IF .... then oder Schleifenstrukturen um deinen Einzeiler aufzubrechen. Siehe auch http://linuxcommand.org/wss0150.php. Und wenn du dann dir die Inhalte deiner erzeugten Dateien ($TOLKORUECK/Rueck$TODAY.txt, $MEGARUECK/Rueck$TODAY.txt, PLATZHALTERFUERDATEI) angeschaut hast (diekt nach der Erzeugung und du dir klar bist warum du einmal ein >> verwendet hast, dann solltest du sehen an welcher Stelle dir die \r\n eingepappt werden.
Es ist nicht alleine damit getan nur Einzeile zu schreiben, du musst die nach 6 Monaten aber auch entschlüßeln können. Daher nutzt man weniger Einzeiler als vielmehr Strukturietes Programmieren um die lesbarkeit für den Menschen zu erhöhen und Kommentare umd zu erklären was man den beabsichtigt. Zur erhöhung der lesbarkeit gehört aber auch das Module, Funktionen, usw. alle auf einer Bildschirmseite appsen sollen ohne zu Scrollen. Das ist teils aufwendiger und schwieriger als nur ein Einzeiler hinzuknallen und andere dazu zu verdonnern meinen Kartoffelsalat wieder in seine Ursprungsteile wieder zurück zu Verwandeln.
Jetzt wo ich eine Schleife gebastelt habe bekommen die Dateien am Ende zwei leerere Zeilen. Die Anzahl der Zeilen erhöht sich mit den Anzahl der Dateien im Verzeichnis.
Fehlersuche nennt sich ein Programm mit 1.000.000 Quellcodezeilen oder ein Bash Einzeiler zu entkäfern (Debuggen). Du kannst auch ein Bash Skript im Debug Modus laufen lassen. Wie? Schau hie mal rein http://tldp.org/LDP/Bash-Beginners-Guide/html/sect_02_03.html Die Anzahl der Zeilen erhöht sich mit den Anzahl der Dateien im Verzeichnis.Gruß,
Peter
Hi,
danke dir Peter. Für mich sollte es einfach nur ein kleiner Script sein welches ein paar Daten aus verschiedenen Daten welche Täglich immer wieder neu kommen, zuerst mit wesentlichem Inhalt an zwei verschiedenen Stellen zu verteilen und die viele Daten aus verschiedenen Dateien dann in eine zusammen zu fassen. Ich dachte es wird ein Sparziergang… Kurze Kommentare sind auch existent. Das was Ihr hier sieht ist nur ein bruchteil der Funktionen. Es währe alles viel einfacher, wenn die Dateien immer gleich heißen wirden, sind sie aber leider nicht.
Jetzt bin unter anderem dank dir und LKS zu verstehen, dass das was ich vor hatte etwas mehr ist als einfach nur ein cp und mv
So nun habe ich die Befehle auf einzelne Zeilen aufgeteilt. Und stellte fest, dass in der Schleife bei dem Befehl „cat $BACKUPFOLDER/letzte.txt $BACKUPFOLDER/heute.txt > $BACKUPFOLDER/Rueck$BACKUPDATE.txt“ die Datei „heute.txt“ so oft eingebunden wird wie es Dateien im Ordner „$MOUNTFOLDER/ELSendEx20*“ gefunden werden.
Daher habe ich die schleiffe an der Stelle getrent und eine zusätzliche Abfrage gestartet:
Es funktioniert. Aber Jetzt habe ich noch ein Problem. Da der Script jede Minute als Cronejob ausgefürt werden soll bekomme ich haufen E-Mails in der /var/spool/mail/root mit dem Inhalt:
Wie kann ich das unterbinden ohne die Datei selbst zu löschen?
danke dir Peter. Für mich sollte es einfach nur ein kleiner Script sein welches ein paar Daten aus verschiedenen Daten welche Täglich immer wieder neu kommen, zuerst mit wesentlichem Inhalt an zwei verschiedenen Stellen zu verteilen und die viele Daten aus verschiedenen Dateien dann in eine zusammen zu fassen. Ich dachte es wird ein Sparziergang… Kurze Kommentare sind auch existent. Das was Ihr hier sieht ist nur ein bruchteil der Funktionen. Es währe alles viel einfacher, wenn die Dateien immer gleich heißen wirden, sind sie aber leider nicht.
Jetzt bin unter anderem dank dir und LKS zu verstehen, dass das was ich vor hatte etwas mehr ist als einfach nur ein cp und mv
So nun habe ich die Befehle auf einzelne Zeilen aufgeteilt. Und stellte fest, dass in der Schleife bei dem Befehl „cat $BACKUPFOLDER/letzte.txt $BACKUPFOLDER/heute.txt > $BACKUPFOLDER/Rueck$BACKUPDATE.txt“ die Datei „heute.txt“ so oft eingebunden wird wie es Dateien im Ordner „$MOUNTFOLDER/ELSendEx20*“ gefunden werden.
for file in $MOUNTFOLDER/ELSendEx20*; do
if [ -f ${file} ] ; then
grep -a -h ';;;01;Lager;;;;' $MOUNTFOLDER/ELSendEx20*.txt > $TOLKORUECK/Rueck$TODAY.txt #Kopiert alle Zeilen mit dem Inhalt ;;;01;Lager;;;; (FUNKTIONIERT)
grep -a -h ';;;02;Biglager;;;;' $MOUNTFOLDER/ELSendEx20*.txt > $MEGARUECK/Rueck$TODAY.txt #Kopiert alle Zeilen mit dem Inhalt ;;;02;Biglager;;;; (FUNKTIONIERT)
ls $MOUNTFOLDER/ELSendEx20*.txt | xargs -l1 -I PLATZHALTERFUERDATEI echo 'echo -n -e "\r\n" >>PLATZHALTERFUERDATEI' | tee /root/echoscript.sh
source /root/echoscript.sh
rm -f /root/echoscript.sh
gawk -F: '{ print $0 }' $MOUNTFOLDER/ELSendEx20*.txt > $BACKUPFOLDER/heute.txt
mv $BACKUPFOLDER/Rueck$BACKUPDATE.txt $BACKUPFOLDER/letzte.txt
cat $BACKUPFOLDER/letzte.txt $BACKUPFOLDER/heute.txt > $BACKUPFOLDER/Rueck$BACKUPDATE.txt
rm -f $BACKUPFOLDER/letzte.txt
else
break
fi
doneDaher habe ich die schleiffe an der Stelle getrent und eine zusätzliche Abfrage gestartet:
[[ -f $BACKUPFOLDER/letzte.txt ]] && cat $BACKUPFOLDER/letzte.txt $BACKUPFOLDER/heute.txt > $BACKUPFOLDER/Rueck$BACKUPDATE.txt
rm -f $BACKUPFOLDER/letzte.txt
rm -f $MOUNTFOLDER/ELSendEx20*.txt || clearEs funktioniert. Aber Jetzt habe ich noch ein Problem. Da der Script jede Minute als Cronejob ausgefürt werden soll bekomme ich haufen E-Mails in der /var/spool/mail/root mit dem Inhalt:
TERM environment variable not set.
TERM environment variable not set.
echo -n -e "\r\n" >>/mnt/backup-tmp/ELSendEx20161228155502192.txt
echo -n -e "\r\n" >>/mnt/backup-tmp/ELSendEx20161228155502317.txt Zitat von @Pjordorf:
Hallo,
Es mag zwar Intelligent wirken nach möglichkeit alle Befehle in einer Zeile zu packen, aber das ist es nicht.
Hallo,
Es mag zwar Intelligent wirken nach möglichkeit alle Befehle in einer Zeile zu packen, aber das ist es nicht.
Genauer geasgt: Einzeiler nimmt man für "one-time-shots", als für Fälle, die man nur ein einiges Mal braucht und dann nicht mehr. Da ist es dann unerheblich, ob man die Logik später nochmal versteht oder nicht.
Für cronjobs oder wiederkehrende Aufgaben gibt man sich (hoffentlich) mehr Mühe und schaut, daß man sie selbst in 5 Jahren imemr noch nachvollziehen kann.
lks
Jup das habt Ihr mir verständlich gemacht
Aber wie lasse ich die Nachrichten verschwinden?
Aber wie lasse ich die Nachrichten verschwinden?
Moin,
Entweder die Ausgabe des Cronjobs in /dev/null oder eine logdatei leiten, z.B. mit
1 2 3 * * /usr/local/cronscripts/cron-script-1.sh >>/var/log/cron-script-1.log
4 5 6 * * /usr/local/cronscripts/cron-script-2.sh >/dev/null
lks
DAAANKE! habe auch gerade das gefunden.
http://www.sysadminslife.com/linux/quicktipp-cron-daemon-mails-deaktivi ...
Vielen lieben Dank.
Andere Frage, würdet Ihr an dem Script etwas ändern? Würdet Ihr das anders schreiben?
http://www.sysadminslife.com/linux/quicktipp-cron-daemon-mails-deaktivi ...
Vielen lieben Dank.
Andere Frage, würdet Ihr an dem Script etwas ändern? Würdet Ihr das anders schreiben?
