AW: Verzeichnisangaben mit enthaltenen Umgebungsvariablen
Liste der Anhänge anzeigen (Anzahl: 1)
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... |
AW: Verzeichnisangaben mit enthaltenen Umgebungsvariablen
Liste der Anhänge anzeigen (Anzahl: 1)
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. :stupid: Anhang 41830 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. |
AW: Verzeichnisangaben mit enthaltenen Umgebungsvariablen
@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 |
AW: Verzeichnisangaben mit enthaltenen Umgebungsvariablen
@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. |
AW: Verzeichnisangaben mit enthaltenen Umgebungsvariablen
Zitat:
[edit] Irgendwie hab ich übersehen, dass nach himitsus noch andere Posts kamen :oops: [/edit] |
AW: Verzeichnisangaben mit enthaltenen Umgebungsvariablen
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? |
AW: Verzeichnisangaben mit enthaltenen Umgebungsvariablen
Und durch Wiederholung wird das richtiger? Aber meinetwegen, jeder darf ja glauben, was er will.
|
AW: Verzeichnisangaben mit enthaltenen Umgebungsvariablen
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). |
Alle Zeitangaben in WEZ +1. Es ist jetzt 15:57 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz