Arbeitsverzeichniss in der Shell immer gleich wie Ort der Python-Datei, die os.system ausgeführt hat?

Hi,

startet eine Shell, die durch ein Python-Script (os.system) aufgerufen wird, immer in dem selben Arbeitsverzeichnis, wie der Ort der Datei, in der sich der Python-Script befindet?

Blue-Tiger

Ich vermute mal, du redest von einem Unixoidem System: In dem Fall: ein Prozess erbt die CWD seines Elternprozesses. Sprich: die Shell wird das gleiche Arbeitsverzeichnis haben wie das Python-Script.

Ich habe mich wohl vertan. 'open' (z.B: open('','r')) hat ja nichts mit CWD zu tun, also gelten da offenbar andere Umgebungsregeln. Mir scheint, dass 'open' immer vom Home-Verzeichnis des ausführenden Users beginnt. Kann man für 'open' das Arbeitsverzeichnis vielleicht ändern oder muss man bei einem Dateinamen immer den Pfad mit angeben?

Also wenn ich das Python-Script von der Konsole (ubuntu) aus, ausführe gibt os.getcwd() immer den path des User Home-Verzeichnis zurück. Gibt es eine andere Methode, die den path des eigenen Script-Datei zurückgeben kann? Oder wenigstens den vollständigen String zu erhalten, mit dem die Script-Datei aufgerufen wurde?

Blue-Tiger

Ich nehm an du hast mitterweile selbst gemerkt, dass "open" sehr wohl immer im aktuellen CWD zum Suchen anfaengt. Auch deine zweite Aussage stimmt nicht: das Python-Script gibt nur dann das Home-Verzeichnis als das CWD zurueck, wenn du's vom Homeverzeichnis aus startest!

Schau dir z. B. mal folgendes Script (names "test.py") an:

#!/usr/bin/python
import os
print os.getcwd()

Das start ich jetzt 1x vom Home-Verzeichnis aus:

tom@blulap:~$ cd ~
tom@blulap:~$ python test.py
/home/tom

Jetzt wechsel ich in ein anderes Verzeichnis (hier /usr/local) und fuehr es dort nochmal aus:

tom@blulap:~$ cd /usr/local
tom@blulap:local$ python ~/test.py
/usr/local

Den vollstaendigen Pfad der Script-Datei erhaelst du, indem du sys.argv[0] anschaust. Der Pfad dort ist allerdings manchmal relativ zum CWD, in dem Fall wirst du wohl mit den Methoden aus os.path den absoluten Pfad zusammenbasteln muessen.

Aber was viel, viel wichtiger ist: Ich glaube, du willst eigentlich ein ganz anderes Problem loesen, und gehst die Sache falsch an. Was willst du _EIGENTLICH_ machen?

Also bei mir ist es so, dass die Script-Datei nicht im Home-Verzeichnis liegt und wenn ich nicht mittels 'cd' in das Verzeichnis wechsle, wo die Script-Datei liegt, gibt os.getcwd() bei mir das Home-Verzeichnis an, obwohl da die Script-Datei nicht ist. Wechsle ich mittels 'cd' in ein anderes Verzeichnis aber in eins wo die Script-Datei auch nicht liegt, gibt mir os.getcwd() das Verzeichnis an, in das ich vorher mittels 'cd' gewechselt bin.

Ich bin jetzt dabei sys.argv[0] zu nutzen, wobei ich nicht damit so ganz klar, den Teil ab dem letzten '/' abzutrennen. Versuche es gerade mit einer Rückwärtslaufenden Schleife aber string[0][i] mag irgendwie bei mir nicht funktionieren. Vielleicht extrahiere ich einfach sys.argv[0] vorher einfach in einen neuen 1-Dimensionalen String.

Was ich will ist eigentlich nichts besonderes. Wichtig zu wissen, für das Script selbst, von wo aus es startet, war schon bei MS-DOS mit Stapelverarbeitungsdateien so. Deshalb finde os.getcwd() enttäuschend.

Shade Of Mine

[Python] schrieb:

Was ich will ist eigentlich nichts besonderes. Wichtig zu wissen, für das Script selbst, von wo aus es startet, war schon bei MS-DOS mit Stapelverarbeitungsdateien so. Deshalb finde os.getcwd() enttäuschend.

Dieses verhalten haben alle Systeme die ich kenne. Ist auch wahnsinnig super so. Den Pfad wo deine Python Datei liegt bekommst du ueber argv[0].

Ansonsten: wie schon gesagt wurde, das CWD wird vom Vater geerbt. Das ist essentiell dass das so ist. Sonst koenntest du zB nicht

$ python foo.py

schreiben.

PS:
aber eigentlich braucht man den Pfad wo das Script liegt so gut wie nie. Warum brauchst du ihn denn?
PPS:
Probier mal: os.path.dirname(sys.argv[0])

Christoph

Blue-Tiger schrieb:

Den vollstaendigen Pfad der Script-Datei erhaelst du, indem du sys.argv[0] anschaust.[/b]

Nein. sys.argv[0] enthält in manchen Fällen den gesuchten Pfad, aber das wird keineswegs garantiert.

Im Gegenteil: Das ist sogar in einigen Fällen definitiv falsch. sys.argv[0] kann auch einfach der leere String sein oder irgendwas völlig nutzloses. Ein simples Beispiel in Bash ist:
$ python <(cat /pfad/zum/skript)
sys.argv[0] enthält dann etwas (ziemlich nutzloses) von der Form: /dev/fd/63

Anderes Beispiel:
$ cat /pfad/zum/skript | python
sys.argv[0] wird hier einfach leer sein.

Eine Shell kann sich auch entscheiden, bei einem normalen Aufurf sys.argv[0] komplett leerzulassen, aus irgendwelchen Sicherheitsgründen oder was auch immer. Es gibt keine Garantie, dass sys.argv[0] irgendetwas sinnvolles, geschweige denn einen Pfad, enthält, und es gibt viele Fälle, wo es definitiv keinen brauchbaren Pfad enthält.

Für mehr Details verweise ich auf diese Bash-FAQ: http://mywiki.wooledge.org/BashFAQ/028

"Der Pfad zum eigenen Skript" ist auf Linux-Systemen etwas, was man bei ordentlichen Programmen nicht dynamisch herausfinden sollte. Resourcen, die das Programm braucht, liegen üblicherweise in /usr/, darauf wird per absolutem Pfad zugegriffen.

Ich habe es jetzt so gelöst:

for i in range(len(sys.argv[0]) - 1, 0, -1):
	if sys.argv[0][i] == '/':
		currentPath = sys.argv[0][0:i+1]
		break

Den Path brauche ich z.B. wenn ich eine Datei lesen muss, die in dem selben Verzeichnis wie die Script-Datei liegt, dass Script aber portabel bleiben soll und man nicht gezwungen sein soll, den Path der Script-Datei wo fest reinschreiben zu müssen.

Das war auch im Moment meint einziges Problem. Mein eigentliches Problem wird nun schön durch mein Script behoben, genau so wie ich es mir vorgestellt habe. War einfach eine Idee, es mal mit Python zu probieren. Kann C/C++ eher besser aber habe mich mit Visual C++ richtig verharrt und hasse dieses Visual Studio Gesindel jetzt richtig.

Christoph

[Python] schrieb:

Den Path brauche ich z.B. wenn ich eine Datei lesen muss, die in dem selben Verzeichnis wie die Script-Datei liegt, dass Script aber portabel bleiben soll und man nicht gezwungen sein soll, den Path der Script-Datei wo fest reinschreiben zu müssen.

Dein Skript ist auf diese Weise nicht sonderlich portabel. Resourcen sollten in /usr liegen.

In jedem Fall sollte dein Programm sauber abbrechen, wenn es die Resource auch nach der argv[0]-Spielerei nicht findet. Es könnte schließlich sein, dass argv[0] gar keinen Pfad enthält oder an eine völlig falsche Stelle zeigt wie /dev/fd/.

Christoph schrieb:

[Python] schrieb:

Den Path brauche ich z.B. wenn ich eine Datei lesen muss, die in dem selben Verzeichnis wie die Script-Datei liegt, dass Script aber portabel bleiben soll und man nicht gezwungen sein soll, den Path der Script-Datei wo fest reinschreiben zu müssen.

Dein Skript ist auf diese Weise nicht sonderlich portabel. Resourcen sollten in /usr liegen.

In jedem Fall sollte dein Programm sauber abbrechen, wenn es die Resource auch nach der argv[0]-Spielerei nicht findet. Es könnte schließlich sein, dass argv[0] gar keinen Pfad enthält oder an eine völlig falsche Stelle zeigt wie /dev/fd/.

Naja in ubuntu scheint es soweit aber zu funktionieren. Es muss halt die Regel beachtet werden, dass das Script über den vollen Path aufgerufen wird und da es ja ein Bereinigungsscript ist, ist es ja auch so gedacht, dass der Path so im System eingetragen wird, dass die Script-Datei immer automatisch aufgerufen wird. Man also quasi zur Installation, nur den Path eintragen muss und quasi zur Deinstallation den Path nur wieder austragen muss. Ende der Geschichte.

Christoph

[Python] schrieb:

Christoph schrieb:

[Python] schrieb:

Den Path brauche ich z.B. wenn ich eine Datei lesen muss, die in dem selben Verzeichnis wie die Script-Datei liegt, dass Script aber portabel bleiben soll und man nicht gezwungen sein soll, den Path der Script-Datei wo fest reinschreiben zu müssen.

Dein Skript ist auf diese Weise nicht sonderlich portabel. Resourcen sollten in /usr liegen.

In jedem Fall sollte dein Programm sauber abbrechen, wenn es die Resource auch nach der argv[0]-Spielerei nicht findet. Es könnte schließlich sein, dass argv[0] gar keinen Pfad enthält oder an eine völlig falsche Stelle zeigt wie /dev/fd/.

Naja in ubuntu scheint es soweit aber zu funktionieren. Es muss halt die Regel beachtet werden, dass das Script über den vollen Path aufgerufen wird und da es ja ein Bereinigungsscript ist, ist es ja auch so gedacht, dass der Path so im System eingetragen wird, dass die Script-Datei immer automatisch aufgerufen wird. Man also quasi zur Installation, nur den Path eintragen muss und quasi zur Deinstallation den Path nur wieder austragen muss. Ende der Geschichte.

Wenn die Skript-Datei automatisch aufgerufen wird, dann kennt der Aufrufer ja den Pfad zum Skript und kann das current working directory passend setzen. Das wär vielleicht das einfachste.

Falls das aufgerufene Skript aber wirklich ein Bereinigungsskript ist und Dinge löscht, dann würde ich entweder die absoluten (!) Pfade zu den zu löschenden Dateien im Skript hartkodieren oder dem Skript die Pfade zu den zu löschenden Dateien auf der command line übergeben. Sich bei sowas auf argv[0] zu verlassen halte ich für ausgesprochen riskant.

Ich kann mich, was os.getcwd() anbelangt, immer nur wieder holen: Bei mir gibt os.getcwd() nicht das Verzeichnis zurück wo sich die Script-Datei befindet, auch wenn die Script-Datei mittels "Startprogrammeinstellungen" aufgerufen wird.

Die Dateien die von dem Script behandelt werden, sind einmalig und das Script greift auch nicht außerhalb seines Verzeichnis. Die zu behandelnde Datei muss/kann in das Verzeichnis kopiert werden, wo sich die Script-Datei befindet und die Quelle durch einen symbolischen Link ersetzt werden. Was bei einem vbox-Einsatz sehr effektiv ist. Sollten sich die Dateinamen der Dateien einmal ändern, muss man nur jeweils eine String-Variable ändern.

Shade Of Mine

[Python] schrieb:

Ich kann mich, was os.getcwd() anbelangt, immer nur wieder holen: Bei mir gibt os.getcwd() nicht das Verzeichnis zurück wo sich die Script-Datei befindet, auch wenn die Script-Datei mittels "Startprogrammeinstellungen" aufgerufen wird.

Natuerlich nicht. Das sagen wir ja die ganze Zeit. cwd ist dass was du von deinem Vater erbst: sprich der CWD des Prozesses der dein Script spawned.

Shade Of Mine schrieb:

[Python] schrieb:

Ich kann mich, was os.getcwd() anbelangt, immer nur wieder holen: Bei mir gibt os.getcwd() nicht das Verzeichnis zurück wo sich die Script-Datei befindet, auch wenn die Script-Datei mittels "Startprogrammeinstellungen" aufgerufen wird.

Natuerlich nicht. Das sagen wir ja die ganze Zeit. cwd ist dass was du von deinem Vater erbst: sprich der CWD des Prozesses der dein Script spawned.

Sag das Blue-Tiger

Shade Of Mine

[Python] schrieb:

Sag das Blue-Tiger

der sagt genau das selbe wie alle anderen.

Shade Of Mine schrieb:

[Python] schrieb:

Sag das Blue-Tiger

der sagt genau das selbe wie alle anderen.

Eben nicht:

Blue-Tiger schrieb:

[...]Sprich: die Shell wird das gleiche Arbeitsverzeichnis haben wie das Python-Script.

Shade Of Mine

[Python] schrieb:

Shade Of Mine schrieb:

[Python] schrieb:

Sag das Blue-Tiger

der sagt genau das selbe wie alle anderen.

Eben nicht:

Blue-Tiger schrieb:

[...]Sprich: die Shell wird das gleiche Arbeitsverzeichnis haben wie das Python-Script.

Eben doch.
Diese Diskussion hier ist laecherlich.
Schau dir seinen 2. Post an, da hat ersn deppen einfach erklaert.

Und vergiss auch Christophs Einwand nicht.

Shade Of Mine schrieb:

[Python] schrieb:

Shade Of Mine schrieb:

[Python] schrieb:

Sag das Blue-Tiger

der sagt genau das selbe wie alle anderen.

Eben nicht:

Blue-Tiger schrieb:

[...]Sprich: die Shell wird das gleiche Arbeitsverzeichnis haben wie das Python-Script.

Eben doch.
Diese Diskussion hier ist laecherlich.
Schau dir seinen 2. Post an, da hat ersn deppen einfach erklaert.

Und vergiss auch Christophs Einwand nicht.

Ach wie? Jetzt wieder doch so? Soll ich noch ein mal http://www.c-plusplus.net/forum/p2084209#2084209 wiederholen? Wach auf!

Shade Of Mine

no comment