• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

wc -w funktioniert plötzlich nicht mehr mit backticks

Erdös schrieb:
P.S. Warum muss der FILECNT durch 9 geteilt werden?
Zum Vergrößern anklicken....
Weil ls -l folgene Informationen für eine Datei anzeigt:
Code: 
-rw-rw-r-- 1 framp framp   4950 May 21 13:27 Makefile
und das sind 9 durch Leerzeichen getrennte Worte die mit wc -w gezählt werden. Siehe auch die Beispiele von @susejunky : Er hat 4 Dateien und der Count 36 wird zurückgeliefert.

Wenn Dir in Deinem Code aber wirklich die korrekte Anzahl Dateien geliefert wird - was passiert wenn Du ls -1 nimmst, kann ich daraus nur vermuten dass das Ausgabeformat von ls -l durch irgendeine Einstellung nur den Dateinamen zurückliefert. Der Einwand von @susejunky zu Dateinamen mit Leerzeichen ist natürlich auch zu berücksictigen.

Die Backticks funktionieren zu 100%. Ansonsten würde sich wohl auf dem System kein Rad mehr drehen.

Ich sehe es so wie @josef-wien in Punkt 2. Du musst auf dem Produktionssystem debuggen. Alles andere ist Satzleserei und Du wirst kaum Erfolg haben. Ist es denn wirklich nicht möglich ein einfaches xxd <<< "$FILES" >> /var/log/debugMe an der entsprechenden Stelle einzubauen? Dadurch wird defintiv die Funktionalität des Codes nicht geändert.
 
Ja, danke, der ls ist "ls -1..." und das funktioniert alles, die $FILES sind auch nicht das Problem, das funktioniert - leider - alles, auch auf dem Server wo der Fehler mit "FILECNT=`echo $FILES | wc -w* auftritt und in dem FILECNT steht defintiv nichts drin, da nützt mir auch kein Hexaldump.
Nein, da wo der Fehler auftritt kann ich nicht so ohne weiteres Testen, das Skript muss funktionsfähig aus Annahme nach Produktion gehen, weil das Skript Ausgaben erzeugt, die sofort zum externen Provider gehen und das zu unterdrücken ist ein ziemlicher Aufwand.
Ich werde das schon irgendwie lösen, das Skript ohne diesen merkwürdigen Count zu erstellen ist nicht das Problem, das mache ich alle Tage.
Nur - ich wiederhole mich - eigentlich läuft das seit ca. 13 Jahren und wenn da irgendetwas plötzlich anders funktioniert, hat das vielleicht Auswirkungen auch auf andere Skripte, deswegen würde ich die Ursache gern kennen.
 
Erdös schrieb:
eigentlich läuft das seit ca. 13 Jahren und wenn da irgendetwas plötzlich anders funktioniert, hat das vielleicht Auswirkungen auch auf andere Skripte, deswegen würde ich die Ursache gern kennen.
Zum Vergrößern anklicken....
In den vorangegangenen Beiträgen wurden Dir doch die zwei Bereiche aufgezeigt, welche die Problemursache beherbergen könnten:
  1. Änderungen in den eingesetzten Softwareversionen und/oder Abweichungen in den Softwareständen zwischen Produktiv- und Testsystem.
  2. Mängel im Skript (siehe Beitrag #16).
zu 1.)
Ohne konkrete Informationen über die eingesetzten Softwarestände und ggf. den Aktualisierungsverlauf kann man Dir diesbezüglich nicht weiter helfen (und Du bist ohnehin der Ansicht, dass das nicht die Ursache des Problems sein kann).

zu 2.)
Das Beispiel in Beitrag #16 zeigt, dass das Skript (soweit Du es hier zugänglich gemacht hast) an Dateinamen, welche Leerzeichen enthalten, scheitern würde. Dass dieser Sachverhalt bislang (13 Jahre ?) unentdeckt geblieben ist, könnte sich dadurch erklären lassen, dass die Testdaten, die Du auf Deinem Testsystem verwendest, keine Dateinamen mit Leerzeichen beinhalten.

Ich will damit nicht sagen, dass Dateinamen mit Leerzeichen die Ursache für das aktuelle Versagen des Skripts darstellen. Aber ich halte es durchaus für möglich, dass das Skript noch weitere implizite Annahmen (wie z.B. Dateinamen beinhalten keine Leerzeichen) bezüglich der zu verarbeitenden Daten trifft und dass diese Annahmen nach 13 Jahren nicht mehr zutreffen, was dann zu einem Scheitern des Skripts führt. Dass das Skript bis vor kurzem sowohl auf dem Produktiv- als auch auf dem Testsystem problemlos lief, kann daher kommen, dass die verwendeten Testdaten eben nicht alle Fälle der aktuell im Wirkbetrieb anfallenden Daten abdecken.

Um es etwas verständlicher zu machen hier ein kleines Beispiel "aus meinem Nähkästchen":

Bei einem Kunden war seit Anfang 1990 ein System in Betrieb (klaglos), welches Mitte Januar 2000 plötzlich Probleme verursachte. Die Analyse ergab, dass an einer Stelle im Programm eine 10-stellige Kundennummer auf Gültigkeit geprüft werden sollte und die Prüfung bestand in der Auswertung der letzten beiden Ziffern der Kundennummer, welche das Jahr, in dem der Kunde zum Kunden geworden war, abbildeten. Da das Unternehmen seit 1985 tätig war, sollte die Gültigkeit einer Kundennummer dadurch festgestellt werden, dass die letzten beiden Ziffern einen Wert >=85 ergaben (wurde vom Kunden so spezifiziert und vom Softwareersteller gemäß Spezifikation realisiert). Das funktionierte 10 Jahre wunderbar bis dann der erste neue Kunde im Januar 2000 erfasst wurde.

Um solche Fälle oder eben den in Beitrag #16 beschriebene zu erkennen, muss
  • bekannt sein, welche Funktionalität durch den Programmcode abgedeckt werden soll (Spezifikation),
  • der Programmcode analysiert; d.h. mit der Spezifikation abgeglichen werden und dann
  • unter Verwendung von Testdaten, die möglichst alle je im Wirkbetrieb zu erwartenden Datenkonstellationen abdecken, überprüft werden.
Das Alles ist Dir sicherlich bereits bekannt, da das Erstellen komplexer Skripte Dein "täglich Brot" ist. Du musst es jetzt eben nur noch umsetzen. Ich denke viele Forumsmitglieder (mich eingeschlossen) würden Dich dabei gerne unterstützen. Aber ohne das Skript vollständig zu kennen und ohne zu wissen, was das Skript leisten soll (Spezifikation) ist das kaum möglich.
 
Vielen Dank für die ausführliche Antwort, aber alles was mir als Anwendungsentwickler zugänglich ist, funktioniert ja, das ist das Problem!
Es ist derselbe Code, der auf dem einen Environment (MMWBATCH02), auf dem er 13 Jahre fehlerfrei gelaufen ist, jetzt fehlerhaft läuft, in Produktion auf einer andere Maschine ( MMWBATCH01) als Verlegenheitslösung jetzt provisorisch fehlerfrei in Betrieb und im Test sowieso, wobei die Administration behauptet, alles ist identisch.
Es schwebt die die Befürchtung im Raum, dass das was auf dem einen Rechner unbekannterweise zu dem Fehler führt und bis jetzt keiner kennt, irgendwann auch auf dem aktiv wird und dann isses zappenduster.
Ich mal Laufprotokolle zur Illustration angefügt, man sieht im einen Fall das hinter "Anzahl Files:" nichts steht, was zu dem Syntaxfehler in der if-Abfrage führt, im anderen Fall eben die Anzahl der aufgelisteten Files, die dann verarbeitet werden, im fehlerhaften Fall allerdings ohne die in der if-Abfrage vorgesehen Bearbeitung,
Die kritischen Stellen sind in der Hardcopy gelb markiert.
Ich gebe jedem Recht, der sagt, dass das nicht sein kann - ich werde aber nicht nachlassen, da trotzdem weiter zu recherchieren.
Leider ist mir als kleinem externen Anwendungsentwickler nicht jeder Zugang zum Environment möglich, deswegen werde ich vermutlich einfach den alten Code anpassen müssen.
Es ist nicht das erste Mal, dass ich erlebe, dass in diesem komplexen Systemen heutzutage eine Fehler erzeugende Konfiguration nicht zu analysieren war,
 

Anhänge

Erdös schrieb:
in dem FILECNT steht defintiv nichts drin, da nützt mir auch kein Hexaldump.
Zum Vergrößern anklicken....
Ich habe mal versucht zu erreichen dass in FILECNT nichts drinsteht. Leider kein Erfolg. wc liefert immer eine Zahl zurück.

Code: 
framp@majestix:~/test$ cat ticks.sh
#!/bin/bash
#
set -eo pipefail

cnt() {
    echo "-> $1 <-"
    FILES=`$1`
    FILECNT=`echo $FILES | wc -w`
    echo "FILES: $FILES"
    echo "FILECNT: $FILECNT"
}

cnt "ls -1 *.sh"
cnt ""
cnt $DUMMY
CHINESE="世界＋你好"
cnt "echo $CHINESE"

#Add BOM to the new file
printf '\xEF\xBB\xBF' > with_bom.txt
# Append the content of the source file to the new file
echo "世界＋你好" >> with_bom.txt
cnt "echo $(<with_bom.txt)"

framp@majestix:~/test$ ./ticks.sh
-> ls -1 *.sh <-
FILES: mwe.sh
ticks.sh
FILECNT: 2
->  <-
FILES:
FILECNT: 0
->  <-
FILES:
FILECNT: 0
-> echo 世界＋你好 <-
FILES: 世界＋你好
FILECNT: 1
-> echo 世界＋你好 <-
FILES: 世界＋你好
FILECNT: 1

Deshalb bin ich nicht davon überzeugt dass da nichts drinsteht.

Code: 
//mmwsrv01/anwendungen$/BATCH/SEPA/concatxml_mc.sh: Zeile 38: [: 26: Einstelliger (unärer) Operator erwartet.

Wie sieht denn die Codezeile 38 in concatxml_mc.sh aus?
 
Ich habe es auch nicht geschafft, mit dem Code des Skripts mit FILECNT=`echo $FILES | wc -w` etwas anderes in $FILECNT zu bekommen als ungünstigstenfalls 0. Das ist ja, wenn alles korrekt funktioniert, auch der Wert, wenn wc in dem übergebenen String nichts findet - also auf jeden Fall ein numerischer Wert, auch "Zahl" genannt.
Es kommt aber in dem Fehlerfall offenbar etwas anderes zurück: nach meinem Eindruck ein Blank oder auch Low Value - das kann ich nicht checken, weil ich auf den Prod-Server keinen Zugang habe.
Auf jeden Fall kommt etwas zurück, was die Zeile 38: "then if [ $COUNTER != $FILECNT ] so zusammenschiebt, dass die Meldung mit dem fehlenden unären Operator geworfen wird.
Ich habe das im Test damit erreicht, dass ich hart ein Blank in den $FILECNT geschoben habe,. Also liegt die Vermutung nahe, dass auch aus FILECNT=`echo $FILES | wc -w` auch ein Blank kommt. Fest steht aber, dass aus dieser Zuweisung schon mal keine Zahl kommt, dann dann würde die if-Abfrage als syntaktisch korrekt interpretiert.
Das legt aber die Vermutung nahe, dass, wenn man annimmt, dass wc immer ein Zahl liefert, die Zuweisung über die backticks nicht richtig funktioniert, das würd erklären, dass der $FILECNT leer ist.
Ich kann mir auch schwer vorstellen, dass die backtick-Zuweisung "nicht mehr" funktioniert, ich nutze die auch standardmäßig bei basename- oder date-Zuweisungen, aber es sieht in diesem speziellen Fall einfach so aus, so daß für mich die Frage entstand, wodurch könnte das beeinflusst werden ?
 
Erdös schrieb:
Die kritischen Stellen sind in der Hardcopy gelb markiert.
Zum Vergrößern anklicken....
Ich habe mir Deinen Code-Ausschnitt einmal angesehen und mit den Log-Ausgaben, die im Erfolgsfall erzeugt werden, abgeglichen.

Meines Erachtens passen der von Dir gezeigte Code und die Log-Ausgaben nicht wirklich zusammen (siehe beiliegenden Datei). Aber ich denke es ist besser, wenn ich jetzt an die Forumsmitglieder mit mehr Programmiererfahrung abgebe.
 

Anhänge

Du hast Recht, der Code ist etwas anders, weil der aus meiner Testversion ist - dort habe ich zum Nachgucken den cat eingebaut, den es in echt nicht gibt und die "Anzahl Files..." -Ausgabe entfernt, weil ich im Test dort einiges zur Kontrolle ausgegeben habe. Die entscheidenden Stellen sind aber unverändert.
Anbei eine Hardcopy die zu den SYSOUTS passt, fall es noch interessiert...
 

Anhänge

  • 18527358.png
    18527358.png
    54,7 KB · Aufrufe: 8
...aber nochmal zur Verdeutlichung: es ist an dem Skript nirgends nicht etwas geändert worden, es ist seit ca. dreizehn Jahren problemlos gelaufen, auch wenn es mir vom Coding her nicht gefällt und läuft auch auf allen Environments weiter. Daher lautet die Frage, was ist möglicherweise am Environment, auf dem es nicht nicht mehr korrekt läuft, anders geworden, dass dieser Subprozess mit dem Gravis plötzlich keine Zahl mehr liefert.
 
framp schrieb:
Code: 
//mmwsrv01/anwendungen$/BATCH/SEPA/concatxml_mc.sh: Zeile 38: [: 26: Einstelliger (unärer) Operator erwartet.

Wie sieht denn die Codezeile 38 in concatxml_mc.sh aus?
Zum Vergrößern anklicken....
?

Wie @susejunky schon schreibt: Dein Code passt nicht zu den Logausgaben :-(

Noch ein paar Dinge die mir als Ursache in den Kopf kommen:
1) Ist das Testsystem ein Clone des Prodsystems? Ansonsten kannst Du nicht sicher sein dass Du dieselben Bedingunegn hast.
2) Wird derselbe Nutzer genommen um das Script aufzurufen?
3) Werden dieselben Language Settings genommen?
4) Sind alle globalen bash Settings identisch zwischen Test und Prod?
 
Ja in diese Richtung gingen meine Vermutungen auch, aber wie framp schreibt nutzt wc keinen IFS, Und selbst wenn würde/müsste es 0 zurückliefern Genauso wie die Verwendung auf einen String statt auf eine File nicht der reinen Lehre entspricht, aber doch immer funktioniert hat. Die nicht-numerische Ausgabe, die das Probelm verursacht, sieht nicht nach wc aus.
Die übrigen Fragen kann ich so aus dem Stand nicht beantworten, weil ich von zu Hause aus nicht auf den Prod-Rechner komme, dazu muss ich mich bei jemandem mit Admin-Rechten auf den Schoß setzen - aber diese behaupten ja, das alles gleich ist und bei den settings, die ich bisher angefragt und überprüft habe , war das auch der Fall. Deswegen wäre es schön zu wissen, welche settings genau inspiziert werden müssen, weil sie verdächtigt werden können, genau auf diese Kommandos Einfluss zu haben. Irgendetwas muss sich ja letzte Woche kurz vor dem ersten Auftreten des Problems geändert haben oder geändert worden sein, was von niemandem in dieser Hinsicht ernst genommen wurde. Man wird wohl nicht umhin kommen, alles durchzuflöhen, weil, wie schon geschrieben, möglicherweise auch andere Skripte betroffen sein könnten.
Die Zeile 38 ist meiner letzten Hardcopy numeriert sichtbar, das ist die Zeile mit der nicht funktionierenden If-Abfrage.
 
Danke für den Hinweis, das kann ich erst morgen überprüfen (lassen) - das würde mich zwar wundern, aber möglich ist alles.

Von außen betrachtet weist einiges darauf hin, dass im Zuge der Einspielung der neuen sentinelone-Version irgendetwas umparametrisiert wurde, dessen Nebeneffekte man nicht beachtet hat oder nicht kannte.
Ich habe mit diesen Virenscannern keine Erfahrung, aber man kennt das ja z.B seinerzeit aus der PL/1-Welt, wo beim neuen Enterprise-Compiler die Registerkonventionen umgestellt wurden und plötzlich die alten Programme sich völlig anders verhielten.
 
Ja, danke für den Hinweis.
Das Problem hängt aber offenbar mit der cygwin-Installation zusammen, weniger mit dem Linux.
Da bin ich soweiso erstmal überfragt., man findet im Internet aber Kollegen, die damit schon Probleme hatten.
 
Erdös schrieb:
Das Problem hängt aber offenbar mit der cygwin-Installation zusammen
Zum Vergrößern anklicken....
Wo wird cygwin eingesetzt? Auf dem Produktiv- oder auf dem Testsystem oder auf beiden?

Wenn (auf dem Produktivsystem) schon unbedingt MS Windows eingesetzt werden muss, warum nutzt man dann nicht eine Lösung mittels VBScript oder setzt WSL ein?

Und wenn das Produktivsystem unter einer Linux-Variante läuft, warum setzt Du dann als Testsystem nicht auch Linux ein? Wenn Du unbeding MS Windows auf Deinem Testrechner benötigst, dann könntest Du entweder WSL oder eine VM mit Linux nutzen oder eine Dual-Boot-Installation MS Windows mit einer Linux-Distribution oder ein Linux-LIVE-System von einem externen Datenträger.
 
Ich kann überhaupt nichts einsetzen, weil dafür andere zuständig sind, ich muss mit dem arbeiten und mich herumärgern, was ich hier vorfinde - es handelt sich um eine riesige Zahlungsverkehrsanwendung bei einer Bank -und das Skript ist wie schon mehrfach von mir erwähnt vor 13 Jahren von einem Kollegen geschrieben worden, der über alle Berge ist und sich auch nicht ausgesucht hat, mit welcher Software er arbeitet..
Wenn ich früher gewusst hätte, dass da etwas unter Windows (nur in dieser speziell Prod-Umgebung, das ist nicht die einzige) läuft, hätte ich den Fehler sofort zumindest vermutet und auch gefunden - mit den \r\n-Kombinationen aus Windows-Files ärgere ich mich hier schon herum seit ich hier arbeite, ich merke das bloß nicht mehr so oft, weil ich in meinen Skripts die \r standardmäßig überall sofort entferne.
In diesem Fall ist wohl - genau weiß ich es noch nicht - wohl die Steuerung in diesem cygwin verloren gegangen, die die Carriage-Returns unterdrückt, so dass die Varaiablen offenbar eine \r\n-Kombination am Ende haben und da der \r interpretiert wird, die Variable dann verschwindet.
Wenn man es nachstellt - aber wenn man es weiß ist es trivial - sieht das so aus :
1751292961330.png
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben