Bug mit der Path Variable im TC

[Tahattmeruh]

Wenn ich im TC arbeite und mehrere Kommandos absetzen will, dann öffne ich eine neue Shell mit CMD. Diese enthällt alle Pfade die in PATH definiert sind. Gehe ich über Arbeitsplatz -> Eigenschaften und erweitere die PATH Variable, gehe zurück in den TC und gebe nochmal CMD ein, dann steht dort immernoch die alte PATH Variable. Gehe ich über Start -> Ausführen, dann habe ich die aktuellen Einträge. Schließe ich den TC und starte ihn neu, dann bekomme ich in einer neuen Shell auch die neuen Pfade.

Das ist etwas umständlich. Kann man das irgendwie verhindern?

[shammat]

Ich glaube nicht, daß man das ändern kann. Ein Prozess der gestartet wird, erbt die Umgebungsvariablen (und nichts anderes ist PATH) des Prozesses der ihn startet. Wenn Du TC startest sind das die aktuellen Variablen des Windows-Explorers. "Erben" heißt in dem Fall, daß der Prozess eine Kopie anlegt.

Wenn die Variablen des startenden Prozesses geändert werden, so kriegen das die Prozesse die bereits gestartet wurden nicht mit (und können demnach ihre Kopie nicht aktualisieren)

Irgendeinen Trick scheint es aber zu geben, sonst könnte die Kommandozeile über Start -> Ausführen ja nicht die Variablen des Vaterprozesses ändern. Wie MS das gelöst hast weiß ich nicht, und ob das z.B. der TC verwenden kann, kann ich auch nicht sagen.

[HolgerK]

Irgendeinen Trick scheint es aber zu geben, ...

Wenn ich die folgende Zeile eintippe:

Code: Select all

runas /user:<NAME> cmd.exe

dann muss ich zwar mein Passwort des UserAccounts <NAME> angeben, aber ich erhalte eine Kommandokonsole mit den aktuellen Umgebungsvariablen!
Vielleicht weiss ja jemand einen besseren/kürzeren Trick?

Gruß
Holger

Edit:
Dabei geht mir allerdings %COMMANDER_PATH% verloren

[Sheepdog]

Man kann die Varible direkt in der Kommandozeile , sprich DOS-Fenster ändern:

Code: Select all

Path=%path%;c:\temp

sheepdog

[HolgerK]

Oder ghisler(Author) müsste vor dem Starten eines externen Programmes aus dem TC heraus, die Einträge aus der Registry:

HKEY_CURRENT_USER\Environment
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment

auslesen, und die prozessinterne Kopie des Enviroments daraus aktualisieren.
Das wäre dann sowas ähnliches wie das interne setzten der %COMMANDER_PATH%-Variablen.

Glaube kaum, das sowas mit einem Script möglich wäre, der würde ja auch nur seine eigene Enviroment-Kopie ändern.
Aber mal ernsthaft gefragt:
Wie häufig braucht man sowas?
Und ist das Neustarten des TC eine hinnehmbares Übel?

Gruß
Holger

[ghisler(Author)]

die Einträge aus der Registry

Das ist sehr unschön - wer weiss, ob das in zukünftigen Windows-Versionen immernoch dort stehen wird. Ausserdem kann es sein, dass da eingeschraenkte User keinen Zugriff haben.

Eine offiziell dokumentierte Funktion zum Auslesen der Umgebungsvariablen des Systems habe ich bisher leider nicht gefunden...

[HolgerK]

Eine offiziell dokumentierte Funktion zum Auslesen der Umgebungsvariablen des Systems habe ich bisher leider nicht gefunden...

Eine Möglichkeit wäre CreateEnvironmentBlock dessen Ergebnis an einen CreateProcessAsUser Aufruf übergeben wird.
Ist allerdings erst ab NT 4.0 verfügbar.
Die Code-Beispiele die ich, insbesondere zum Ermittlen des UserTokens, gefunden habe sind auch nicht ohne eine gewisse Komplexität.

Damit wäre es theoretisch möglich sowas wie das obige "Runas"-Beispiel mit dem aktuellen Login ohne Passwordeingabe zu realisieren.

Aber wie bereits in meinem vorherigen Post angedeutet:
Die Notwendigkeit für sowas ist eigentlich nur selten gegeben, und in einem solchen Fall würde ich persönlich lieber mit zwei Tastenkombination "ALT+F4" und "ALT+CTRL+C" (mein privater Shortcut zum TC) einfach den TC neu starten.

Ich kann mir auch ohne weiteres vorstellen den TC aus einem Batch heraus mit geändertem Environment zu starten. Dann ist die Vererbung des Environments auf die aus dem TC gestarteten Prozesse sogar von mir gewünscht.

Gruß
Holger

[Tahattmeruh]

Eine Möglichkeit wäre CreateEnvironmentBlock dessen Ergebnis an einen CreateProcessAsUser Aufruf übergeben wird.
Ist allerdings erst ab NT 4.0 verfügbar.

Danke für den Link. Werde ich mir mal genauer ansehen.
Vielleicht kann Christian das ab NT einbauen. Die Abfrage
sollte nicht so schwer sein.

[karlchen]

Hallo, an alle engagiert Diskutierenden.

Darf ich so ganz nebenbei nochmal auf was hinweisen, das shammat in seinem Beitrag zaghaft angedeutet hat?

Bei dem beschriebenen Verhalten handelt es sich nicht um einen Bug im TotalCommander, sondern um das ganz normale Verhalten des Betriebssystems, also Windows seit v95, NT usw.:

Jeder Prozess erbt die Umgebung seines Vaterprozesses. Also TC erbt die Umgebung seines Vaters, i.d.R. wird das der Explorer sein. Also gibt TC diese Umgebung, inklusive PATH, an seine Kinder weiter.

Wenn man nun bei laufendem TC die systemweite Umgebung des Windows über Arbeitsplatz => Eigenschaften => ... Umgebung ändert, dann bekommen bereits laufende Kinder des Explorer (defaultmäßig) davon nichts mit.

Also geben diese Kinder, inklusive TC, wenn sie selbst Prozesse starten, an diese ihre Umgebung mit, die dann nicht mehr mit der aktualisierten Umgebung des Arbeitsplatzes/Windows/Explorers übereinstimmt.

Das ist unter Windows so, das ist unter Unix so, das ist keine Macke des TotalCommanders. Wenn es unter Windows Möglichkeiten gibt, als Kind Änderungen des Vaterprozesses zu erfragen und zu übernehmen, dann ist da ja toll. Wenn das irgendwann in den TC eingebaut würde, vielleicht noch besser - hat mal einer über mögliche Nebenwirkungen nachgedacht? Aber einen Bug des TC kann ich immer noch nicht sehen.

So, nun dürft ihr über mich herfallen.

Karl

[HolgerK]

... das ist keine Macke des TotalCommanders ...
... So, nun dürft ihr über mich herfallen.

Ich gebe dir Recht.
Ich habe allerdings auch, glaube ich, an keiner Stelle gesagt, das ich darin einen Bug sehe.

Also zum dritten? Mal:
Für mich persönlich, ist es kein Problem den TC neu zu starten!

Wenn man allerdings komplett auf den Windows-Explorer (und das Start Menu) als Shell verzichten möchte, wäre so ein optional einstellbares Verhalten recht praktisch.
Dann wäre es ein weiterer Vorteil des TotalCommanders.

Gruß
Holger

[Tahattmeruh]

Ich dachte zuerst, es sein ein Bug.
shammat hat uns ja gut darüber aufgeklärt.
Wenn man das aber umgehen könnte, hätte
es ein paar Vorteile für mich. Ansätze wurden
ja schon gepostet. Falls Christian sich irgendwann
dazu entschliessen sollte soetwas einzubauen,
freu ich mich darüber. Ich werde aber nicht weiter
danach fragen.

[ghisler(Author)]

Eine Möglichkeit wäre CreateEnvironmentBlock

Ja, diese Funktion wurde mir von einem User auch schon per e-mail vorgeschlagen. Das Problem: Sie benötigt als Parameter ein sogenanntes User-Token, das man nur mit LogonUser bekommt, d.h. der Benutzer würde erneut nach seinem Passwort gefragt! Das ist doch sehr unpraktisch.

Kennt jemand einen Weg, das User-Token des aktuell eingeloggten Benutzers zu bekommen?

[karlchen]

Hallo, Christian.

Kennt jemand einen Weg, das User-Token des aktuell eingeloggten Benutzers zu bekommen?

Ohne jetzt versprechen zu können, daß ich es dort finden werde, werde ich am Wochenende (heute ist es schon zu spät, 23:50 CEST, und morgen wieder den ganzen Tag Oracle-Lehrgang) in das dicke, fette "Windows Internals 4th Edition" von Russinovich/Solomon schauen.
Wenn es jemand wissen sollte, dann die beiden.
Hoffentlich haben sie es auch beschrieben.

Wenn jemand die Info schneller beschaffen kann, soll er sich bitte nicht abhalten lassen. Her damit.

Karl

[HolgerK]

2ghisler(Author)

Das sollte unter Delphi mit der Funktion GetCurrentEnvironmentBlock funktionieren.
Kann's leider wegen fehlendem Delphi nicht direkt ausprobieren, aber das Prinzip habe ich eben mal mit einem kleinen C-Programm erfolgreich angetestet (falls die MS-IDE mir nicht einen Streich gespielt hat, und im Debugger das Enviroment aktualisiert hat).

Der Trick scheint darin zu bestehen, sich das UserToken vom laufenden Prozess mittels OpenProcessToken zu beschaffen.
Ist wesentlich simpler als das unten genannte C-Beispiel, und hoffentlich recht einfach in den TC einzubauen.

Ansonsten gibt es noch eine Artikel bei CodeProject "GUI-Based RunAsEx", der allerdings ziemlich ins Eingemachte geht, und eine temporären Service benutzt um (ohne Password ) einen Runas "username" durchzuführen.
Dann meckert aber jedes Sicherheitstool wie z.B Windows-Defender sofort los. Die Methode ist also absolut nicht zu empfehlen.

Gruß
Holger

[ghisler(Author)]

OpenProcessToken

Hmm, das gibt aber ein ProcessToken, kein Usertoken, oder ist das dasselbe?