새로운 독자들은 제 두 번째 편집 내용을 (그냥) 읽어보시기 바랍니다.
(원문 제목: "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, , min
(이는 링크된 도움말 파일의 예제와 동일합니다. 단, 예제에서는 출력을 c:\에 기록하며 최대한 복잡하지 않게 만들고 싶습니다.)
이는 명령 창만 열지만 명령을 쓰지 않으므로 출력이 없습니다. (/c 속성 없이 명령 창을 열어두면 이를 확인할 수 있습니다. runwait, %comspec% dir c:\ >>d:downloads\000.txt, , min )
그래서 글을 써야 해요
runwait, *runas %comspec% /c dir c:\ >>d:downloads\000.txt, , min
이것은 그들이 *runas "키"라고 부르는 것을 제외하고는 이전과 같습니다. 이것으로 "성공"이 있습니다. 그러나 이 명령은 먼저 "앱이 장치를 변경할 수 있도록 허용하시겠습니까?"라고 묻는 UAC 대화 상자를 엽니다. 유일한 "변경"은 분명히 출력 파일 쓰기입니다. 출력을 클립보드에 파이프로 연결했거나 명령 창 내에 도움말을 표시하는 다른 프로그램을 실행한 경우에도 마찬가지입니다.
이러한 경우에는 누구도 해당 UAC 대화 상자와 상호 작용하고 싶어하지 않고 출력이 추가로 처리되도록 자동으로 이 작업을 수행했을 것임이 분명합니다.
따라서 UAC에서 보안 설정을 변경해 보았습니다(UAC 대화 상자에 "자세히 보기"가 있고 이를 클릭하면 "이 알림이 표시되는 위치 변경"을 읽을 수 있습니다. 슬라이더) 4/4에서 3/4, 2/4, 1/4로, 이 모든 경우(이 역시 웹 브라우징 보안에 해를 끼칠 수 있음) UAC 대화 상자가 계속 방해가 되므로 다음으로 재설정했습니다. 4/4, 내 사용 사례에서는 분명히 이를 제거하는 방법이 아니기 때문입니다(= AHK에서 내 시스템으로 무해한 comspec 명령 보내기). 0/4로 설정했다면 아마도 제거했을 것입니다. 그러면 제3자 공격자에 대한 보안이 전혀 없게 되었을 것입니다.
따라서 시스템이 UAC 대화 상자를 표시하여 처리를 중단하지 않고 명령 창에서 AHK 명령을 수락하고 처리하도록 하려면 어떻게 해야 합니까?
(필요하다면 레지스트리를 수동으로 변경할 수도 있습니다.)
편집:
고마워요, 해리엠씨. 사실, 몇 시간 동안 노력한 후에도 나는 이 새로운 오류를 전혀 보지 못했습니다. (이 줄은 처음에는 정확했지만 나중에는 어떻게든 잘못되었습니다.) 내 평가판 스크립트에서 이전에 올바른 구문을 사용하여 시도했지만 작동하지 않았습니다. 이제 그 사람은 실제로 일합니다. 왜 이것이 지속되지 않는지 모르겠습니다.
또한 이 시험용 스크립트는 (작동하는) 일부 라인(다른 라인은 주석 처리되지 않음)일 뿐이며 이제 이 간단한 작업은 스크립트를 승격하지 않고도 거기에서 작동합니다.
user3419297님, 감사합니다. 위의 편집 내용에서 말했듯이 간단한 작업에는 이것이 필요하지 않지만 이 스크립틀릿은 잘 작동합니다. 이제 AHK 스크립트를 로드할 때 UAC 대화 상자에 응답해야 하지만 그대로 사용할 수 있습니다.
불행히도 내 실제 작업은 작동하지 않습니다. 지금도 명령 창이 비어 있고 명령이 입력되지 않아 거기에서 처리되지 않습니다.
내 진짜 문제는 명령줄을 통한 모든 검색입니다. 따라서 이들 중 하나는 작동해야 하지만 그 중 어느 것도 작동하지 않습니다. 수정되고 상승된 스크립트에서는 변형 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의 오류라고 누가 짐작할 수 있겠습니까?
세 번째 편집: 다른 이유로(AHK 스크립트가 상승하면 추가 도구가 더 이상 예상대로 작동하지 않음) UAC 문제가 아니라는 것을 확인할 수 있습니다. 추가 스크립트 부분을 다시 주석 처리했고 (재부팅 후) 위에 표시된 명령은 계속 작동합니다.
(속성 부분에 대해 그렇게 하지 않는 동안 프로그램 호출 부분을 변수에 넣는 것은 말이 안 되는 반면, 반대 방향은 의미가 있다는 것은 말할 필요도 없습니다. 두 부분을 모두 변수에 넣었습니다.)
추가 처리를 위해서는 대부분의 경우 출력을 클립보드로 파이프하는 것이 좋습니다.
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:현재 폴더가 루트가 아닌 경우 공식화가 실패할 수 있습니다 .