UAC: Autohotkey が Windows 10 コマンド ウィンドウを呼び出す; Voidtools Everything の es.exe

UAC: Autohotkey が Windows 10 コマンド ウィンドウを呼び出す; Voidtools Everything の es.exe

新しい読者の方は、私の2回目の編集版を(ぜひ)読んでみてください。

(元のタイトル: 「UAC: Autohotkey でコマンド ウィンドウを使用できなくなりました (Windows 10)」、中間タイトル: 「UAC: Autohotkey のコマンド ウィンドウで es.exe (Voidtools Everything) を実行できなくなりました (Windows 10)」)


以前は、AHK でコマンド ウィンドウを使用していましたが、UAC の干渉がなければ、これはもう不可能です。最新の W10 (および/または AHK?) アップデートで「更新」があったようです。

非常に単純なことでさえもう不可能であり、AHKヘルプは理解できません(https://www.autohotkey.com/docs/commands/Run.htm)。

常に管理者アカウントから次の AHK コマンドを実行します。

runwait、%comspec% /c dir c:\ >>d:downloads\000.txt、、分

(これは、リンクされたヘルプ ファイルの例と同じですが、例では出力が c:\ に書き込まれており、できるだけ複雑にならないようにしたいという点が異なります。)

これはコマンド ウィンドウを開くだけで、コマンドは書き込まれないので、出力はありません。(/c 属性なしでコマンド ウィンドウを開いたままにしておくと、これを確認できます: runwait, %comspec% dir c:\ >>d:downloads\000.txt, , min )

だから、私は書かなければならない

runwait、*runas %comspec% /c dir c:\ >>d:downloads\000.txt、、分

これは、*runas「キー」と呼ばれるものを除いて、以前と同じです。これにより、出力の書き込みを含めて「成功」しますが、このコマンドは最初にUACダイアログを開き、「アプリがデバイスに変更を加えることを許可しますか?」と尋ねます。明らかに唯一の「変更」は出力ファイルの書き込みです。出力をクリップボードにパイプした場合や、コマンドウィンドウ内にヘルプを表示する別のプログラムをトリガーした場合も同じことが起こります。

このような場合、UAC ダイアログを操作したい人は誰もいないことは明らかですが、出力をさらに処理するために、これを自動的に実行するだけでしょう。

そこで、UAC のセキュリティ設定を 4/4 から 3/4、2/4、1/4 に変更してみました (UAC ダイアログには「詳細を表示」があり、それをクリックすると「これらの通知の表示場所を変更する」というメッセージが表示され、それをクリックするとスライダーが表示されます)。これらのすべてのケース (これも Web ブラウジングのセキュリティに悪影響を及ぼします) で、UAC ダイアログが引き続き干渉したため、4/4 にリセットしました。これは明らかに、私のユースケース (= AHK からシステムに無害な comspec コマンドを送信する) では、この方法では取り除けないためです。0/4 に設定していたら、おそらく取り除けていたでしょうが、サードパーティの攻撃者に対するセキュリティがまったく残っていなかったでしょう。

したがって、システムが UAC ダイアログを表示して処理を停止することなく、コマンド ウィンドウが AHK コマンドを受け入れて処理できるようにするには、どうすればよいでしょうか。

(必要に応じてレジストリを手動で変更することもできます。)


編集:

harrymc さん、ありがとうございます。実際、数時間試してみた後、この新しいエラーはまったく見られませんでした (この行は最初は正しかったのですが、その後、どういうわけか間違えてしまいました)。私の試用スクリプトでは、コメントアウトしましたが、正しい構文で以前に試したことがありましたが、うまくいきませんでした。今、その 1 つは確かに機能します。なぜこれが持続しないのかわかりません。

また、この試用スクリプトは、いくつかの(動作する)行(他の行はコメントアウトされています)だけであり、この単純なものは、スクリプトを昇格しなくても、そこからでも動作します。


ありがとうございます、user3419297。上記の編集で述べたように、単純なタスクではこれは必要ありませんが、このスクリプトレットは正常に動作します。AHK スクリプトをロードするときに UAC ダイアログに応答する必要がありますが、それで問題ありません。

残念ながら、私の実際のタスクは機能せず、今でもコマンド ウィンドウは空のままで、コマンドはそこに入力されないため、そこでは処理されません。

私の本当の問題は、コマンド ラインによる Everything 検索です。そのため、次のいずれかが機能するはずですが、いずれも機能しません。修正された昇格されたスクリプトでは、バリアント 2 が正しい構文だと思います。

+^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

(* = ちなみに、バリアント 1 では、「Program Files」内のスペースに関するエラー メッセージが表示されるはずですが、コマンドがコマンド ウィンドウに書き込まれていないため、必須のエラー メッセージも表示されません。)

(追加の「{enter}」コマンドは確かに必要ありませんが、そのコマンドの有無にかかわらず、「runwait」(または「run」) コマンドのコマンド テキストはコマンド ウィンドウに書き込まれません。これはすべて、前述のように、現在昇格されているメインの AHK スクリプトから送信されます。)

言うまでもなく、コマンド「c:\Program Files\Everything\ES\es.exe」-h を (管理者権限のない) コマンド ウィンドウに直接入力すると (そしてもちろん Enter キーを押すと)、Everything ヘルプがコマンド ウィンドウに表示されます。

もちろん、チェックアウトのために Everything コマンド ライン ("es.") exe またはその他のプログラムをインストールしたはずなので、問題はかなり複雑になっています。

結局のところ、Everything / es.exeの問題だと言う前に(https://www.voidtools.com/forum/viewtopic.php?t=1745そしてhttps://www.voidtools.com/forum/viewtopic.php?t=7518) 後で問題が発生する可能性はありますが、コマンド ラインは少なくともコマンド ウィンドウに書き込まれるべきだと考えますが、前述のように、コマンド自体はコマンド ウィンドウ内に表示されません。

また、数日前までは、昇格されていない (追加の) スクリプトからでも、実際の検索を含め、すべて正常に動作していました。 (その間に Everything の更新は行われていませんが、AHK の更新 (最近行ったため、その後、今日まで es.exe 検索を行っていない可能性があります)、および W10 の更新の可能性があります。)


第二版

これは UAC の問題ではないようです。現在昇格されているメインの AHK スクリプトでも、昇格されていないように見える他のスクリプトでも、すべて同じように動作します。

現時点では、AHK から永続的なコマンド ウィンドウを実行することはできないようです。そのため、/c 属性なしで AHK からそのようなウィンドウで「単純な」コマンドを実行することさえできず、es.exe ヘルプを表示することさえできません。参照:

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

一方、es.exe または AHK でわずかな構文エラーが発生した場合でも、コマンド ウィンドウは空のままになりますが、次の点に注意してください。

; 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

永続的なコマンド ウィンドウで AHK コマンドの機能が欠落していると、新しいコマンドを最初に永続的で「表示可能な」コマンド ウィンドウで試し、その後、そこで作業するときにのみ、/c 属性を使用して非永続的なウィンドウ内で処理するのが「自然」であるように見えるため、ユーザーを頻繁に誤解させることは明らかです。この「自然な」やり方が AHK の誤りであると誰が推測できたでしょうか。


3 回目の編集: これは UAC の問題ではないことを確認できます。他の理由 (AHK スクリプトが昇格された状態で追加のツールが期待どおりに動作しなくなった) により、追加のスクリプト部分を再度コメントアウトし、(再起動後) 上記の指定されたコマンドが引き続き機能するようになりました。

(言うまでもなく、プログラム呼び出し部分を変数に入れて、属性部分を変数に入れないのは意味がありませんが、その逆は意味があります。私は両方の部分を変数に入れました。)

さらに処理を進めるには、ほとんどの場合、出力をクリップボードにパイプすることが望ましいでしょう。

progvar := "c:\program files\everything\ES\es.exe"
attrvar := "c: parents:1 |clip"
runwait, %comspec% /c "%progvar%" %attrvar%

答え1

問題は出力ファイルの指定が不適切であることだと思います。

の代わりにd:downloads\000.txtを使用する必要がありますd:\downloads\000.txt

現在のフォルダーがD:ルートでない場合は、定式化が失敗する可能性があります。

関連情報