Verzeichnisangaben mit enthaltenen Umgebungsvariablen

[hathor]

Kann jeder selbst nachprüfen:

1. Im CMD-Fenster:
- path eingeben

2. Mit DELPHI:
Memo1.Lines.Add(System.SysUtils.GetEnvironmentVari able('path'));
überprüfen

3. Im CMD-Fenster:
- path C:\ eingeben
- path eingeben

4. Mit DELPHI:
Memo1.Lines.Add(System.SysUtils.GetEnvironmentVari able('path'));
überprüfen
--- keine Änderung!


Siehe Anhang...

[himitsu]

Um das klarzustelen:

Die meisten WinAPIs lösen keine Umgebungsvariablen auf.
Viel schlimmer noch, denn "%irgendwas%" ist (in langen Pfadangaben, also nicht die alten 8.3-DOS-Pfade) ein korrekter Datei-/Verzeichnisname,
was dann gern darin endet, daß komische Programme gern mal Verzeichnisse mit solchen Dateinamen anlegen.




Und das Andere:
Jedes Programm (jeder Prozess) kann ein eigenes Set von Umgebungsvariablen besitzen.
Es bekommt es zwar meistens standardmäßig von deinem Aufrufer/Starter vererbt, aber der Prozess kann den Inhalt zur Laufzeit selber manipulieren, oder der Prozess bekomm beim Aufruf ein "anderes" Set mitgegeben.

In Delphi kennt man das z.B. als Delphi-Optionen > Umgebungsoptionen > Umgebungsvariablen > Vom Anwender überschrieben, welches dann für die IDE und von der IDE gestarteten Programmen gilt.



Und natürlich kann bei der Pfadbehandlung auch noch eine "manuelle" Behandlung von solchen "Variablen"-Platzhaltern implementiert sein, alternativ oder zusätzlich zu diesen Environment-Variablen.

[Dalai]

@hathor: Und weiter? Das zeigt doch nur, dass jedes Programm die Umgebungsvariablen beliebig ändern kann, ohne dass dabei die ursprünglichen Inhalte oder die Inhalte derselben Variablen in anderen Prozessen verändert werden! Das ist ein völlig normales Verhalten und auch von Delphi-Programmen (und anderen Programmen) aus nachvollziehbar. Öffne zwei Instanzen einer CMD und du wirst dieselben Ergebnisse erhalten.

IIRC gibt es eine API-Funktion, mit der man Änderungen an Umgebungsvariablen im System bekanntmachen kann und auch welche, mit denen man über solche Änderungen informiert werden kann; vermutlich sind das irgendwelche Messages.

MfG Dalai

[Sir Rufo]

@himitsu

Genau weil es sich um gültige Dateinamen handelt dürfen die WinApi-Funktionen das auch nicht automatisch auflösen. Genau aus dem Grund gibt es in der Registry auch den Value Type

REG_EXPAND_SZ

A null-terminated string that contains unexpanded references to environment variables (for example, "%PATH%"). It will be a Unicode or ANSI string depending on whether you use the Unicode or ANSI functions. To expand the environment variable references, use the ExpandEnvironmentStrings function.

[DeddyH]

Zitat von hathor:

Kann jeder selbst nachprüfen:

1. Im CMD-Fenster:
- path eingeben

2. Mit DELPHI:
Memo1.Lines.Add(System.SysUtils.GetEnvironmentVari able('path'));
überprüfen

3. Im CMD-Fenster:
- path C:\ eingeben
- path eingeben

4. Mit DELPHI:
Memo1.Lines.Add(System.SysUtils.GetEnvironmentVari able('path'));
überprüfen
--- keine Änderung!


Siehe Anhang...

Der "Beweis" hinkt aber ganz gewaltig. Schließ doch mal das Konsolenfenster, mach es neu auf und lass Dir Path ausgeben... Überraschung!

[edit] Irgendwie hab ich übersehen, dass nach himitsus noch andere Posts kamen [/edit]

[hathor]

Das ändert nichts an meiner Aussage:
"Befehle im CMD-Fenster ergeben andere Path-Variablen als wenn sie in einem WINDOWS-Programm aufgerufen werden."

Wollt Ihr jetzt "jahrelang" darüber diskutieren?

[DeddyH]

Und durch Wiederholung wird das richtiger? Aber meinetwegen, jeder darf ja glauben, was er will.

[Sir Rufo]

Jeder Prozess fängt mit dem gleichen Stand der Umgebungsvariablen an. Werden dann innerhalb des Prozesses Umgebungsvariablen geändert, dann gelten diese Änderungen nur für diesen Prozess.

Das sollte bekannt sein und ist auch nur vernünftig, denn sonst könnte man keine Batch-/Command-Dateien parallel laufen lassen, weil man ständig auf Überschneidungen dieser Umgebungsvariablen aufpassen müsste (wenn man diese benutzt).