Bash Script in Cron läuft nur teilweise

  • Sehe ich auch so. Lieber:

    Code
    pip install -U git+https://github.com/sivel/speedtest-cli.git

    Wenn dein PIP neu genug ist um aus Git-Repositories zu installieren, versteht es auch -U.

    Wenn ihr schnell hilfreiche Antworten wollt, lest bitte diesen Artikel (Fehlerberichte - wie Sie Softwarefehler melden sollten) und beherzigt die darin enthaltenen Ratschläge. Herzlichen Dank!

  • sudo und pip zusammen ist nie eine gute Idee.

    Acha, und warum nicht? :conf:


    Ohne sudo bzw mit -U wird sein Problem nicht so leicht behoben ... Der Installationsort ist dann nämlich /home/pi/.local/bin/speedtest-cli

    Da wird also wieder ein Rattenschwanz nötig, da die Umgebungsvariablen von Cron eher minimalistisch sind.

    Wie gestern auch schon erwähnt: Warum kompliziert wenns auch einfach geht :-/

  • Acha, und warum nicht? :conf:

    Weil man als Superuser natürlich das System global "verschmutzt". Zugegeben, wenn das jetzt ein Rezept wäre welches mit Ansible oder Chef appliziert wird, würde ich auch mehrfach überlegen ob ich nicht lieber PIP als Superuser ausführe.

    Allerdings verstehe ich dein Gegenargument nicht, da wir ja nicht alle Details kennen (oder?). Man müßte doch erstmal mit env in der crontab eruieren, ob denn /usr/local/bin im Standardpfad liegt. Ist dies der Fall hast du allerdings unumwunden recht.

    Wahrscheinlich ist es für Bastelprojekte ohnehin wumpe. Aber da ich Linux nicht nur als Bastler einsetze, habe ich da, wie scheinbar auch Linus, andere Ansprüche.

    Wenn ihr schnell hilfreiche Antworten wollt, lest bitte diesen Artikel (Fehlerberichte - wie Sie Softwarefehler melden sollten) und beherzigt die darin enthaltenen Ratschläge. Herzlichen Dank!

  • Acha, und warum nicht?

    Hab ich schon zig mal erklärt und lässt sich im Internet nachlesen. Es gibt in der Python-Community eben gewisse Standards, an die man sich halten möchte ( noisefloor: der TE will sich daran halten ;)).

    Kurz und gut, tut was ihr nicht lassen könnt, aber eigentlich pfuscht man nicht mit sudo irgendwelche Pakete in seine Systeminstallation von Python. Es gibt nicht umsonst eine per-User Installation und Virtualenvs. Wie wär's mit einem Symlink, ist das keine Option?

  • Aber da ich Linux nicht nur als Bastler einsetze, habe ich da, wie scheinbar auch linusg, andere Ansprüche.

    Absolut. Zum Beispiel eine gut reproduzierbare Entwicklungsumgebung, versucht mal mit dem pip freeze eurer Python-Systeminstallation mit draufgeklatschten Paketen was anzufangen :wink:

    Außerdem kann ich mir mit Virtualenvs genaustens die Versionen der Pakete aussuchen und den Python-Interpreter, der das ganze powert, und das für jedes Projekt einzeln.

    Aber die Erfahrungen damit muss man einfach mal gemacht haben, sonst diskutieren wir wieder ewig aneinander vorbei, a la "das ist doch wieder einer von den unter Programmierern ach so beliebten Glaubenskriegen" :2cents:

  • :warn:

    Es geht hier nicht um pyenv sondern um PATH der Shell

    Seine Crontab ruft ein Bash-Script auf, welches infolgedessen speedtest-cli ebenfalls über bash ausführt. Erst speedtest-cli ist ein Python-Script - aber bevor das nicht "gefunden wurde" kann es auch nichts aus dem pyenv laden.

    Es gilt zu unterscheiden: Python Module/Paket und Python-Script!

    Es ist davon auszugehen dass der TE nichts an den Umgebungsvariablen von Cron verändert hat - impliziert durch "nicht wissen wie 'command not found' zu lösen geht". Demnach gilt die Standard Einstellung: /usr/bin:/bin

    Wie er PATH anpassen kann, oder welche Möglichkeiten es noch gibt, wurde ihm zum Ende von Seite 1 ausführlich beschrieben.

  • Ganz einfach in dem Bash-File, indem der ganze Kram aufgerufen wird, die Pfade zud en aufgerufenen Programme in eine PATH-Variable für genau diese Shell-Umgebung setzten.

    ------------

    Wenn man in einem Crontab-Aufruf, wenigstens für die ersten Tests, die Standard- und Fehlerausgabe nicht gleich nach /dev/null umleitet, sondern in jeweils eine Datei, kann man sehen, warum etwas nicht so läuft, wie es laufen soll.

    Computer ..... grrrrrr

  • Hätte ja nicht gedacht, dass eine solche Frage zu solchen Diskussionen führt. :)

    Aber völlig richtig, ich würde gerne möglichst sauber anfangen und möglichst die "ordentliche" Variante lernen und gleich verinnerlichen. Für mich sind alle Betriebssysteme mit GUI eigentlich kein Problem, aber quasi reines CLI ist schon was anderes.

    An den Cronvariablen habe ich nichts geändert. Wüsste gar nicht wie ich das mache. ;)

    Also für alle Hilfestellungen könnt ihr von einem jungfräulichen Raspberry ausgehen.

    Ich würde jetzt speedtest-cli und speedtest-cli-extras einfach folgendermaßen installieren:

    pip install -U git+https://github.com/sivel/speedtest-cli.git

    und anschließend:

    git clone https://github.com/HenrikBengtsson/speedtest-cli-extras.git

    Müsste ich danach noch speedtest-cli-extras nach /home/pi/.local/bin/ verschieben?

    Tut mir echt leid für die vielen Anfängerfragen, jedoch habe ich mal mit PHP angefangen und dort nicht von Anfang mit EVA gearbeitet, was letztlich zu Chaos und mühsamen Umlernen geführt hat. Deswegen lieber jetzt gleich richtig, ohne dass ich irgendwelche "klassischen" Arbeitsweisen ignoriere.

    Grüße

  • Leider spann die Forensoftware beim Zitieren. Also Pardon, daß es nicht so schick aussieht wie es sollte.

    Zitat

    Es geht hier nicht um pyenv sondern um PATH der Shell

    Das war schon klar. Wobei ja das besagte "Wrapper-Skript" mit absolutem Pfad aufgerufen werden kann und daher selbst PATH modifizieren und exportieren kann, bevor es speedtest-cli ausführt.

    Zitat

    das nicht "gefunden wurde" kann es auch nichts aus dem pyenv laden.

    Es gilt zu unterscheiden: Python Module/Paket und Python-Script!

    Ich denke du hast mißverstanden worauf ich hinauswollte. Also nehmen wir mal ganz keck an, daß pyenv lokal im Homeverzeichnis installiert ist (im Standardpfad ~/.pyenv). Nun kannst du pyenv bekanntlich dadurch aktivieren, daß du die Ausgabe von "pyenv init" und "pyenv virtualenv-init" in Bash sourcst. Genau das meinte ich. Grob gesagt (in Bash), gefolgt dann von der Auswahl der jeweiligen Pythonversion:

    Code
    if [[ -x "$HOME/.pyenv/bin/pyenv" ]]; then
        export PATH="$HOME/.pyenv/bin:$PATH"
        eval "$(pyenv init -)"
        eval "$(pyenv virtualenv-init -)"
    fi
    Zitat

    Es ist davon auszugehen dass der TE nichts an den Umgebungsvariablen von Cron verändert hat - impliziert durch "nicht wissen wie 'command not found' zu lösen geht". Demnach gilt die Standard Einstellung: /usr/bin:/bin

    Genau, daher mein Hinweis mit /usr/local/bin ... wobei natürlich je nach Shell in Cron und je nach globalem Profil der Shell auch andere Regeln gelten könnten. Ich würde aber in jedem Fall auf Nummer sicher gehen.

    Aber ich hab ohnehin schon das Gefühl, daß wir auf's gleiche hinauswollen und den TE mittlerweile mit unserer Detaildiskussion eher verwirren ;)

    Wenn ihr schnell hilfreiche Antworten wollt, lest bitte diesen Artikel (Fehlerberichte - wie Sie Softwarefehler melden sollten) und beherzigt die darin enthaltenen Ratschläge. Herzlichen Dank!

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!