UAC: Autohotkey chamando a janela de comando do Windows 10; es.exe por Voidtools Everything

UAC: Autohotkey chamando a janela de comando do Windows 10; es.exe por Voidtools Everything

Novos leitores, por favor (apenas) leiam minha segunda edição.

(Título original: "UAC: Não é mais possível usar a janela de comando com o Autohotkey (Windows 10)", título intermediário: "UAC: Não é mais possível executar es.exe (Voidtools Everything) na janela de comando do Autohotkey (Windows 10)")


No passado, usei a janela de comando com AHK; isso não é mais possível, sem a interferência do UAC. Parece que houve "atualizações" com as atualizações mais recentes do W10 (e/ou AHK?).

Mesmo que as coisas simplesmente não sejam mais possíveis, a ajuda do AHK não é compreensível (https://www.autohotkey.com/docs/commands/Run.htm).

Eu executo o seguinte comando AHK, sempre a partir de uma conta de administrador:

runwait, %comspec% /c dir c:\ >>d:downloads\000.txt, , min

(Isso é idêntico a um exemplo no arquivo de ajuda vinculado, exceto pelo fato de que, no exemplo, eles escrevem a saída em c:\, e eu quero descomplicar as coisas tanto quanto possível.)

Isso apenas abre a janela de comando, mas não grava nenhum comando nela e, portanto, não há saída. (Você pode verificar isso deixando a janela de comando aberta, sem o atributo /c: runwait, %comspec% dir c:\ >>d:downloads\000.txt, , min )

Então, eu tenho que escrever

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

É como antes, exceto pela "chave" *runas, como eles a chamam. Com isso, há “sucesso”, incl. a gravação da saída, MAS este comando primeiro abre a caixa de diálogo do UAC, que pergunta: "Deseja permitir que o aplicativo faça alterações no seu dispositivo?", sendo a única "alteração" obviamente a gravação do arquivo de saída; o mesmo ocorreria se eu apenas canalizasse a saída para a área de transferência ou se acionasse outro programa que apenas exibisse sua ajuda na janela de comando.

É óbvio que, para tais coisas, ninguém gostaria de interagir com a caixa de diálogo do UAC, mas simplesmente teria feito isso automaticamente, para que a saída fosse processada posteriormente.

Assim, tentei alterar minhas configurações de segurança no UAC (na caixa de diálogo do UAC, há "Mostrar mais detalhes", e ao clicar nele, você pode ler, "Alterar onde essas notificações aparecem", clicando nele e abrindo um controle deslizante) de 4/4 para 3/4, depois 2/4, depois 1/4 e, em todos esses casos (o que também prejudicaria a segurança da minha navegação na web), a caixa de diálogo do UAC continuou a interferir, então eu a redefini para 4/4, já que obviamente essa não é a maneira de me livrar dele no meu caso de uso (= enviar comandos comspec inofensivos do AHK para o meu sistema); Eu provavelmente teria me livrado dele se tivesse configurado para 0/4, o que me deixaria sem qualquer segurança para invasores terceiros.

Portanto, o que posso fazer para que a janela de comando aceite e processe meus comandos AHK, mas sem que meu sistema interrompa o processamento exibindo a caixa de diálogo do UAC?

(Eu poderia fazer alterações manuais no registro, se necessário.)


EDITAR% S:

Obrigado, Harry. Na verdade, depois de várias horas de tentativas, eu não tinha visto esse meu - novo - erro (essa linha estava correta primeiro, depois errei de alguma forma); em meu script de teste, comentado, eu fiz tentativas anteriores com a sintaxe correta, que não funcionou; agora isso funciona de fato; Não sei por que isso não é persistente.

Além disso, esse script de teste contém apenas algumas linhas (funcionais) (as outras foram comentadas), e essa coisa simples, agora, até funciona a partir daí, sem que o script seja elevado.


Obrigado, usuário3419297. Como dito acima em minha edição, para a tarefa simples, isso nem é necessário, mas esse scriptlet funciona bem, agora tenho que responder à caixa de diálogo do UAC ao carregar o script AHK, mas posso conviver com isso.

Infelizmente, minha tarefa real não funciona, mesmo agora a janela de comando permanece vazia, o comando não é colocado nela, portanto não é processado lá.

Meu verdadeiro problema é pesquisar tudo, por linha de comando, então um deles deve funcionar, mas NENHUM deles funciona, no script elevado e alterado, a variante 2 seria a sintaxe correta, eu acho:

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

(* = Aliás, a variante 1 deve trazer uma mensagem de erro para o espaço em "Arquivos de Programas", mas como o comando nem está escrito na janela de comando, nem mesmo a mensagem de erro obrigatória aparecerá.)

(Os comandos adicionais {enter}" certamente não são necessários, mas com ou sem, o texto do comando "runwait" (ou "run") NÃO é escrito na janela de comando; tudo isso, como dito, enviado do meu agora elevado o script AHK principal.)

Nem é preciso dizer que se eu colocar o comando "c:\Program Files\Everything\ES\es.exe" -h diretamente em uma janela de comando (não elevada) (e depois pressionar Enter, é claro), a ajuda do Everything é exibido na janela de comando.

Claro, o problema agora é consideravelmente complicado, pois para fazer o check-out, você teria instalado o exe de linha de comando Everything ("es.") ou possivelmente algum outro programa.

Antes de dizer, tudo se resume a um problema de Everything / es.exe (https://www.voidtools.com/forum/viewtopic.php?t=1745ehttps://www.voidtools.com/forum/viewtopic.php?t=7518) Eu fingiria que a linha de comando deveria pelo menos ser escrita na janela de comando, com possíveis problemas posteriormente, mas como dito, o comando em si não aparece na janela de comando.

E, mesmo a partir de um script não elevado (extra), tudo funcionou bem, incl. pesquisas reais, apenas alguns dias atrás. (E eu não tive nenhuma atualização de tudo no meio, mas possivelmente uma atualização do AHK (eu fiz isso recentemente e talvez não tenha feito pesquisas es.exe antes de hoje) e possíveis atualizações do W10 de qualquer maneira.)


SEGUNDA EDIÇÃO

NÃO parece ser um problema do UAC, tudo funciona de forma idêntica ao meu script AHK principal agora elevado e a qualquer outro script aparentemente não elevado.

Parece que atualmente NÃO é possível executar uma janela de comando persistente do AHK, daí a impossibilidade de executar até mesmo comandos "simples" em tal janela do AHK, sem o atributo /c, daí a impossibilidade de exibir até mesmo a ajuda do es.exe lá. Ver:

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

Por outro lado, mesmo o menor erro de sintaxe em es.exe OU em AHK deixará a janela de comando vazia, mas veja:

; 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

É óbvio que a funcionalidade ausente dos comandos AHK em uma janela de comando persistente irá regularmente enganar os usuários, uma vez que (aqui: falsamente) parece "natural" experimentar novos comandos primeiro em uma janela de comando persistente e "visível", e depois somente quando eles trabalhar lá, processando-os em uma janela não persistente, com o atributo /c: Quem poderia adivinhar que essa maneira "natural" de fazer as coisas era uma falácia do AHK?


TERCEIRA EDIÇÃO: Posso confirmar que NÃO é um problema do UAC, pois por outros motivos (ferramentas adicionais não funcionaram mais como esperado com meu script AHK elevado), comentei novamente a parte do script adicional e (após a reinicialização) o os comandos indicados acima continuam funcionando.

(Nem é preciso dizer que colocar a parte de chamada de prog em uma variável, embora não o faça na parte de atributos, não faria sentido, enquanto o contrário faria sentido; coloquei ambas as partes em variáveis.)

Para processamento posterior, seria preferível canalizar a saída para a área de transferência, na maioria dos casos:

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

Responder1

Acho que o problema é que o arquivo de saída está mal especificado.

Em vez de d:downloads\000.txtvocê deveria ter d:\downloads\000.txt.

Sua formulação poderá falhar se a pasta atual D:não for a raiz.

informação relacionada