wc -w funktioniert plötzlich nicht mehr mit backticks

[framp]

P.S. Warum muss der FILECNT durch 9 geteilt werden?

Weil ls -l folgene Informationen für eine Datei anzeigt:

-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.

 

[Erdös]

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.

 

[susejunky]

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.

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.