Neue Leser lesen bitte (nur) meine zweite Ausgabe.
(Originaltitel: „UAC: Befehlsfenster kann mit Autohotkey nicht mehr verwendet werden (Windows 10)“, Zwischentitel: „UAC: es.exe (Voidtools Everything) kann im Befehlsfenster von Autohotkey nicht mehr ausgeführt werden (Windows 10)“)
In der Vergangenheit habe ich das Eingabeaufforderungsfenster mit AHK verwendet. Dies ist nicht mehr möglich, ohne dass UAC eingreift. Es scheint, dass es mit den neuesten W10- (und/oder AHK?) Updates „Updates“ gegeben hat.
Selbst ganz einfache Dinge sind nicht mehr möglich, die AHK-Hilfe ist nicht verständlich (https://www.autohotkey.com/docs/commands/Run.htm).
Ich führe den folgenden AHK-Befehl immer von einem Administratorkonto aus:
runwait, %comspec% /c dir c:\ >>d:downloads\000.txt, , min
(Dies ist identisch mit einem Beispiel in der verlinkten Hilfedatei, mit der Ausnahme, dass im Beispiel die Ausgabe nach c:\ geschrieben wird und ich die Dinge so weit wie möglich vereinfachen möchte.)
Dadurch wird nur das Befehlsfenster geöffnet, aber kein Befehl hineingeschrieben, und daher erfolgt auch keine Ausgabe. (Sie können dies überprüfen, indem Sie das Befehlsfenster ohne das Attribut /c geöffnet lassen: runwait, %comspec% dir c:\ >>d:downloads\000.txt, , min )
Also muss ich schreiben
runwait, *runas %comspec% /c dir c:\ >>d:downloads\000.txt, , min
Dies ist wie zuvor, mit Ausnahme des *runas-„Schlüssels“, wie er genannt wird. Damit ist „Erfolg“ gegeben, einschließlich des Schreibens der Ausgabe, ABER dieser Befehl öffnet zuerst den UAC-Dialog, der fragt: „Möchten Sie der App erlauben, Änderungen an Ihrem Gerät vorzunehmen?“, wobei die einzige „Änderung“ offensichtlich das Schreiben der Ausgabedatei ist; dasselbe würde passieren, wenn ich die Ausgabe einfach in die Zwischenablage weiterleiten oder ein anderes Programm starten würde, das nur seine Hilfe im Befehlsfenster anzeigen würde.
Es ist offensichtlich, dass bei solchen Dingen niemand mit diesem UAC-Dialog interagieren möchte, sondern dies einfach automatisch erledigt, um die Ausgabe anschließend weiter zu verarbeiten.
Ich habe es also versucht, indem ich meine Sicherheitseinstellungen in der Benutzerkontensteuerung (im Dialogfeld der Benutzerkontensteuerung gibt es „Weitere Details anzeigen“, und wenn Sie darauf klicken, können Sie „Ändern, wo diese Benachrichtigungen angezeigt werden“ lesen. Wenn Sie darauf klicken, wird ein Schieberegler angezeigt) von 4/4 auf 3/4, dann auf 2/4 und dann auf 1/4 geändert habe. In allen diesen Fällen (die auch meine Sicherheit beim Surfen im Internet gefährden würden) hat das Dialogfeld der Benutzerkontensteuerung weiterhin gestört. Ich habe es also auf 4/4 zurückgesetzt, da dies in meinem Anwendungsfall (= Senden harmloser Comspec-Befehle von AHK an mein System) offensichtlich nicht die Möglichkeit ist, es zu beseitigen. Wahrscheinlich wäre ich es beseitigt worden, wenn ich die Einstellung auf 0/4 gesetzt hätte, wodurch ich gegenüber Angreifern von Drittanbietern keinerlei Sicherheit gehabt hätte.
Was kann ich also tun, damit das Befehlsfenster meine AHK-Befehle akzeptiert und verarbeitet, ohne dass mein System die Verarbeitung durch Anzeige des UAC-Dialogs stoppt?
(Ich könnte bei Bedarf manuelle Änderungen an der Registrierung vornehmen.)
BEARBEITUNGEN:
Vielen Dank, harrymc. Tatsächlich ist mir dieser – neue – Fehler von mir nach mehreren Stunden des Versuchens überhaupt nicht aufgefallen (diese Zeile war zuerst richtig, dann habe ich sie irgendwie falsch gemacht); in meinem auskommentierten Testskript hatte ich jedoch frühere Versuche mit der richtigen Syntax, die nicht funktionierten; jetzt funktioniert dieser tatsächlich; ich weiß nicht, warum das nicht dauerhaft ist.
Außerdem besteht dieses Testskript nur aus einigen (funktionierenden) Zeilen (die anderen sind auskommentiert) und diese einfache Sache funktioniert jetzt sogar von dort aus, ohne dass das Skript erweitert werden muss.
Vielen Dank, user3419297. Wie oben in meiner Bearbeitung gesagt, ist dies für die einfache Aufgabe nicht einmal erforderlich, aber dieses Scriptlet funktioniert einwandfrei. Ich muss jetzt den UAC-Dialog beim Laden des AHK-Skripts beantworten, aber damit kann ich leben.
Leider klappt meine eigentliche Aufgabe auch jetzt nicht, das Kommandofenster bleibt leer, der Befehl wird dort nicht eingegeben, also auch nicht verarbeitet.
Mein wirkliches Problem ist die Suche nach allem über die Befehlszeile, daher sollte eine davon funktionieren, aber KEINE davon tut es. Im geänderten, erweiterten Skript wäre meiner Meinung nach Variante 2 die richtige Syntax:
+^F2::
msgbox, variant 1: ; *
runwait, %comspec% "c:\Program Files\Everything\ES\es.exe -h"
; send, {enter}
msgbox, variant 2:
runwait, %comspec% "c:\Program Files\Everything\ES\es.exe" -h
; send, {enter}
msgbox, variant 3:
runwait, %comspec% "c:\Program Files\Everything\ES\es.exe" "-h"
; send, {enter}
msgbox, variant 4:
runwait, %comspec% ""c:\Program Files\Everything\ES\es.exe" -h"
; send, {enter}
msgbox, variant 5:
runwait, %comspec% ""c:\Program Files\Everything\ES\es.exe" "-h""
; send, {enter}
return
(* = Übrigens, Variante 1 sollte eine Fehlermeldung für den Bereich in "Programme" bringen, da der Befehl aber gar nicht in das Befehlsfenster geschrieben wird, bleibt auch die obligatorische Fehlermeldung aus.)
(Die zusätzlichen {enter}"-Befehle sind sicherlich nicht notwendig, aber mit oder ohne wird der Befehlstext des "runwait"- (oder "run")-Befehls NICHT in das Befehlsfenster geschrieben; all dies wird, wie gesagt, von meinem jetzt erhöhten Haupt-AHK-Skript gesendet.)
Es versteht sich von selbst, dass, wenn ich den Befehl "c:\Program Files\Everything\ES\es.exe" -h direkt in ein (nicht erhöhtes) Befehlsfenster eingebe (und dann natürlich die Eingabetaste drücke), die Everything-Hilfe im Befehlsfenster angezeigt wird.
Natürlich ist das Problem jetzt erheblich komplizierter, da Sie zum Auschecken die Everything-Befehlszeilen-EXE („es.“) oder möglicherweise ein anderes Programm installiert hätten.
Bevor ich sage, dass es auf ein Everything / es.exe-Problem hinausläuft (https://www.voidtools.com/forum/viewtopic.php?t=1745Undhttps://www.voidtools.com/forum/viewtopic.php?t=7518) Ich würde so tun, als ob die Befehlszeile zumindest in das Befehlsfenster geschrieben werden sollte, was anschließend zu möglichen Problemen führen könnte, aber wie gesagt, der Befehl selbst wird nicht im Befehlsfenster angezeigt.
Und selbst von einem nicht erhöhten (zusätzlichen) Skript aus hat das alles vor wenigen Tagen problemlos funktioniert, einschließlich echter Suchvorgänge. (Und ich hatte zwischendurch kein Everything-Update, sondern möglicherweise ein AHK-Update (das habe ich vor Kurzem gemacht und habe es.exe-Suchvorgänge danach möglicherweise tatsächlich nicht vor heute durchgeführt) und möglicherweise sowieso W10-Updates.)
ZWEITE BEARBEITUNG
Es scheint KEIN UAC-Problem zu sein, es funktioniert alles identisch von meinem jetzt erhöhten AHK-Hauptskript und von jedem anderen, scheinbar nicht erhöhten Skript aus.
Es scheint derzeit NICHT möglich zu sein, ein persistentes Befehlsfenster von AHK aus auszuführen, daher ist es unmöglich, auch nur „einfache“ Befehle in einem solchen Fenster von AHK aus auszuführen, ohne das Attribut /c, daher ist es unmöglich, dort auch nur die es.exe-Hilfe anzuzeigen. Siehe:
runwait, %comspec% /c dir c:\ >>d:\downloads\000.txt, , min ; works fine, but
runwait, %comspec% dir c:\ >>d:\downloads\0000.txt, , min ; does NOT work
Andererseits führt selbst der kleinste Syntaxfehler in es.exe ODER in AHK dazu, dass das Befehlsfenster leer bleibt, aber siehe:
; the data to be retrieved is always identical:
progvar := "c:\program files\everything\ES\es.exe"
attrvar := "c: parents:1 -export-txt d:\downloads\0both.txt"
; no var used here, works:
; runwait, %comspec% /c "c:\program files\everything\ES\es.exe" c: parents:1 -export-txt d:\downloads\0none.txt
; ditto with persistent command window, command is NOT written into command window, so NO output either:
; runwait, %comspec% "c:\program files\everything\ES\es.exe" c: parents:1 -export-txt d:\downloads\0nonebutpersistent.txt
; only progvar used here, works:
; runwait, %comspec% /c "%progvar%" c: parents:1 -export-txt d:\downloads\0progonly.txt
; both vars used here, works:
runwait, %comspec% /c "%progvar%" %attrvar%
; ditto with persistent command window, command window (persistent) remains empty again:
; runwait, %comspec% "%progvar%" %attrvar%
return
Es liegt auf der Hand, dass die fehlende Funktionalität von AHK-Befehlen in einem persistenten Befehlsfenster Benutzer regelmäßig in die Irre führt, da es (hier: fälschlicherweise) als „natürlich“ erscheint, neue Befehle zuerst in einem persistenten, „sichtbaren“ Befehlsfenster auszuprobieren und sie dann, wenn sie dort funktionieren, in einem nicht persistenten Fenster mit dem Attribut /c verarbeiten zu lassen: Wer hätte gedacht, dass diese „natürliche“ Vorgehensweise bei AHK ein Trugschluss ist?
DRITTE BEARBEITUNG: Ich kann bestätigen, dass es KEIN UAC-Problem ist, da ich aus anderen Gründen (zusätzliche Tools funktionierten mit meinem erhöhten AHK-Skript nicht mehr wie erwartet) den zusätzlichen Skriptteil wieder auskommentiert habe und (nach dem Neustart) die oben angegebenen Befehle weiterhin funktionieren.
(Es versteht sich von selbst, dass es keinen Sinn hätte, den Programmaufrufteil in eine Variable zu packen, dies aber für den Attributteil nicht zu tun, während es umgekehrt sinnvoll wäre; ich habe beide Teile in Variablen gepackt.)
Für die weitere Verarbeitung ist in den meisten Fällen eine Weiterleitung der Ausgabe in die Zwischenablage vorzuziehen:
progvar := "c:\program files\everything\ES\es.exe"
attrvar := "c: parents:1 |clip"
runwait, %comspec% /c "%progvar%" %attrvar%
Antwort1
Ich denke, das Problem liegt darin, dass die Ausgabedatei falsch spezifiziert ist.
Stattdessen d:downloads\000.txthätten Sie haben sollen d:\downloads\000.txt.
Ihre Formulierung schlägt möglicherweise fehl, wenn der aktuelle Ordner D:nicht das Stammverzeichnis ist.