Was macht "cron" anders??????

Ice

Ice

Well-Known Member
Hi all,

Ich habe ein kleines Problemchen mit cron. Ist zwar kein BSD-System, aber ich hoffe ihr verzeiht mir, dass ich das hier trotzdem poste.

Ich habe ein kleines Skript geschrieben, das mir die aktuellen Virenkennungen für Sophos, abhängig von der Version, aus dem Web runterladen soll. Dazu verwende ich folgenden Mechanismus:
Code: 
VERSION=`/usr/local/bin/sweep -V|grep Produktversion|awk '{ print $3 }'|awk -F . '{ print $1 $2 }'`_ides.zip

/usr/bin/wget http://www.sophos.com/downloads/ide/$VERSION
Das Skript läuft bei manuellem Start absolut einwandfrei!
Der Download-Link wird dann z.B.
Code: 
/usr/bin/wget [url]http://www.sophos.com/downloads/ide/381_ides.zip[/url]
Wenn ich das Skript jedoch als cronjob laufenlasse, funktioniert die Zuweisung der Variable VERSION offensichtlich nicht.
Als Download-Adresse in der zweiten Zeile kommt dann folgender Link raus:
Code: 
/usr/bin/wget [url]http://www.sophos.com/downloads/ide/_ides.zip[/url]
der natürlich nicht funktioniert!

Das Skript läuft sowohl manuell als auch als cronjob mit der gleichen UID und der gleichen shell.

Hat jemand eine Idee, was der crond da anders macht??????

Thx,

Ice
 
Da wir nicht wissen, wo awk und grep auf dem Zielsystem liegen und welche Pfade der Cron setzt, kann man auf $PATH nur spekulieren, was aber sicher schon ein guter Ansatzpunkt ist.

Wenn man sich also auf Pfade verläßt, sollte man den $PATH am besten im Skript selbst auf das setzen, was man erwartet. Ansonsten kann man natürlich auch die PATH-Zuweisung in der Crontab ändern, was dann aber wiederum eine Anpassung auf jedem Rechner, auf dem das Skript laufen soll, zur Folge hätte.

Alternativ kann man auch mit dem absoluten Pfadnamen arbeiten. Nicht nur über den direkten Aufruf sondern beispielsweise auch mittels:
Code: 
AWK_CMD=/usr/bin/awk
[...]
[...]   ${AWK_CMD} '{ print $3 }'   [...]
Das ist dann brauchbar, wenn man den Aufruf öfters braucht oder in einem case-Konstrukt vor der eigentlichen Ausführung noch auf einen plattformabhängigen String setzt (für Skripte, die auf mehreren Plattformen laufen sollen).
 
Erstmal Danke an Alle für die Antworten!

Auf den Pfad hatte ich auch schon getippt! Kann es aber eigentlich nicht sein, denn

1. PATH=/sbin:/bin:/usr/sbin:/usr/bin steht in der crontab und grep&awk liegen in /bin
2. Dann müsste das Skript eine Fehlermeldung nach dem Motto "no such file..."
3. In /var/log/cron tauchen keinerlei Fehlermeldungen auf

Ich habe trotzdem mal den absoluten Pfad überall eingesetzt, aber es ändert sich leider nichts!!! Hab langsam echt keine Idee mehr, was da schief läuft. Glaube so langsam wirklich an einen Bug im Linux cron! Es handelt sich nämlich um ein RedHat 7.1 System.... ;)

Gruß,

Ice
 
Hast du ein #!/bin/sh am Anfang? Sonst kann es gut sein, dass du manuell mit einer anderen Shell das Teil startest als cron das tut.

alternativ:
The -F fs option defines the input field separator to be the regular expression fs.
Zum Vergrößern anklicken....
und du sagst '.', also egal was für ein Zeichen, was mich allerdings doch wieder verwundert, da es ja im einen Fall zu funktionieren scheint.

Zudem ist "awk" in deinem fall etwas übertrieben, "cut" wäre eher die Waffe der Wahl.
 
Auf was stehen die LC_* Variablen? Ist /usr/local/bin/sweep ein "deutsches" Programm? Vielleicht gibt es bei ungesetzten LC_* Variablen nicht 'Produktversion' aus, sondern 'product version'....
 
@Tron

Das Skript läuft in beiden Fällen in der bash. Deshlab steht am Anfang des Skriptes #!/bin/bash

Als Field Separator benutze ich in diesem speziellen Fall tatsächlich den Punkt selbst, was auch einwandfrei funktioniert. Die Ausgabe des Sweep-Kommandos gibt 3.81 zurück - durch awk wird daraus dann 381, was zu dem gewünschten Filename führt.

Ich habe früher auch oft "cat" verwendet. Nachdem ich damit aber immer wieder mal in Fehler und Probleme gestolpert bin, benutze ich jetzt lieber "awk" auch wenn es etwas überdimensioniert ist.

Es wäre allerdings tatsächlich mal interessant, ob das Problem bei Verwendung von "cut" auch auftaucht. Werde ich mal ausprobieren!

@MrFixit

Auch eine gute Idee, aber dann dürfte ja das Skript bei manueller Ausführung auch nicht funktionieren, oder?????
Ich denke mal, dass die env-Variablen für einen User gleich sind, egeal ob per cron oder manuell, oder????
Werde das aber ebenfalls nochmal überprüfen.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben