Datei im übergordneten Verzeichnis erstellen

[Michael (Gast)]

Hallo zusammen,

ich möchte eine Datei erzeugen, die eine Ebene höher liegt wie meine 
Exe.

ich habe versucht, den Dateinamen für fopen

if((outstream=fopen(outfile,"w"))==NULL)

 wie folgt zu erweitern:


origial:

char *outfile="mytest.m";

neu:

char *outfile="..\mytest.m";

bzw.

char *outfile="..\\mytest.m";

beides funktioniert nicht. Die Ausgabe landet immer im selben 
Verzeichnis wie meine exe.
Am Ende möchte ich die Konsolenanwendung gerne per Argument mit einem 
relativen Ausgabepfad füttern.


Ich hoffe es kann jemand helfen.

Ich arbeite mit ms visual studio express 2010.

Grüße Michael

[hp-freund (Gast)]

Vielleicht wäre es besser das aktuelle Verzeichnis abzufragen, in eine 
Zeichenkette ablegen, das letzte Verzeichnis abzutrennen und das 
absolute Verzeichnis beim erstellen der Datei anzugeben.
Dann kannst Du auch gleich testen ob deine exe schon im root Verzeichnis 
liegt und es nicht höher geht.

[Michael (Gast)]

wie bekomme ich das aktuelle Verzeichnis?


Michael

[hp-freund (Gast)]

http://msdn.microsoft.com/de-de/library/windows/desktop/aa363806.aspx

[DirkB (Gast)]

Mit ..\\ bekommst du den relativen Pfad zum aktuellen Verzeichnis.
Das muss ja nicht das sein, in dem die .exe steht.

[Noname (Gast)]

Eben. Warum nicht noch ein "..\\" davor hängen?

[Joachim D. (Firma: JDCC) (scheppertreiber)]

Mal mit getcwd() das aktuele Verzeichnis abfragen.
Bei Windows richtet sich das bei relativen Pfaden nach den
Standort der exe.

[Michael (Gast)]

ich werde die Tips gleich ausprobieren
Vielen Dank schon mal
Michael

[Sven P. (Gast)]

Schau auch mal nach, welcher der tatsächliche Pfad zu Programmstart ist. 
Eventuell ist ein Debug-Build eingestellt, bei dem ein anderes 
Ausführungsverzeichnis gewählt ist.

[Peter II (Gast)]

Joachim Drechsel schrieb:
> Bei Windows richtet sich das bei relativen Pfaden nach den
> Standort der exe.
nein macht es nicht, das ausführungsverzeichnis ist dafür wichitg.

[Joachim D. (Firma: JDCC) (scheppertreiber)]

Peter II schrieb:
> nein macht es nicht, das ausführungsverzeichnis ist dafür wichitg.

Dann habe ich ein chinesisch gefälschtes Windows ;-)))

[Reinhard Kern (Gast)]

Joachim Drechsel schrieb:
> Dann habe ich ein chinesisch gefälschtes Windows ;-)))

Ja, das ist offensichtlich so. Du kannst z.B. bei jedem Link unter 
Eigenschaften einstellen "Ausführen in", d.h. du kannst zum 
Programmstart jedes beliebige Verzeichnis zum aktuellen machen. Aber das 
ist nur eine Möglichkeit von vielen, ein Arbeitsverzeichnis einzustellen 
- eine Beschäftigung mit BS-Grundlagen, Dateisystemen, 
Umgebungsvariablen und noch ein paar Erstsemesterfragen wäre wohl nicht 
verkehrt, bevor man die armen Chinesen beschuldigt.

Nach deiner Behauptung müsste der Windows-Explorer immer im 
Windows-Verzeichnis starten, weil dort die explorer.exe steht, das wäre 
aber sehr unpraktisch.

Gruss Reinhard

[Joachim D. (Firma: JDCC) (scheppertreiber)]

Was soll der Windows-Explorer denn damit zu tun haben ?

[Peter II (Gast)]

#include <stdio.h>

int main() {
  FILE* file = fopen("../test.txt", "a+" );
  fclose( file );
}

das macht genau das was du willst.

[DirkB (Gast)]

Peter II schrieb:
> FILE* file = fopen("../test.txt", "a+" );

Das erzeugt eine Datei in einer höheren Ebene als das 
Arbeitsverzeichnis.

Michael schrieb:
> ich möchte eine Datei erzeugen, die eine Ebene höher liegt wie meine
> Exe.

Die Exe kann ganz woanders liegen.
Sonst funktioniert die ganze Sache mit $PATH ja nicht.

[Michael (Gast)]

Vielen Dank.
Wenn ich die exe ausserhalb der Debug Umgebung ausführe,
klappt es ohne Probleme.- Danke für das Beispiel.
Hatte evtl. was mit Zugriffsrechten zu tun.

Grüße Michael

[Karl H. (kbuchegg)]

Michael schrieb:
> Vielen Dank.
> Wenn ich die exe ausserhalb der Debug Umgebung ausführe,
> klappt es ohne Probleme.- Danke für das Beispiel.
> Hatte evtl. was mit Zugriffsrechten zu tun.

Eher damit, dass du in der Entwicklungsumgebung ein anderes Working 
Directory hast. In Visual C++ ist es zb so

+  Projektverzeichnis
  +  Debugverzeichnis

Das EXE steht am Debugverzeichnis. Wenn der Debugger aber startet ist 
normalerweise das Projektverzeichnis das Working Directory.

[bluppdidupp (Gast)]

GetModuleFileName() + PathRemoveFileSpec() ergibt den Ordner, in dem die 
.exe liegt. Davon ausgehend könnte man sich den absoluten Pfad zum 
übergeordneten Ordner zusammenbauen.

Das "Current Directory" (bzw "Working Directory") sollte MS mal 
abschaffen ;D (oder dessen Auswirkungen nur auf OpenFileDialog, etc. 
beschränken)

[Peter II (Gast)]

bluppdidupp schrieb:
> Das "Current Directory" (bzw "Working Directory") sollte MS mal
> abschaffen ;D (oder dessen Auswirkungen nur auf OpenFileDialog, etc.
> beschränken)

warum, das ist doch sehr nützlich. was hilft dir ein "dir" was immer in 
seinem Programmverzeichniss ausgeführt wird?

[Udo S. (urschmitt)]

bluppdidupp schrieb:
> Das "Current Directory" (bzw "Working Directory") sollte MS mal
> abschaffen ;D (oder dessen Auswirkungen nur auf OpenFileDialog, etc.
> beschränken)

Na ja, es hat aber keiner seine Arbeitsdateien in das Verzeichnis zu 
legen in dem eine installierte Anwendung liegt oder gar in dem 
darüberliegenden Verzeichnis. Das widerspricht jeglichem 
Sicherkeitsaspekt und der Trennung von Programm und User-Daten auf einem 
Multi-User System.
Und genau das sind Windows und Unix Systeme.
Er kann seine Daten ja in sein home Verzeichnis schreiben.
Man könnte sich für so was auch eine Umgebungsvariable setzen und für 
den Fall dass sie nicht gesetzt ist mit einer sprechenden Fehlermeldung 
abbrechen.

[bluppdidupp (Gast)]

In der Konsole ist es sinnvoll. Im eigenen Programm stört es mich aber 
eher ;D

[bluppdidupp (Gast)]

Udo Schmitt schrieb:
> Na ja, es hat aber keiner seine Arbeitsdateien in das Verzeichnis zu
> legen in dem eine installierte Anwendung liegt oder gar in dem
> darüberliegenden Verzeichnis

Das stimmt, aber ich sehe da nur 2 verschiedene Varianten:
1) Daten die meine Anwendung intern verwendet (Datenbankdateien, etc.), 
die lege ich unter FOLDERID_LocalAppData, FOLDERID_RoamingAppData, ... 
ab.
2) Dateien die der Benutzer selbst via "Datei öffnen"-Dialog, etc. 
auswählt.

In Fall 1) bringt mir das Working-Directory nichts.
In Fall 2) bringt das Working-Directory der Anwendung selbst nicht 
wirklich was, sondern eher dem Datei-Öffnen-Dialog von Windows. Ich als 
Anwendung kriege ohnehin den absoluten Pfad der ausgewählten Datei(en) 
von der Dialog-Box.

Genau genommen baue ich Pfade aktuell auch nur zusammen um read-only auf 
Grafiken im Programmordner zuzugreifen ;D