python: zmień katalog roboczy skryptów na własny katalog skryptu

Co minutę uruchamiam powłokę Pythona z crontaba:

* * * * * /home/udi/foo/bar.py

/home/udi/fooma pewne niezbędne podkatalogi, takie jak /home/udi/foo/logi /home/udi/foo/config, do którego /home/udi/foo/bar.pyodwołuje się.

Problem polega na tym, że crontaburuchamia skrypt z innego katalogu roboczego, więc próba otwarcia ./log/bar.logkończy się niepowodzeniem.

Czy istnieje dobry sposób, aby powiedzieć skryptowi, aby zmienił katalog roboczy na własny katalog skryptu? Spodobało mi się rozwiązanie, które działałoby dla dowolnej lokalizacji skryptu, zamiast wyraźnie wskazywać skryptowi, gdzie on się znajduje.

EDYTOWAĆ:

os.chdir(os.path.dirname(sys.argv[0]))

Było najbardziej kompaktowym, eleganckim rozwiązaniem. Dziękuję za odpowiedzi i wyjaśnienia!

Spowoduje to zmianę bieżącego katalogu roboczego na tak, aby otwieranie ścieżek względnych działało:

import os
os.chdir("/home/udi/foo")

Jednak zapytałeś, jak przejść do dowolnego katalogu, w którym znajduje się skrypt Pythona, nawet jeśli nie wiesz, który to będzie katalog podczas pisania skryptu. Aby to zrobić, możesz użyć os.pathfunkcji:

import os

abspath = os.path.abspath(__file__)
dname = os.path.dirname(abspath)
os.chdir(dname)

Pobiera nazwę pliku skryptu, konwertuje go na ścieżkę bezwzględną, następnie wyodrębnia katalog z tej ścieżki, a następnie przechodzi do tego katalogu.

Możesz uzyskać krótszą wersję, używając sys.path[0].

os.chdir(sys.path[0])

Z http://docs.python.org/library/sys.html#sys.path

Zgodnie z inicjalizacją podczas uruchamiania programu, pierwszą pozycją na tej liście path[0]jest katalog zawierający skrypt, który został użyty do wywołania interpretera Pythona

Nie rób tego.

Twoje skrypty i dane nie powinny być łączone w jeden duży katalog. Umieścić swój kod w jakiejś znanej lokalizacji ( site-packageslub /var/opt/udiczy coś) oddzielone od danych. Używaj dobrej kontroli wersji w swoim kodzie, aby mieć pewność, że masz oddzielone od siebie wersje bieżące i poprzednie, dzięki czemu możesz wrócić do poprzednich wersji i przetestować przyszłe wersje.

Konkluzja: nie łącz kodu i danych.

Dane są cenne. Kod przychodzi i odchodzi.

Podaj katalog roboczy jako wartość argumentu wiersza polecenia. Możesz podać wartość domyślną jako zmienną środowiskową. Nie dedukuj tego (ani nie zgaduj)

Ustaw wymaganą wartość argumentu i zrób to.

import sys
import os
working= os.environ.get("WORKING_DIRECTORY","/some/default")
if len(sys.argv) > 1: working = sys.argv[1]
os.chdir( working )

Nie „zakładaj” katalogu na podstawie lokalizacji oprogramowania. Na dłuższą metę nie będzie dobrze działać.

Zmień polecenie crontab na

* * * * * (cd /home/udi/foo/ || exit 1; ./bar.py)

(...)Rozpoczyna sub-shell, że crond wykonywany jako jednego polecenia. || exit 1Powoduje, że cron niepowodzenie w przypadku, że katalog jest niedostępny.

Chociaż inne rozwiązania mogą na dłuższą metę być bardziej eleganckie dla określonych skryptów, mój przykład może być nadal przydatny w przypadkach, gdy nie możesz zmodyfikować programu lub polecenia, które chcesz wykonać.