UAC: Autohotkey llamando a la ventana de comandos de Windows 10; es.exe por Voidtools Todo

UAC: Autohotkey llamando a la ventana de comandos de Windows 10; es.exe por Voidtools Todo

Nuevos lectores, por favor (simplemente) lean mi segunda edición.

(Título original: "UAC: Ya no se puede usar la ventana de comandos con Autohotkey (Windows 10)", título intermedio: "UAC: Ya no se puede ejecutar es.exe (Voidtools Everything) en la ventana de comandos desde Autohotkey (Windows 10)")


En el pasado, usé la ventana de comandos con AHK; Esto ya no es posible sin que la UAC interfiera. Parece que ha habido "actualizaciones" con las actualizaciones más recientes de W10 (¿y/o AHK?).

Incluso las cosas muy simples ya no son posibles, la ayuda de AHK no es comprensible (https://www.autohotkey.com/docs/commands/Run.htm).

Ejecuto el siguiente comando AHK, siempre desde una cuenta de administrador:

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

(Esto es idéntico a un ejemplo en el archivo de ayuda vinculado, excepto por el hecho de que en el ejemplo, escriben el resultado en c:\, y quiero simplificar las cosas tanto como sea posible).

Esto simplemente abre la ventana de comandos pero no escribe ningún comando en ella y, por lo tanto, no hay salida. (Puede verificar esto dejando abierta la ventana de comandos, sin el atributo /c: runwait, %comspec% dir c:\ >>d:downloads\000.txt, , min )

entonces tengo que escribir

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

Esto es como antes, excepto por la "clave" *runas como la llaman. Con esto está el "éxito", incl. la escritura del archivo de salida, PERO este comando primero abre el cuadro de diálogo UAC, que pregunta: "¿Quieres permitir que la aplicación realice cambios en tu dispositivo?", siendo el único "cambio" obviamente la escritura del archivo de salida; Lo mismo ocurriría si simplemente canalizara la salida al portapapeles, o si activara otro programa que simplemente mostrara su ayuda dentro de la ventana de comandos.

Es obvio que para tales cosas, nadie querría tener que interactuar con ese cuadro de diálogo UAC, sino que simplemente lo habría hecho automáticamente, para que la salida pudiera seguir procesándose.

Por lo tanto, intenté cambiar mi configuración de seguridad en la UAC (en el cuadro de diálogo de la UAC, hay "Mostrar más detalles", y cuando haces clic en él, puedes leer "Cambiar dónde aparecen estas notificaciones", al hacer clic en eso y luego aparece un control deslizante) de 4/4 a 3/4, luego 2/4, luego 1/4, y en todos estos casos (lo que también dañaría mi seguridad de navegación web), el cuadro de diálogo UAC continuó interfiriendo, así que lo restablecí a 4/4, ya que obviamente esa no es la forma de deshacerme de él en mi caso de uso (= enviar comandos comspec inofensivos desde AHK a mi sistema); Probablemente me habría deshecho de él si lo hubiera configurado en 0/4, lo que me habría dejado sin ninguna seguridad frente a atacantes externos.

Entonces, ¿qué puedo hacer para que la ventana de comandos acepte y procese mis comandos AHK, pero sin que mi sistema detenga el procesamiento mostrando el cuadro de diálogo UAC?

(Podría realizar cambios manuales en el registro si fuera necesario).


EDICIONES:

Gracias, harrymc. De hecho, después de varias horas de intentarlo, no había visto este nuevo error mío (esta línea era correcta primero, luego me equivoqué de alguna manera); en mi script de prueba, superado en comentarios, tuve intentos anteriores para eso con la sintaxis correcta, que no funcionó; ahora que sí se trabaja; No sé por qué esto no es persistente.

Además, este script de prueba consta solo de algunas líneas (en funcionamiento) (las otras están comentadas), y esta cosa simple, ahora, incluso funciona desde allí, sin que el script sea elevado.


Gracias, usuario3419297. Como dije anteriormente en mi edición, para una tarea simple, esto ni siquiera es necesario, pero este scriptlet funciona bien. Ahora tengo que responder al cuadro de diálogo UAC al cargar el script AHK, pero puedo vivir con eso.

Desafortunadamente, mi verdadera tarea no funciona, incluso ahora la ventana de comandos permanece vacía, el comando no se coloca en ella, por lo que no se procesa allí.

Mi verdadero problema es la búsqueda de todo, por línea de comando, por lo que uno de estos debería funcionar, pero NINGUNO de ellos lo hace, en el script elevado y modificado, creo que la variante 2 sería la sintaxis correcta:

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

(* = Por cierto, la variante 1 debería mostrar un mensaje de error para el espacio en "Archivos de programa", pero como el comando ni siquiera está escrito en la ventana de comandos, ni siquiera aparecerá el mensaje de error obligatorio).

(Los comandos adicionales {enter}" ciertamente no son necesarios, pero con o sin, el texto del comando "runwait" (o "ejecutar") NO está escrito en la ventana de comandos; todo esto, como dije, enviado desde mi script AHK principal ahora elevado).

No hace falta decir que si pongo el comando "c:\Program Files\Everything\ES\es.exe" -h directamente en una ventana de comandos (no elevada) (y luego presiono Enter, por supuesto), la ayuda de Everything se muestra en la ventana de comandos.

Por supuesto, el problema ahora es considerablemente complicado, ya que para realizar el check-out, habría instalado el exe de la línea de comando Everything ("es."), o posiblemente algún otro programa.

Antes de decirlo todo se reduce a un problema de Everything/es.exe (https://www.voidtools.com/forum/viewtopic.php?t=1745yhttps://www.voidtools.com/forum/viewtopic.php?t=7518) Pretendería que la línea de comando al menos debería escribirse en la ventana de comandos, con posibles problemas posteriores, pero como dije, el comando en sí no aparece dentro de la ventana de comandos.

Y, incluso desde un guión no elevado (extra), todo esto funcionó bien, incl. búsquedas reales, hace apenas unos días. (Y no tuve ninguna actualización de Everything en el medio, pero posiblemente una actualización de AHK (lo hice recientemente y es posible que no haya realizado búsquedas de es.exe después, antes de hoy), y posibles actualizaciones de W10 de todos modos).


SEGUNDA EDICIÓN

NO parece ser un problema de UAC, todo funciona de manera idéntica desde mi script AHK principal ahora elevado y desde cualquier otro script aparentemente no elevado.

Parece que actualmente NO es posible ejecutar una ventana de comando persistente desde AHK, de ahí la imposibilidad de ejecutar incluso comandos "simples" en dicha ventana desde AHK, sin el atributo /c, de ahí la imposibilidad de mostrar incluso la ayuda de es.exe allá. 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 otro lado, incluso el más mínimo error de sintaxis en es.exe O en AHK dejará la ventana de comandos vacía, pero consulte:

; 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 obvio que la funcionalidad faltante de los comandos AHK en una ventana de comandos persistente engañará regularmente a los usuarios, ya que (aquí: falsamente) parece "natural" probar primero nuevos comandos en una ventana de comandos persistente y "visible", y luego solo cuando trabajar allí, procesándolos dentro de una ventana no persistente, con el atributo /c: ¿Quién podría adivinar que esta forma "natural" de hacer las cosas era una falacia con AHK?


TERCERA EDICIÓN: Puedo confirmar que NO es un problema de UAC, ya que por otras razones (las herramientas adicionales ya no funcionaron como se esperaba con mi script AHK elevado), volví a comentar la parte del script adicional y (después de reiniciar) el Los comandos indicados arriba continúan funcionando.

(No hace falta decir que poner la parte que llama a la programación en una variable, sin hacerlo para la parte de atributos, no tendría sentido, mientras que al revés sí tendría sentido; puse ambas partes en variables).

Para un procesamiento posterior, sería preferible canalizar la salida al portapapeles, en la mayoría de los casos:

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

Respuesta1

Creo que el problema es que el archivo de salida está mal especificado.

En lugar de d:downloads\000.txtti deberías haberlo hecho d:\downloads\000.txt.

Su formulación puede fallar si la carpeta actual D:no es la raíz.

información relacionada