Bash Script in Cron läuft nur teilweise
-
xorem -
30. November 2017 um 13:17 -
Erledigt
-
-
Bash Script in Cron läuft nur teilweise? Schau mal ob du hier fündig wirst!
-
sudo und pip zusammen ist nie eine gute Idee.
Acha, und warum nicht?
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?
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.
-
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
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"
-
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.
-
Rasp-Berlin das wurde bereits in Beitrag#2 und Beitrag#16 erwähnt.
-
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.
ZitatEs 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.
Zitatdas 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:
Codeif [[ -x "$HOME/.pyenv/bin/pyenv" ]]; then export PATH="$HOME/.pyenv/bin:$PATH" eval "$(pyenv init -)" eval "$(pyenv virtualenv-init -)" fi
ZitatEs 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
-
Jetzt mitmachen!
Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!