UAC: Autohotkey, вызывающий окно команд Windows 10; es.exe от Voidtools Everything

UAC: Autohotkey, вызывающий окно команд Windows 10; es.exe от Voidtools Everything

Новые читатели, пожалуйста, (просто) прочтите мою вторую правку.

(Исходное название: «UAC: больше невозможно использовать командное окно с Autohotkey (Windows 10)», промежуточное название: «UAC: больше невозможно запустить es.exe (Voidtools Everything) в командном окне из Autohotkey (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 (в диалоговом окне UAC есть «Показать больше сведений», и при нажатии на него вы можете прочитать «Изменить место появления этих уведомлений», нажав на него, а затем вызвав ползунок) с 4/4 на 3/4, затем на 2/4, затем на 1/4, и во всех этих случаях (что также навредило бы моей безопасности при просмотре веб-страниц) диалоговое окно UAC продолжало мешать, поэтому я сбросил его на 4/4, поскольку это, очевидно, не способ избавиться от него в моем случае использования (= отправка безвредных команд comspec из AHK в мою систему); я, вероятно, избавился бы от него, если бы установил настройку на 0/4, что оставило бы меня без какой-либо защиты от сторонних злоумышленников.

Итак, что я могу сделать, чтобы командное окно принимало и обрабатывало мои команды AHK, но при этом моя система не останавливала обработку, отображая диалоговое окно UAC?

(При необходимости я могу вручную внести изменения в реестр.)


ПРАВКИ:

Спасибо, harrymc. На самом деле, после нескольких часов попыток я вообще не видел этой своей новой ошибки (эта строка была сначала правильной, а потом я как-то ошибся); в моем пробном скрипте, закомментированном, у меня были предыдущие попытки сделать это с правильным синтаксисом, которые не сработали; теперь эта действительно работает; я не знаю, почему это не сохраняется.

Кроме того, этот пробный скрипт представляет собой всего лишь несколько (рабочих) строк (остальные закомментированы), и эта простая вещь теперь работает даже оттуда, без повышения уровня скрипта.


Спасибо, user3419297. Как было сказано выше в моей правке, для простой задачи это даже не нужно, но этот скриптлет отлично работает, теперь мне приходится отвечать на диалог UAC при загрузке скрипта AHK, но с этим можно жить.

К сожалению, моя реальная задача не работает, даже сейчас окно команд остается пустым, команда в него не вводится, а значит, и не обрабатывается.

Моя настоящая проблема - поиск по всему миру с помощью командной строки, поэтому один из них должен работать, но НИ ОДИН из них не работает, в измененном скрипте с повышенными привилегиями, вариант 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, отсюда невозможно запустить даже "простые" команды в таком окне из AHK без атрибута /c, отсюда невозможно отобразить там даже справку 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?


ТРЕТЬЕ ПРАВКА: Я могу подтвердить, что это НЕ проблема 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:не является корневой.

Связанный контент