"\"a\"" 이 예상되는 동작이라고 생각하는 이유는 무엇입니까? PowerShell 이스케이프에 대한 나의 이해에 따르면 실제 동작은 정확하고 예상되는 동작입니다. " "a "" 는 a 둘러싼 이스케이프 된 따옴표 쌍을 둘러싼 따옴표 쌍이므로 PowerShell은 외부 이스케이프되지 않은 쌍을"this is a string argument "로 해석하고 그래서 그것들을 삭제 한 다음 이스케이프 된 쌍을 이스케이프 된 따옴표로 해석하여 "a" 남겨 둡니다. 문자열에 \ 추가되지 않았습니다.

Bash가 \ 를 이스케이프 문자로 사용한다는 사실은 관련이 없습니다. PowerShell에서 이스케이프 문자는 백틱입니다. PowerShell 이스케이프 문자를 참조하십시오.

문자 그대로 "\"a\"" 전달하려면 다음을 사용합니다.

> echo `"\`"a\`"`"
"\"a\""

뿡뿡
예, 이스케이프는 내부 ​​cmdlet에 대해 잘 작동하지만 특히 Windows에서 기본 바이너리 와 통신 할 때 상황이 이상해집니다.
native.exe " "a "" 실행할 때 ARGV [1]는

"a"

(3 자)

대신에

(한 문자).

현재 native.exe 가 두 개의 따옴표와 a 문자가있는 ARGV를 올바르게 수신하려면 다음과 같은 이상한 호출을 사용해야합니다.

native.exe "\`"a\`""

아, 알겠습니다. 재개.

호기심이 심해서 # 1639를 사용하여 빌드를 시도하면 어떻게 되나요?

@andschwa 동일합니다. PowerShell과 CommandLineToArgvW 모두 만족 시키려면 두 번 이스케이프해야합니다. 이 줄 :

native.exe "`"a`""

StartProcess가 cmd와 같음

native.exe ""a""

@ be5invis @douglaswth 는 https://github.com/PowerShell/PowerShell/pull/2182 를 통해 해결

아니요, 백틱 이스케이프 처리 된 큰 따옴표 앞에 백 슬래시를 추가해야합니까? 이중 이스케이프 문제는 해결되지 않습니다. (즉, PowerShell과 CommandLineToArgvW 모두에 대해 큰 따옴표를 이스케이프해야합니다.)

" "a "" 는 '"a"' 와 같으므로 " native.exe '"a"' 결과가 "\"a\"" 되어야한다고 제안하십니까?

이는 구현 된 경우 필요한 이중 이스케이프를 사용하는 기존의 많은 PowerShell 스크립트를 손상시킬 수있는 기능 요청처럼 보이므로 모든 솔루션에 대해 세심한주의가 필요합니다.

@vors 예.
@douglaswth 이중 이스케이프는 정말 어리 석습니다. DOS 시대에 만들어진 "내부"이스케이프가 필요한 이유는 무엇입니까?

트윗 담아 가기
GetCommandLineW 및 CommandLineToArgvW 결과를 표시하는 데 사용되는 C 코드입니다.

#include <stdio.h>
#include <wchar.h>
#include <Windows.h>

int main() {
  LPWSTR cmdline = GetCommandLineW();
  wprintf(L"Command Line : %s\n", cmdline);

  int nArgs;
  LPWSTR *szArglist = CommandLineToArgvW(cmdline, &nArgs);
  if (NULL == szArglist) {
    wprintf(L"CommandLineToArgvW failed\n");
    return 0;
  } else {
    for (int i = 0; i < nArgs; i++) {
      wprintf(L"argv[%d]: %s\n", i, szArglist[i]);
    }
  }
  LocalFree(szArglist);
}

결과는 다음과 같습니다.

$ ./a "a b"
Command Line : "Z:\playground\ps-cmdline\a.exe" "a b"
argv[0]: Z:\playground\ps-cmdline\a.exe
argv[1]: a b

$ ./a 'a b'
Command Line : "Z:\playground\ps-cmdline\a.exe" "a b"
argv[0]: Z:\playground\ps-cmdline\a.exe
argv[1]: a b

$ ./a 'a"b'
Command Line : "Z:\playground\ps-cmdline\a.exe" a"b
argv[0]: Z:\playground\ps-cmdline\a.exe
argv[1]: ab

$ ./a 'a"b"c'
Command Line : "Z:\playground\ps-cmdline\a.exe" a"b"c
argv[0]: Z:\playground\ps-cmdline\a.exe
argv[1]: abc

$ ./a 'a\"b\"c'
Command Line : "Z:\playground\ps-cmdline\a.exe" a\"b\"c
argv[0]: Z:\playground\ps-cmdline\a.exe
argv[1]: a"b"c

@ be5invis 저는 이중 이스케이프가 성가신 것에 대해 동의하지 않지만, 이것에 대한 변경은 기존 PowerShell 스크립트가 사용하는 것과 역 호환되어야한다는 것입니다.

얼마나 많은가요? 그런 큰 따옴표에 대해 알고있는 스크립트 작성자가 없다고 생각합니다. 기능이 아니라 버그이며 문서화되지 않았습니다.

???? 아이폰

? 2016? 9? 21 ?? 01 : 58? Douglas Thrift < [email protected] [email protected] > ???

@ be5i nvishttps : //github.com/be5invis 이중 이스케이프가 성가신 것에 대해 동의하지 않지만, 이에 대한 변경은 기존 PowerShell 스크립트가 사용하는 것과 역 호환되어야한다는 것입니다.

당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하거나 Gi tHubhttps : //github.com/PowerShell/PowerShell/issues/1995#issuecomment -248381045에서 확인하거나 https://github.com/notifications/unsubscribe-auth/AAOp20f_W0mTl2YiJKi_flQBJUKaeAnLks5qsB7ZgaJpZM4JpVin.

PowerShell은 9 년 동안 사용되어 왔으므로 많은 수의 스크립트가있을 가능성이 큽니다. 필요에 따라 StackOverflow 및 기타 소스에서 이중 이스케이프가 필요한지에 대한 많은 정보를 찾았으므로 그 필요성에 대해 아무도 모르거나 문서화되지 않았다는 귀하의 주장에 동의하는지 모르겠습니다. .

추가 컨텍스트를 위해 구현에 대해 조금 이야기하고 싶습니다.
PowerShell은 .NET API를 호출하여 Windows에서 Win32 API를 호출하는 새 프로세스를 생성합니다.

여기서 PS는 다음을 사용하는 StartProcessInfo를 생성합니다.
https://github.com/PowerShell/PowerShell/blob/master/src/System.Management.Automation/engine/NativeCommandProcessor.cs#L1063

제공된 API는 인수에 대해 단일 문자열을 취한 다음 실행을 수행하기 위해 인수 배열로 다시 파싱됩니다.
이 재분석 규칙은 PowerShell에 의해 제어되지 않습니다. 이는 Win32 API입니다 (다행히도 dotnet 코어 및 유닉스 규칙에서 일관성이 있음).
특히이 계약은 \ 및 " 동작을 설명합니다.

PowerShell은 더 똑똑하고 더 좋은 환경을 제공하려고 할 수 있지만 현재 동작은 cmd 및 bash와 일치합니다. 기본 실행 줄을 복사하여 powershell에서 사용할 수 있으며 동일하게 작동합니다.

@ be5invis 깨지지 않는 방식으로 경험을 향상시키는 방법을 알고 있다면 세부 사항을 정렬하십시오. 주요 변경 사항의 경우 https://github.com/PowerShell/PowerShell/blob/master/docs/dev-process/breaking-change-contract.md에 설명 된대로 RFC 프로세스를 사용해야합니다.

이것은 Windows에 적용되지만 Linux 또는 Unix에서 명령을 실행할 때 이중 이스케이프 따옴표가 필요하다는 것이 이상합니다.

Linux에서 프로세스에는 단일 명령 줄이 아니라 인수 배열이 있습니다.
따라서 powershell의 인수는 모든 인수를 병합 한 다음 다시 분할하는 대신 실행 파일에 전달되는 인수와 동일해야합니다.

창에서도 현재 동작은 일관되지 않습니다.
인수에 공백이 없으면 변경되지 않고 전달됩니다.
인수에 공백이 포함 된 경우 따옴표로 묶이면 CommandLineToArgvW 호출을 통해 함께 유지합니다. => CommandLineToArgvW 요구 사항을 충족하도록 인수가 변경되었습니다.
그러나 인수에 따옴표가 포함되어 있으면 이스케이프되지 않습니다. => CommandLineToArgvW 에는 인수가 필요하지만 인수는 변경되지 않습니다.

인수는 절대 변경되지 않거나 CommandLineToArgvW 요구 사항을 충족하기 위해 항상 변경되어야한다고 생각합니다.

계약 파기 관련 :
이중 이스케이프에 대한 공식 문서를 찾을 수 없기 때문에 이것을 "버킷 2 : 합리적인 회색 영역"범주로 간주 할 것이므로이를 변경할 가능성이 있습니까, 아니면 제가 틀렸습니까?

@vors 인수가 변수이거나 다른
"자동 이스케이프"연산자가 도움이 될 수 있습니다. ^"a " " -> "a\ " "`처럼

나는 @TSlivede 가 행동의 불일치로 옳다고 생각합니다.

인수는 절대 변경되지 않거나 CommandLineToArgvW 요구 사항을 충족하기 위해 항상 변경되어야한다고 생각합니다.

버킷에 대해 잘 모르겠지만 "분명히 중요한 변경 사항"버킷도 잠재적으로 변경 될 수 있습니다. 우리는 PowerShell을 더 좋게 만들고 싶지만 이전 버전과의 호환성은 우리의 최우선 순위 중 하나입니다. 그것이 그렇게 쉽지 않은 이유입니다.
우리는 훌륭한 커뮤니티를 가지고 있으며 합의를 찾을 수 있다고 확신합니다.

누구든지 RFC 프로세스를 시작하고 싶습니까?

PowerShell이 ​​인수에 따옴표를 추가 할 필요가없는 경우 프로세스를 시작하기 위해 .Net 대신 P / Invoke를 사용하는 것이 좋습니다.

@lzybkr 내가 말할 수있는 한 PInvoke는 도움이되지 않습니다.
그리고 이것은 Unix와 Windows API가 다른 곳입니다.

https://msdn.microsoft.com/en-us/library/20y988d2.aspx (공백을 구분 기호로 처리)
https://linux.die.net/man/3/execvp (공백을 구분 기호로 취급하지 않음)

Windows 구현 변경을 제안하지 않았습니다.

여기서 플랫폼 별 동작을 피하려고합니다. 스크립트 이식성이 손상됩니다.
나는 우리가 깨지지 않는 방식으로 창 동작을 변경하는 것을 고려할 수 있다고 생각합니다. 즉, 선호 변수가 있습니다. 그리고 우리는 다른 기본값을 가질 수 있습니다.

우리는 외부 명령을 호출하는 것에 대해 이야기하고 있습니다-어쨌든 다소 플랫폼에 따라 다릅니다.

음, Windows와 Linux는 실행 파일을 호출하는 방법이 다르기 때문에 실제로 플랫폼 독립적 일 수는 없다고 생각합니다. Linux에서는 프로세스가 인수 배열을 가져 오는 반면 Windows에서는 프로세스가 단일 명령 줄 (하나의 문자열) 만 가져옵니다.
(더 기본적인 비교
CreateProcess -> 명령 줄 (https://msdn.microsoft.com/library/windows/desktop/ms682425)
과
execve -> 명령 배열 (https://linux.die.net/man/2/execve)
)

Powershell이 ​​인수에 공백이있을 때 이러한 따옴표를 추가함에 따라 powershell은 ** 방식으로 인수를 전달하려고 시도하고 CommandLineToArgvW 명령 줄을 원래 powershell에서 제공된 인수로 분할합니다. (이렇게하면 일반적인 c 프로그램은 powershell 함수가 $ args로 가져 오는 것과 동일한 인수를 argv 배열에서 가져옵니다.)
이것은 (p / invoke를 통해 제안 된대로) Linux 시스템 호출에 인수를 전달하는 것과 완벽하게 일치합니다.

** (따옴표를 이스케이프하지 않기 때문에 실패 함)

PS : RFC 프로세스를 시작하려면 무엇이 필요합니까?

정확히-PowerShell은 CommandLineToArgvW 가 올바른 명령을 생성하고 _after_ PowerShell이 ​​이미 구문 분석 한 내용을 다시 구문 분석하도록 시도합니다.

이것은 Windows에서 오랫동안 고통 스러웠던 점이었습니다. 나는 그 어려움을 * nix에 가져 가야 할 이유가 있다고 생각합니다.

나에게 이것은 RFC가 실제로 필요하지 않은 구현 세부 사항처럼 느껴집니다. Windows PowerShell에서 동작을 변경하면 RFC가 보장 될 수 있지만 올바른 변경은 (위험 할 수있는) 버그 수정으로 간주 될 수 있습니다.

예, 또한 Linux에서 직접 시스템 호출을 사용하도록 변경하면 모든 사람이 더 행복하게 느낄 것이라고 생각합니다.

여전히 창문에서도 변경해야한다고 생각합니다.
(어쩌면 스크립트를 변경하고 싶지 않은 사람들을 위해 환경 설정 변수를 추가하여)
지금은 틀 렸기 때문에 버그입니다. 이것이 수정 되었다면, 어떤 인수도 변경되지 않고 다음 프로세스에 도달 할 것이기 때문에 리눅스에서 직접 syscall이 필요하지 않을 것입니다.

그러나 CommandLineToArgvW 와 호환되지 않는 방식으로 명령 줄을 분할하는 실행 파일이 있으므로 @ be5invis 의 인수 연산자에 대한 아이디어가

이 문제는 누군가 PowerShell에서 다음 명령을 시도하고 작동하지 않았지만 CMD가 작동했을 때 PowerShell을 dissing했을 때 방금 발생했습니다.

wmic useraccount where name='username' get sid

PSCX echoargs에서 wmic.exe는 다음을 확인합니다.

94> echoargs wmic useraccount where name='tso_bldadm' get sid
Arg 0 is <wmic>
Arg 1 is <useraccount>
Arg 2 is <where>
Arg 3 is <name=tso_bldadm>
Arg 4 is <get>
Arg 5 is <sid>

Command line:
"C:\Users\hillr\Documents\WindowsPowerShell\Modules\Pscx\3.2.2\Apps\EchoArgs.exe" wmic useraccount where name=tso_bldadm get sid

그렇다면 CMD.exe는 프로세스를 호출하고 명령 줄을 구성하는 데 어떤 API를 사용합니까? 그 문제에 대해-%는이 명령을 작동시키기 위해 무엇을합니까?

@rkeithhill CreateProcessW . 직접 전화. 정말.

Powershell이이 두 상황에서 다르게 작동하는 이유는 무엇입니까? 특히, 공백을 포함하는 인수를 큰 따옴표로 묶어 일관성없이 래핑합니다.

# Desired argv[1] is 4 characters: A, space, double-quote, B
$ .\echoargs.exe 'A \"B'
<"C:\test\echoargs.exe" "A \"B">
<A "B>
# Correct!

# Desired argv value is 4 characters: A, double-quote, space, B
$ .\echoargs.exe 'A\" B'
<"C:\test\echoargs.exe" A\" B>
<A"> <B>
# Wrong...

운율이나 이유가없는 것 같습니다. 첫 번째 상황에서는 내 인수를 큰 따옴표로 감싸지 만 두 번째 상황에서는 그렇지 않습니다. 나는 때 정확히 알 필요가 내가 수동으로 스크립트 (여부) 포장 할 수 있도록 큰 따옴표로 포장하지 않습니다.

.echoargs.exe는 cl echoargs.c 다음을 컴파일하여 생성됩니다.

// echoargs.c
#include <windows.h>
#include <stdio.h>
int wmain(int argc, WCHAR** argv) {
    wprintf(L"<%ls>\n", GetCommandLineW());
    for(int i = 1; i < argc; i++) {
        wprintf(L">%s< ", argv[i]);
    }
    wprintf(L"\n");
}

편집 : 다음은 내 $ PSVersionTable입니다.

Name                           Value
----                           -----
PSVersion                      5.1.15063.296
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.15063.296
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

따옴표에 관한 동작이 여러 번 변경되었으므로 다음과 같이 사용하는 것이 좋습니다.

# call helper

function Run-Native($command) {
    $env:commandlineargumentstring=($args | %{'"'+ ($_ -replace '(\\*)"','$1$1\"' -replace '(\\*)$','$1$1') + '"'}) -join ' ';
    & $command --% %commandlineargumentstring%
}

# some test cases

Run-Native .\echoargs.exe 'A "B' 'A" B'
Run-Native .\echoargs.exe 'A "B'
Run-Native .\echoargs.exe 'A" B'
Run-Native .\echoargs.exe 'A\" B\\" \'

산출:

<"C:\test\echoargs.exe"  "A \"B" "A\" B">
<A "B> <A" B>

<"C:\test\echoargs.exe"  "A \"B">
<A "B>

<"C:\test\echoargs.exe"  "A\" B">
<A" B>

<"C:\test\echoargs.exe"  "A\\\" B\\\\\" \\">
<A\" B\\" \>

첫 번째 -replace 는 따옴표 앞의 백 슬래시를 이중으로하고 qoute를 이스케이프하기 위해 백 슬래시를 하나 더 추가합니다.
두 번째 -replace 는 인수 끝에 백 슬래시를 이중으로 표시하여 닫는 따옴표가 이스케이프되지 않도록합니다.

이것은 --% (PS v3 이상)를 사용하는데, 이는 AFAIK가 네이티브 실행 파일에 따옴표를 전달하는 유일한 방법입니다.

편집하다:

Run-Native 의 업데이트 된 버전, 이제 Invoke-NativeCommand ( 제안대로 )

function Invoke-NativeCommand() {
    $command, [string[]] $argsForExe = $args
    if($argsForExe.Length -eq 0){
        & $command
    } else {
        $env:commandlineargumentstring=($argsForExe | %{
            if($_ -match '^[\w\d\-:/\\=]+$'){
                $_ #don't quote nonempty arguments consisting of only letters, numbers, or one of -:/\=
            } else {
                $_ <# double backslashes in front of quotes and escape quotes with backslash #> `
                    -replace '(\\*)"','$1$1\"' `
                   <# opening quote after xxx= or after /xxx: or at beginning otherwise #> `
                    -replace '^([\w\d]+=(?=.)|[/-][\w\d]+[:=](?=.)|^)','$1"' `
                   <# double backslashes in front of closing quote #> `
                    -replace '(\\*)$','$1$1' `
                   <# add closing quote #> `
                    -replace '$','"'
            }
        }) -join ' ';
        & $command --% %commandlineargumentstring%
    }
}

( iep 에서 영감을

• 간단한 스위치를 인용하지 않음
• 여전히 빈 인수로 작동합니다.
• 인수가 없으면 작동합니다.
• 대부분 msiexec, cmdkey 등과 함께 작동해야합니다.
• 여전히 공통 규칙 을 따르는 프로그램에서 작동합니다.
• 비표준 "" 를 이스케이프 된 " 하지 않습니다. 따라서 .bat 또는 msiexec 인수에 포함 된 따옴표에 대해서는 여전히 작동하지 않습니다.

감사합니다. --% 대해 몰랐습니다. 환경 변수를 기본 프로세스에 유출하지 않고 수행 할 수있는 방법이 있습니까? (및 호출 할 수있는 모든 프로세스)

모든 사람이 사용할 수있는 Run-Native Cmdlet을 구현하는 PowerShell 모듈이 있습니까? 이것은 Powershell Gallery에 있어야 할 것 같습니다. 충분하다면 RFC의 기초가 될 수 있습니다.

"누수"는 보안에 대해 우려하는 것 같습니다. 그러나 명령 줄은 어쨌든 자식 프로세스에 표시됩니다. (예 : Windows의 경우 gwmi win32_process |select name,handle,commandline|Format-Table ps -f , Linux의 경우

그래도 환경 변수를 피하고 싶다면 invoke-expression을 사용하여 무언가를 생성 할 수 있습니다.

RFC 관련 :
나는 그러한 커맨드 렛이 필요하다고 생각하지 않고 대신 이것이 기본 동작이어야합니다.

https://github.com/PowerShell/PowerShell-RFC/issues/90

PowerShell의 기본 동작을 수정해야한다는 데 동의합니다. 나는 그것이 이전 버전과의 호환성 때문에 결코 변하지 않을 것이라고 비관적으로 생각하고 있었기 때문에 모듈 작성을 제안했습니다. 그러나 RFC에서 이전 이스케이프 동작을 기본 설정 변수를 통해 다시 활성화 할 수있는 방식이 정말 마음에 듭니다.

적절한 의견으로 토론을 요약하겠습니다.

• 이전 버전과의 호환성 문제가 있음이 분명하므로 이전 동작을 계속 사용할 수 있어야합니다.

• @TSlivede 의 RFC 제안 은 _ 미래로가는 길 _을 칭찬 할 만하게 가리키면서이를 설명합니다.
  안타깝게도 그의 제안은이 글을 쓰는 시점에서 _PR_로 표시되고 있으며 아직 RFC _draft_로 승인되지도 않았습니다.

_ 미래 _는 다음을 의미합니다.

• PowerShell은 곧 cmd.exe 관련 수하물을 제거 할 자체 셸이므로 외부 유틸리티 (일반적으로 콘솔 / 터미널 애플리케이션 인 실행 파일)를 호출 할 때 고려해야 할 유일한 사항은 다음과 같습니다. :

  • 전달할 인수는 _PowerShell_의 인수 모드 구문 분석 _only_의 규칙에 따라 지정되어야합니다.

  • 해당 프로세스의 _literals_ 결과는 _individual_ 인수로 대상 실행 파일에 _as-is_로 전달되어야합니다.

  • 즉, 사용자로서 집중해야 할 것은 _PowerShell_의 구문 분석 결과가 무엇인지, 그리고 PowerShell이 ​​모든 배후를 처리하여 전달되는 결과에 의존 할 수있는 것입니다. -장면 인코딩-필요한 경우.

_ 구현 _ 미래 :

• _Windows_에서 :

  • _historical_ 이유로 Windows는 대상 실행 파일에 _ 리터럴 배열로 인수를 전달하는 것을 허용하지 _ 않습니다 _. 대신 _pseudo 쉘 구문 _을 사용하여 _all_ 인수를 인코딩하는 _single_ 문자열이 필요합니다. 더 나쁜 것은 단일 문자열을 해석하고 인수로 분할하는 것은 궁극적으로 개별 대상 실행 파일에 달려 있다는 것입니다.

  • PowerShell이 ​​할 수있는 가장 좋은 방법은 명령 줄을 _predictable, 표준화 된 방식으로 _own_ 개별 인수로 분할 한 후 백그라운드에서 단일 문자열을 형성하는 것입니다.

  • @TSlivede 의 RFC 제안 은 PowerShell 이 구문 분석을 수행 할 때 Windows C / C ++ 런타임이 입력 인수를있는 그대로 복구하도록 하는 방식으로 의사 셸 명령 줄을 합성하도록 제안함으로써 다음과 같이 제안합니다.

    • 명령 줄을 해석하는 것이 궁극적으로 각 대상 실행 파일에 달려 있다는 점을 감안할 때, 이것이 모든 경우에 작동 할 것이라는 _ 보장 _은 없지만 _most_ 기존 유틸리티가 이러한 규칙을 사용하기 때문에 규칙이 가장 합리적인 선택입니다.

    • 유일하게 주목할만한 예외는 RFC 제안에서 제안한대로 특수 처리를받을 수있는 _batch files_입니다.

• _Unix_ 플랫폼 :

  • 엄밀히 말하면, 플랫폼 네이티브가 새 프로세스를 생성하기위한 _ 인수를 리터럴 배열로 허용 _-PowerShell이 ​​_own_ 파싱을 수행 한 후 끝나는 인수는 _as-is_에 전달되어야하기 때문에 Windows 인수 구문 분석을 괴롭히는 문제는 _ 절대 발생하지 않습니다 _. .
    @lzybkr 을 인용

  • 슬프게도 .NET Core (CoreFX)의 현재 제한으로 인해 이러한 문제가 발생합니다. CoreFX API가 _Windows_ 인수의 무정부 상태를 Unix 세계로 전달하도록 강제하기 때문에 유닉스.

  • 저는 이 CoreFX 이슈 를 만들어 그 문제가

  • 그 동안 CoreFX가 위에서 언급 한 C / C ++ 규칙을 기반으로 의사 명령 줄을 다시 인수로 분할하므로 @TSlivede 의 제안은 Unix 플랫폼에서도 작동해야합니다.

https://github.com/PowerShell/PowerShell/issues/4358 이 이것의 중복으로 종료되었으므로 여기에 해당 문제에 대한 간단한 요약이 있습니다.

후행 백 슬래시가있는 외부 실행 파일의 인수에 공백이 포함 된 경우 현재 순진하게 인용됩니다 (인수 앞뒤에 인용 부호 추가). 일반적인 규칙 을 따르는 모든 실행 파일은 다음과 같이 해석됩니다.
_{@ mklement0 의 의견에서 :}

앞에 오는 ".\test 2\" 의 두 번째 " 는 이스케이프 된 "로 해석되어 문자열의 나머지 부분이 발생합니다. 논의.

예:
_{( @akervinen 의 코멘트에서 )}

PS X:\scratch> .\ps-args-test.exe '.\test 2\'
인수 인수 : .\test 2"

PSReadLine은 디렉토리의 자동 완성에 후행 백 슬래시를 추가하기 때문에 문제가 매우 자주 발생합니다.

corefx는 우리가 필요로하는 API를 생성하는 데 열려있는 것처럼 보이므로 이것을 6.1.0으로 연기합니다. 6.0.0의 경우 # 4358을 수정할 수 있는지 확인하겠습니다.

@TSlivede 함수를 가져 와서 Invoke-NativeCommand 로 이름을 바꾸고 ( Run 는 유효한 동사가 아니므로) 별칭 ^ 하고 PowerShellGallery에 모듈로 게시했습니다.

install-module NativeCommand -scope currentuser
^ ./echoargs 'A "B' 'A" B'

@ SteveL-MSFT :

임시 방편을 갖는 것은 좋지만, CoreFX 솔루션을 기다리는 동안 @TSlivede 의 RFC 제안에 미리

\" 문제 만 수정 하면 다음과 같은 간단한 시나리오에서도 인수 전달이 근본적으로 중단됩니다.

PS> bash -c 'echo "hi there"'
hi    # !! Bash sees the following tokens:  '-c', 'echo hi', 'there'

이 시점에서 행동이 무엇인지에 대한 충분한 동의가 있다고 생각하므로 전체 RFC 프로세스가 필요하지 않습니다.

유일하게 뛰어난 결정은 _Windows_에서 이전 버전과의 호환성 문제를 처리하는 방법입니다.

@ mklement0 @ SteveL-MSFT
우리는 이미 호환성을 깨고 있습니까?

유일한 뛰어난 결정은 Windows에서 이전 버전과의 호환성 문제를 처리하는 방법입니다.

그래,하지만 그게 어려운 부분이지?

@ be5invis "이미 호환성이 깨졌다"는 의미는 무엇입니까?

또한 CoreFX가 레이어에서 수정이 임박한 경우 레이어에 임시 공간을 만들지 않는 것이 좋습니다.

그리고 누군가가 스레드에서 위에서 말했듯이 이것은 성가신 일이지만 커뮤니티에서 꽤 잘 문서화되어 있습니다. 다음 두 번의 릴리스에서 두 번 중단해야할지 모르겠습니다.

@joeyaiello :

# 4358에 대한 수정은 최종 \ 를 두 배로 늘림으로써 문제를 해결 한 사람들에게 이미 큰 변화가 아닌가? 예 : "c:\tmp 1\\" ? 즉,이 수정 사항에 대한 변경 사항을 제한하면 _two_ 주요 변경 사항이 보장됩니다.이 변경 사항은 지금 당장, 나중에 CoreFx API로 전환 한 후입니다. 그리고 지금 완전한 임시 방편이 구현된다면 그 _ 가능 _ 함 _이 일어날 수 있지만, 우리가이 다가오는 변화에 대해 알고있는 것을 감안할 때 가능성이 낮습니다.

반대로, 다음과 같은 일반적인 인용 시나리오의 경우 Unix에서의 채택을 방해 할 수 있습니다.
bash -c 'echo "hi there"' 이 제대로 작동하지 않습니다.

그러나 이것을 고치는 것이 훨씬 더 큰 주요 변경 사항이라는 것을 알고 있습니다.

@ PowerShell / powershell-committee는 이에 대해 논의하고 최소한 --% 를 사용하는 것은 따옴표가 이스케이프되어 네이티브 명령이 수신하도록 bash와 동일한 동작을 가져야한다는 데 동의했습니다. 토론을 위해 아직 열려있는 것은 이것이 --% 사용하지 않고 기본 동작이어야하는지 여부입니다.

노트 :

• _Windows_에서 일어나는 셸 동작을 _emulate_하려는 것과는 반대로 _Unix_에서 --% 를 사용할 때 실제 셸 실행 파일에 대한 호출이 필요하다고 가정하고 있습니다. 에뮬레이션은 Windows에서 어렵지 않지만 에뮬레이션이 필요한 더 많은 기능을 고려할 때 Unix에서는 훨씬 더 어렵습니다.

• 실제 셸을 사용하면 어떤 셸을 사용할 지에 대한 질문이 제기됩니다. bash 은 어디에나 있지만 기본 동작은 POSIX와 호환되지 않으며 POSIX에서 필요하지도 않습니다. 따라서 이식성을 위해 다른 스크립팅 언어는 다음을 호출합니다. /bin/sh , POSIX에서 선언 한 쉘 실행 파일 (호환성 모드 (예 : macOS)에서 실행중인 Bash 일 수 있지만 반드시 그럴 필요는 없습니다 (예 : Ubuntu의 Dash)).

틀림없이 우리는 /bin/sh 도 타깃팅해야합니다. 그러나 이는 Bash 기능 (특히 중괄호 확장, 특정 자동 변수 등)을 사용할 수 없음을 의미합니다.

--%

아래 예제로 echoargs --% 'echo "hi there"' 명령을 사용하겠습니다.

따옴표가 이스케이프되어 네이티브 명령이 수신한다는 점에서 bash와 동일한 동작입니다.

CoreFX API가 확장되면 _ 향후에 수행하는 방법은 이스케이프를 전혀 수행하지 않고 대신 다음을 수행하는 것입니다.

• 다음과 같이 프로세스를 만듭니다.
  
  
  
  • /bin/sh 실행 파일로, (효과적으로) ProcessStartInfo.FileName 할당됩니다.
  
  
  • ProcessStartInfo.ArgumentList 와 같은 _literal_, _individual_ 인수 토큰의 다음 배열 :
  
  
  • 첫 번째 인수로 -c
  
  
  • 두 번째 인수로 echoargs 'echo "hi there"' -즉, 원래 명령 줄은 --% 가 제거 된 것을 제외하고 지정된대로 _literally_를 사용했습니다.
  
  

실제로 명령 줄은 _as-is_를 통해 셸 실행 파일로 전달 된 다음 _its_ 구문 분석을 수행 할 수 있습니다.

현재 리터럴 인수를 전달하는 배열 기반 방법이없는 상황에서 -c 및 echoargs 'echo "hi there"' 를 _single_ string _with escaping_으로 결합해야합니다. 유감스럽게도 _ 오직 CoreFX API_는 실제 프로세스를 생성 할 때이 단계를 _reverses_하고 단일 문자열을 리터럴 토큰으로 다시 분할합니다.이 반전이 항상 리터럴 토큰의 원래 목록이되도록 보장하는 것은 어려운 부분입니다.

다시 말하지만, 여기서 탈출하는 유일한 이유는 현재 CoreFX 제한 때문입니다.
이 제한을 해결하려면 다음과 같은 단일 이스케이프 문자열을 ProcessStartInfo 인스턴스의 .Arguments 속성에 할당해야하며 이스케이프는 C ++ 명령 줄 인수 구문 분석에 지정된대로 수행해야합니다.

• /bin/sh 실행 파일로, (효과적으로) ProcessStartInfo.FileName 할당됩니다.
• ProcessStartInfo.Arguments 값으로 이스케이프 처리 된 다음 단일 문자열 :
  -c "echoargs 'echo \"hi there\"'"

## 기본 동작

논쟁의 여지가있는 것은 이것이-%를 사용하지 않고 기본 동작이어야하는지 여부입니다.

Unix의 기본 동작은 매우 달라야합니다.

• _PowerShell 자체 이외의 이스케이프 고려 사항 은 작동하지 않아야합니다 (슬프게도 피할 수없는 _Windows_는 예외입니다.하지만 MS C ++ 규칙은 _ 뒤에서 적용 할 수 있습니다 _; 실패, --% 는 탈출 해치를 제공합니다).

• 자체 구문 분석 후 _PowerShell_이 끝나는 인수가 무엇이든 다가오는 ProcessStartInfo.ArgumentList 속성을 통해 _ 리터럴의 _array_ 배열로 전달되어야합니다 .

--% 없이 예제에 적용됨 : echoargs 'echo "hi there"' :

• PowerShell은 일반적인 구문 분석을 수행하고 다음 두 인수로 끝납니다.

  • echoargs
  • echo "hi there" (작은 따옴표-_PowerShell_에 대한 구문 기능 만 포함, 제거됨)

• ProcessStartInfo 가 다음과 같이 채워지고 곧 출시 될 CoreFX 확장이 적용됩니다.

  • echoargs 제 (유효) 등 .FileName 속성 값
  • .ArgumentList 의해 노출 된 Collection<string> 인스턴스에 추가 할 유일한 요소로 _Literal_ echo "hi there" .ArgumentList .

다시 말하지만, .ArgumentList 옵션이없는 경우 _yet_하지만 _ 중간에 _ 위에서 설명한 것과 동일한 MS C ++ 호환 보조 이스케이프를 사용할 수 있습니다.

@ SteveL-MSFT
Make the stop-parsing symbol (-%) work on Unix (# 3733) 에서 이미 언급했듯이 --% 의 동작을 변경하지 않는 것이 좋습니다.

/bin/sh -c 대한 특별한 기능이 필요한 경우 다른 기호 를 사용하고 --% 그대로 두십시오!

@TSlivede :

_If_ something --% -_like_는 Unix에서 구현됩니다-네이티브 globbing과 일반적으로 Unix에서 명령 줄에 정통한 군중을 사용하면 필요가 적다고 느낍니다. 그런 다음 --$ 와 같은 _ 다른 기호 _를 선택합니다

다른 기호는 또한 이식 불가능한 _ 플랫폼 별 _ 동작이 호출되고 있음을 시각적으로 눈에 띄는 알림 역할을합니다.

그 잎이가 건너 올 때 PowerShell에서 무엇을해야하는지 질문 --% 유닉스와 --$ Windows에서.

--% 그대로 두어도됩니다. / bin / sh를 호출하는 --$ 와 같은 것을 도입하면 Windows에서 cmd.exe가이 문제를 해결하는 좋은 방법이라고 생각합니다.

이러한 동작에 대한 cmdlet을 만들 수 없습니까?

@iSazonov 당신은 Invoke-Native 같은 것을 제안하고 있습니까? 내가 그 팬인지 확실하지 않습니다.

예, Start-Native 처럼.
농담으로 :-), PowerShell의 cmdlet을 좋아하지 않습니까?

Build.psm1에는 https://mnaoumov.wordpress.com/2015/01/11/execution-of-external-commands-in-powershell-done-right/에 대한 링크가있는 Start-NativeExecution 이 있습니다.

@ SteveL-MSFT

-% 그대로 두어도 괜찮습니다.

나는 우리 모두가 --% 이 _Windows_에서하는 방식대로 계속 작동해야한다는 데 동의한다고 생각합니다.

대조적으로 _Unix_에서는이 동작이 의미가 없습니다. 제가 여기서 보여 주려고했던 것처럼 요약하면 다음과 같습니다.

• 작은 따옴표가 올바르게 처리되지 않습니다.
• 환경 변수를 참조하는 유일한 방법은 _cmd.exe-style_ ( %var% )입니다.
• 글 로빙 및 단어 분할과 같은 중요한 기본 기능은 작동하지 않습니다.

--% 를 도입 한 주된 동기는 내가 올바르게 이해한다면 _ 기존 cmd.exe 명령 줄을 그대로 _ 재사용 할 수 있도록하는 것이 었습니다.

• 따라서 --% 는 현재 동작으로 Unix에서 쓸모가 없습니다.
• _ 유닉스에서 _analogous_ 기능을 원했다면 위에서 제안한 것처럼 /bin/sh -c 기반이어야하며 아마도 다른 기호를 사용했을 것입니다.

Windows에서 cmd /c 기반 기능이 필요하지 않다고 생각합니다. --% 에는 _ 대부분 _ _ 충분히 좋은 방식으로 다루어지기 때문입니다.
@TSlivede 는 모든 셸 기능이 에뮬레이션되는 것은 아니지만 실제로는 문제가되지 않는 것으로 보입니다 (예 : %envVar:old=new% 와 같은 변수 값 대체는 지원되지 않음, ^ 이스케이프 문자가 아니며 --% 은 _single_ 명령으로 제한됩니다.- cmd.exe 의 리디렉션 및 제어 연산자를 사용하지 않습니다. 즉, --% 라고 생각하지 않습니다

따라서 --$ -구현 된 경우-는 Unix _counterpart_ ~ --% 입니다.

어쨌든 최소한 about_Parsing 도움말 항목 은 --% 가 몇 가지 경우를 제외하고 쓸모가 없다는 눈에 띄는 경고를받을 자격이 있습니다 .

@iSazonov 특정 시나리오를 처리하기 위해 Start-Native 를 사용하는 것이 합리적 일 수 있지만 기본 exe를 사용하는 것이 더 자연스럽고 예측 가능하도록 PowerShell을 개선해야합니다.

@ PowerShell / powershell-committee는이 내용을 검토했으며 --% 은 인수를 관련 플랫폼에서와 같이 처리해야한다는 데 동의했습니다. 즉, Windows와 Linux에서는 다르게 동작하지만 Windows에서는 일관되고 Linux에서는 일관됩니다. 새로운시길을 도입하는 것은 사용자에게 더 혼란 스러울 것입니다. 이를 활성화하는 방법은 엔지니어에게 맡기겠습니다.

크로스 플랫폼 스크립트는 이러한 동작의 차이를 인식해야하지만 사용자가 이것을 칠 것 같지는 않습니다. 사용자 피드백이 더 많은 플랫폼 간 사용으로 인해 필요하다는 의견이라면 새로운시길을 다시 소개 할 수 있습니다.

두 번째로 나는 ripgrep을 사용할 때 이러한 네이티브 vs cmdlet 문자열 인수 구문 분석 차이에

다음은 powershell 호출의 결과입니다 (echo.exe는 "C : Program FilesGitusrbinecho.exe"에서 가져옴).

이제이 " 해야한다는 것을 알고 있습니다.

> echo.exe '"test'
test

하지만이 기이함은 나를 넘어선 다 ...

echo.exe '^\+.+;'
^\+.+;
echo.exe '^\+.*;'
^+.*;

두 번째 경우에는 \ 를 기본 명령에 전달하기 위해 \ 를 두 번 넣어야합니다. 첫 번째 경우에는 할 필요가 없습니다 😑

나는 이것이이 동작을 변경하는 주요 변경 사항이므로 cmlet과 기본 명령 사이에 차이가 없다는 것을 이해합니다. 그러나 나는 이와 같은 기이 한 점이 사람들이 powershell을 기본 셸로 사용하지 못하게하는 것이라고 생각합니다.

@mpawelski 방금 git 2.20.1.vfs.1.1.102.gdb3f8ae를 사용하여 Windows 상자에서 이것을 시도했지만 6.2-RC.1에서는 재현되지 않습니다. 여러 번 실행했는데 지속적으로 ^\+.+; 에코

@ SteveL-MSFT, @mpawelski가 실수로 동일한 명령을 두 번 지정했다고 생각합니다. 예를 들어 '^\"+.*;' 를 전달하면 문제가 발생합니다.- \" 부분에 유의하십시오. , 따라서 외부 대상 프로그램은 ^\"+.*; 를 인수 값으로 간주합니다.

# Note how the "\" char. is eaten.
PS> bash -c 'printf %s "$1"' - '^\"+.*;'
^"+.*; 

#"# Running the very same command from Bash does NOT exhibit the problem:
$ bash -c 'printf %s "$1"' - '^\"+.*;'
^\"+.*; 

-%는 내가 올바르게 이해한다면 기존 cmd.exe 명령 줄을있는 그대로 재사용 할 수 있도록했습니다.

그것은 정답이 아닙니다. --% 는 많은 Windows 명령 줄 유틸리티가 유틸리티 호출을 완전히 방해하는 PowerShell에 의해 해석되는 인수를 사용하기 때문에 도입되었습니다. 좋아하는 기본 유틸리티를 더 이상 쉽게 사용할 수 없다면 사람들을 빨리 사로 잡을 수 있습니다. 이 문제로 인해 제대로 작동하지 않는 SO 및 기타 RE 네이티브 exe 명령에 대한 질문에 답할 때마다 1/4이 있다면 Qoba에서 가족과 함께 저녁 식사를 할 수있을 것입니다. :-) 예를 들어, tf.exe 는 작업 공간 지정의 일부로 ; 를 허용합니다. Git은 {} 및 @~1 등을 허용합니다.

--% 는 PowerShell에 명령 줄의 나머지 부분을 구문 분석하지 않도록 지시하기 위해 추가되었습니다. "있는 그대로"기본 exe로 보내기 만하면됩니다. 한 번만 문질러 cmd env var 구문을 사용하여 변수를 허용하십시오. 약간 못 생겼지 만 Windows에서는 정말 유용합니다.

RE를 cmdlet으로 만들었지 만 어떻게 작동하는지 잘 모르겠습니다. --% 는 파서에게 EOL까지 파싱을 멍청하게하는 신호입니다 ..

솔직히 말해서, PowerShell과 특히이 기능의 오랜 사용자로서 다른 플랫폼에서 동일한 연산자를 사용하여 EOL까지 구문 분석을 간단히 의미하는 것이 좋습니다. 어떤 형태의 변수 대체를 허용하는 방법에 대한 문제가 있습니다. 약간 못 생겼지 만 macOS / Linux에서는 % envvar %를 사용하여 해당하는 env var의 값으로 대체 할 수 있습니다. 그런 다음 플랫폼간에 이식 할 수 있습니다.

문제는이 작업을 수행하지 않으면 조건부 코드로 끝납니다-정확히 내가 휴대용이라고 부르는 것이 아닙니다.

$env:Index = 1
if ($IsWindows) {
    git show --% @~%Index%
}
else {
    git show --$ @~$Index
}

모든 플랫폼에서이 작업을 선호합니다.

$env:Index = 1
git show --% @~%Index%

Windows의 동작은 호환성 때문에 그대로 유지되어야합니다.

뿡뿡

그것은 정답이 아닙니다.

제거 과정 에서 Windows 세계에서 PowerShell 이전의 명령 줄은 cmd.exe - 로 작성되었으며, 다음과 같이

• --% 확장 cmd.exe -style %...% 환경 변수 참조 (예 : %USERNAME% (셸 및 특수 논리가 관련되지 않은 경우 이러한 토큰이 전달됨) _verbatim_)

• PowerShell의 입에서 직접 (원하는 경우, 강조 추가됨) :

웹은 Cmd.exe 용으로 작성된 명령 줄로 가득 차 있습니다. 이러한 명령 줄은 PowerShell에서 자주 작동하지만 세미콜론 (;), 달러 기호 ($) 또는 중괄호와 같은 특정 문자를 포함하는 경우에는 약간의 따옴표를 추가하여 변경해야합니다. 이것은 많은 사소한 두통의 원인 인 것 같습니다.

이 시나리오를 해결하기 위해 명령 줄 구문 분석을 "이스케이프"하는 새로운 방법을 추가했습니다. 매직 매개 변수-%를 사용하면 명령 줄의 일반적인 구문 분석을 중지하고 훨씬 더 간단한 것으로 전환합니다. 우리는 따옴표와 일치하지 않습니다. 세미콜론에서 멈추지 않습니다. PowerShell 변수는 확장하지 않습니다. Cmd.exe 구문 (예 : % TEMP %)을 사용하는 경우 환경 변수를 확장합니다. 그 외에는 줄의 끝 (또는 파이프 인 경우 파이프)까지 인수가 그대로 전달됩니다. 예를 들면 다음과 같습니다.

이 접근 방식은 _Unix_ 세계에 적합하지 않습니다 (위에서 요약).

• *.txt 와 같이 인용되지 않은 인수의 글 로빙은 작동하지 않습니다.

• 유닉스 세계의 전통적인 (POSIX 유사) 쉘은 환경 변수를 참조하기 위해 %...% 를 사용하지 _ 않습니다 _. $... 구문이 필요합니다.

• (다행히) Unix 세계에는 _raw_ 명령 줄이 없습니다. 모든 외부 실행 파일은 _literals_의 _array_를 전달해야하므로 명령 줄을 먼저 인수로 구문 분석해야하는 것은 여전히 ​​PowerShell 또는 CoreFx입니다.

• Unix 세계의 기존 (POSIX 유사) 쉘은 --% 인식하지 못하는 '...' (작은 따옴표) 문자열을 허용합니다. # 10831을 참조하십시오.

그러나 Windows 세계에서도 --% 에는 심각하고 분명하지 않은 제한이 있습니다 .

• 가장 분명하게는 --% 를 사용하면 명령 줄에서 PowerShell 변수를 직접 참조 할 수 없습니다. 유일한 해결 방법은 _environment_ 변수를 임시로 정의하는 것입니다. 그런 다음 %...% 로 참조해야합니다.
• (...) -닫는 ) 는 명령 줄의 리터럴 부분으로 해석되므로 명령 줄을 (...) 묶을 수 없습니다.
• ; 및 다른 문으로 명령 줄을 따라갈 수 없습니다. ; 는 명령 줄의 리터럴 부분으로 해석되기 때문입니다.
• } 닫기는 명령 줄의 리터럴 부분으로 해석되기 때문에 한 줄 스크립트 블록 내에서 --% 사용할 수 없습니다.
• 리디렉션을 사용할 수 없습니다-명령 줄의 리터럴 부분으로 처리되기 때문에-그러나 cmd --% /c ... > file 를 사용하여 cmd.exe 에서 리디렉션을 처리하도록 할 수 있습니다.
• 줄 연속 문자는 사용할 수 없습니다. PowerShell ( ` ) 또는 cmd.exe ( ^ ) 모두 _literals_로 처리됩니다.
  
  
  
  • --% 는 줄 끝까지 만 (최대) 파싱합니다.
  
  

다행히도 우리는 이미 크로스 플랫폼 구문을 가지고 있습니다 : _PowerShell의 자체 구문 _.

예,이를 사용하려면 _PowerShell_이 메타 문자를 고려하는 것이 무엇인지 알아야합니다. 이는 cmd.exe 및 Bash와 같은 POSIX 유사 쉘이 메타 문자를 고려하는 것 모두의 _superset_입니다. 불가지론적인 명령 줄 경험.

그렇다면 PowerShell이 " 문자의 인용을 너무 잘못 처리하는 것은 얼마나 안타까운 이며이 문서 문제에 요약되어 있습니다.

@rkeithhill , 저는 약간의 접선을 시작했습니다. 닫아 보겠습니다.

• --% 실제로 이미 _is_ PowerShell Core 6.2.0부터 구현되었습니다. 예 :
  /bin/echo --% %HOME% 환경 변수의 값을 인쇄합니다 HOME ; 대조적으로
  /bin/ls --% *.txt 는 *.txt 가 리터럴로 전달되기 때문에 예상대로 작동하지 않습니다.

• 궁극적으로 --% 사용하지 않을 때, 우리는 사용자가 _ 배후에서 구성되는 명령 줄 / 인수 배열이 궁극적으로 _ 어떻게 보이는지 진단하도록 도와야합니다 (이는 우리를 유서 깊은 # 1761로 되돌립니다).

  • 당신의 도움이되는 echoArgs.exe 가 바로 그 역할을하며, 연결된 문제에서 이러한 기능이 PowerShell 자체의 일부가되도록 현명하게 호출했습니다.
  • @ SteveL-MSFT는 오류 레코드에 결과 명령 줄을 포함하여 고민했습니다.

마지막으로, PowerShell의 자체 구문을 본질적으로 이식 가능한 구문으로 사용하여 이전 주장을 예제에 적용하려면 다음을 수행하십시오.

# Works cross-platform, uses PowerShell syntax 
# Note: No need for an aux. *environment* variable (which should be cleaned up afterward)
$Index = 1
git show "@~$Index"

# Alternative, quoting just the '@'
git show `@~$Index

예, 토큰 이니셜 @ 는 인용해야하는 메타 문자라는 것을 알아야하지만 PowerShell이 ​​더 널리 사용됨에 따라 이러한 요구 사항에 대한 인식도 더 널리 퍼져 야합니다.

참고로,이 문제는 Windows 및 Unix 계열에서 거의 동일합니다. Unix SDProcess의 CoreFx 구현에는 ParseArgumentsIntoList 라는 것이 있습니다. CommandLineToArgvW _setargv 스위치없이 거의 정확하게 구현됩니다 (그리고 문서화되지 않은 "" 는 따옴표로 묶음 → " 기능). 유닉스는 현재의 형태에서 Windows와 같은 방식으로 깨지기 때문에 추가적인 고통의 포인트가되어서는 안됩니다.

_setargv 는 결국 모든 프로그램이 사용하는 것이 아니며 CRT 버전 간의 동작 변화에 영향을 받기 때문에 고려할 가치가 없을 것입니다. 우리가 할 수 있고해야 할 최선은 모든 것을 큰 따옴표로 묶고 멋진 백 슬라를 추가하는 것입니다. 그게 전부입니다.

인수가 올바르게 구문 분석되지 않는 또 다른 예 :

az "myargs&b"

이 경우 az는 myargs 가져오고 b 새 명령으로 실행하려고합니다.

해결 방법 : az-% "myargs & b"

@ SteveL-MSFT, 필수 기능인 컬렉션 기반 ProcessStartInfo.ArgumentList 속성이 .NET Core 2.1 이후로 제공되었으므로 Waiting - DotNetCore 레이블을 제거 할 수 있습니다.

@TSlivede 는 새로운 방법을 알고 있으며이를 사용할 계획이지만 관련 RFC 인 https://github.com/PowerShell/PowerShell-RFC/pull/90 은 안타깝게도 나 빠지고 있습니다.

_ 구현 _ 토론을 계속할 것을 제안합니다.

그러나 RFC 토론에서 @joeyaiello 는 변경 사항을 실험적 기능으로 만드는 것에 대해 이야기하지만 기존 코드를 크게 깨뜨리지 않고는 인용 동작을 수정할 수 없다는 것이 점점 분명 해지고 있습니다.

_ 일을해야했던 모든 사람 :

• 빈 문자열 인수를 전달할 수 없음 ( foo.exe "" 현재 _no_ 인수 전달)
• 삽입 된 큰 따옴표의 자동 이스케이프가 없기 때문에 예상치 못한 효과적인 큰 따옴표 제거 ( foo.exe '{ "foo": "bar" }' 가 부적절하게 이스케이프 처리 된 것으로 전달됨 "{ "foo": "bar" }" )
• 특정 인수를 허용하지 않는 msiexec 와 같은 특정 CLI의 단점은 _ 전체적으로 _ 큰 따옴표로 묶여 있습니다 ( foo.exe foo="bar none" 는 "foo=bar none" 로 전달됨).
  참고 : 여기서 책임이있는 것은 msiexec 이며 제안 된 변경 사항이 적용된 경우 필요한 foo="bar none" 견적 양식을 전달하면 --% 합니다.

제안 된 변경 사항이 적용된 해결 방법이 _break_되므로 문제가 될 것입니다.

따라서 추가 질문은 다음과 같습니다.

• 최소한 _opt-in_ 기능으로 올바른 동작을 사용하려면 어떻게해야합니까?

  • Start-Process 로 깨진 인용문의 경우, 우리는 적어도 올바른 동작을위한 새로운 매개 변수를 도입 할 수있는 옵션이 --% ).

• 이러한 메커니즘의 근본적인 문제는 일반적으로 기본 설정 변수에 의해 발생하지만 점점 더 증가하는 using 문에 의해 발생합니다. PowerShell의 동적 범위 지정입니다. 즉, 옵트 인 동작은 기본적으로 _from_ one의 옵트 인 코드라는 코드에도 적용되므로 문제가 있습니다.

  • 아마도 _lexical_ 기능 범위 지정, @lzybkr이 작성한-동등하게 쇠약해진- 어휘 엄격 모드 RFC 에서 어휘 범위가 지정된 using strict 제안의 일반화를 일반적으로 도입 할 때입니다.

  • 어휘 범위 using preference ProperArgumentQuoting 와 같은 것? (명백하게 협상 가능한 이름이지만 하나를 찾기 위해 고군분투하고 있습니다.)

이러한 모든주의 사항과 이것이 직접 호출의 문제이기도하므로 단순히 새 매개 변수를 추가 할 수 없다는 점을 감안할 때, 저는 이전 동작을 깨는 것을 강력히 찬성합니다.

예, 아마 많이 깨질 것입니다. 그러나 실제로는 처음부터 완전히 깨 졌기 때문입니다. 나는 _ 실제로 작동하는 _ 기능을 갖는 것보다 고장난 행동에 대한 엄청난 양의 해결 방법을 유지하는 것을 우선시하는 것이 특히 타당하지 않다고 생각합니다.

새로운 메이저 버전으로서 저는 v7이이 상황을 꽤 오랫동안 적절하게 수정할 수있는 유일한 기회라고 생각하며 기회를 가져야합니다. 사용자에게 알리면 전환이 전반적으로 제대로 이루어지지 않을 것이라고 생각합니다.

브레이킹 체인지가 불가피하다고 느낀다면 대화 형 세션에서 쉽게 인쇄 할 수 있어야하고 모든 플랫폼에서 더 잘 작동하는 스크립트 버전을 가질 수 있다는 점을 고려하여 이상적인 솔루션을 설계해야합니다.

동의 함, @ vexx32 : 기본적으로 만 기존 동작을 유지하는 것은

외부 프로그램에 인수를 안정적으로 전달하지 않는 쉘은 핵심 명령 중 하나에 실패합니다.

당신은 확실히 브레이킹 체인지에 대해 _my_ 투표권을 가지고 있지만, 특히 v7이 장기 WinPS 사용자가 PSCore로 마이그레이션 할 수 있다고 선전되고 있기 때문에 다른 사람들이 다르게 느끼게 될 것이 두렵습니다.

@iSazonov : https://github.com/PowerShell/PowerShell-RFC/pull/90 은 올바른 솔루션을 설명합니다.

그 정신을 요약하려면 :

PowerShell은 셸로서 _its_ 규칙에 따라 인수를 구문 분석 한 다음 결과로 확장 된 인수 값 _verbatim_을 대상 프로그램에 전달해야합니다. 사용자는 PowerShell이 ​​어떻게 작동하는지에 대해 생각할 필요가 없습니다. 그들이 걱정해야 할 것은 _PowerShell_ 구문을 올바르게 얻는 것입니다.

• Unix와 같은 플랫폼에서 ProcessStartInfo.ArgumentList 는 확장 된 인수 값의 _array_가 대상 프로그램에 _as-is_로 전달 될 수 있다는 점을 감안할 때이를 완벽하게 구현할 수있는 방법을 제공합니다. 이 세상에서.

• Windows에서는 Windows 명령 줄 구문 분석 인 ProcessStartInfo.ArgumentList 사용 하는 주름 을 az[.cmd] 알 수 있듯이 CLI 진입 점으로 _batch 파일 _이 널리 퍼져 있기 때문에) --% 있습니다.

PSSA는 변경 될 인수 형식을 사용한다는 경고를 사용자에게 경고하여 주요 변경 사항을 완화하는 데 도움이 될 수 있습니다.

이 주요 변경 사항을 다른 일부 와 함께 진행하려면 선택적 기능 과 같은 것을 채택하는 것을 고려해야한다고 생각 합니다 .

기존 행동을 유지하는 데 정말 가치가 있습니까? 이전 버전과의 호환성 외에는 말입니다.

나는 이것을 위해 두 개의 코드 경로를 유지하는 것은 가치가 없다고 생각합니다. 단지 깨진 구현을 유지하는 것입니다. 왜냐하면 일부 오래된 코드는 때때로 그것을 필요로 할 수 있기 때문입니다. 나는 folx가 가끔씩 그들의 코드를 업데이트 할 것이라고 기대하는 것이 부당하다고 생각하지 않습니다. 😅

PS7이 WinPS의 독립형 대체품이 될 것으로 예상한다면 두 배로 그렇습니다. v7의 동작을 유지할 수있는 유일한 이유는 사람들이 5.1과 7 모두에서 명령을 실행하는 데 동일한 스크립트를 사용하기를 기대하는 경우입니다. PS7이 5.1을 대체하는 경우는 매우 드문 경우입니다.

그럼에도 불구하고 사용자가 두 가지를 모두 설명하는 것은 그리 어렵지 않습니다. 실제 언어 구문을 변경하지 않는다면 다음과 같이하는 것은 매우 쉽습니다.

if ($PSVersionTable.PSVersion.Major -lt 7) {
    # use old form
}
else {
    # use new form
}

사용자에게 차이를 인식하게한다면 지금까지 PS에서 이상한 네이티브 실행 파일을 처리하는 것이 고통을 덜어 줄 수있을 것이라고 생각합니다. 😄

@TylerLeonhardt는 옵션 기능에 대한 논의에서 언급 한 바와 같이 - 그 수단 이제 각 필요가 유지되고 시험 플러스도 유지하고 옵션 기능 프레임 워크를 테스트 할 _multiple_ 별개의 구현을 유지 구현. 이것에 대한 가치가있는 것 같지 않습니다, tbh.

@ vexx32 이전 버전과의 호환성은 여기서 큰 문제입니다. 이것은 네이티브 실행 파일에 대한 args의 유일한 문제가 아닙니다. 나는 그것들을 모두 버킷 화하여 모두 하나의 "선택적 기능"으로 만들고 싶습니다. 예 : https://github.com/PowerShell/PowerShell/issues/1761 및 https://github.com/PowerShell/PowerShell/issues/10675. 기본 명령과의 "고정"상호 운용성은 vNext에서 해결하고 싶습니다. 따라서 누군가가이 범주에서 기존 또는 새로운 문제를 본다면 나를 참조하고 적절하게 태그 할 것입니다 (또는 심사 권한이있는 경우 다른 문제처럼 태그 지정).

선택적 기능은 모듈입니다 :-) 엔진에 선택적 기능을 갖는 것은 지원, 특히 Windows 지원의 경우 큰 골칫거리입니다. 내부 종속성을 줄이고 내부 API를 공용으로 대체하여 엔진을 모듈화 할 수 있습니다. 그 후 엔진에서 옵션 기능을 쉽게 구현할 수 있습니다.

@iSazonov 우리 팀이 vNext에서 살펴볼 것 중 하나는 엔진을 모듈화하는 것입니다. :)

여기서 최종 사용자에게 권장되는 솔루션은 무엇입니까?

이것은 인위적이지만 .NET 프레임 워크 자체에서 올바른 * ArgumentList 처리를 얻는 가장 간단한 방법입니다.

Add-Type -AssemblyName "System"
function startProcess([string] $FileName, [string[]] $ArgumentList) {
    $proc = ([System.Diagnostics.Process]::new())
    $proc.StartInfo.UseShellExecute = $false
    $proc.StartInfo.FileName = $FileName
    $proc.StartInfo.CreateNoWindow = $true
    foreach ($a in $ArgumentList) { $proc.StartInfo.ArgumentList.Add($a) }
    $proc.Start()
    return $proc
}

startProcess -FileName 'C:\Program Files\nodejs\node.exe' -ArgumentList '-e','console.log(process.argv.join(''\n''))','--','abc" \" messyString'

물론 위치 매개 변수와 약간의 get-command 속임수를 사용하여 여기서 사용하는 것을 덜 인위적으로 만들 수 있습니다.

* 면책 조항 : Windows에서 cmdline을 구문 분석하는 올바른 단일 방법은 없습니다. "올바른"이란 ArgumentList 처리, main (string[] args) 처리 및 Unix의 외부 스폰 호출을 위해 모든 플랫폼에서 .NET으로 구현 된 cmdline에서 argv로 변환하는 MSVCRT 스타일을 의미합니다. 이 샘플은 일반적인 상호 운용성을 보장하지 않고있는 그대로 제공됩니다. 제안 된 NodeJS child_process 문서의 "windows 명령 줄"섹션을 참조하십시오.

@ Artoria2e5 정확히 내가 결론을 내 렸습니다. System.Diagnostics.Process는 외부 실행 파일을 실행하는 신뢰할 수있는 유일한 방법이지만 stdlib 규칙으로 인해 인수 이스케이프 처리가 까다로울 수 있습니다.

2N backslashes + " ==> N backslashes and begin/end quote
2N+1 backslashes + " ==> N backslashes + literal " 
N backslashes ==> N backslashes

결과적으로 인수를 이스케이프하는 다음 논리를 생각해 냈습니다. 프로세스 실행을 위해 인수를 큰 따옴표 " 로 감 쌉니다.
https://github.com/choovick/ps-invoke-externalcommand/blob/master/ExternalCommand/ExternalCommand.psm1#L244

또한 외부 실행 파일이 실행되는 동안 실시간으로 STDOUT 및 STDERR을 얻는 것이 까다로울 수 있으므로이 패키지를 만들었습니다.

https://github.com/choovick/ps-invoke-externalcommand

나는 Windows, Linux 및 Mac에서 많이 사용하고 있으며 지금까지는 문제없이 줄 바꿈 및 기타 특수 문자로 인수를 전달할 수 있습니다.

GitHub

choovick / ps-invoke-externalcommand

GitHub에서 계정을 만들어 choovick / ps-invoke-externalcommand 개발에 기여하세요.

GitHub

choovick / ps-invoke-externalcommand

GitHub에서 계정을 만들어 choovick / ps-invoke-externalcommand 개발에 기여하세요.

@choovick 전체 stdio 리디렉션이 훌륭합니다!

이스케이프 부분에 대해서는 약간 동의하지 않습니다. ArgumentList라고하는 것이 이미 있기 때문입니다. 나는 그것이 상대적인 최근 (?) 추가라는 것을 이해하고 MS가 SDProcessStartInfo에 대한 String, String [] 이니셜 라이저를 넣는 것을 잊었 기 때문에 실망 스럽습니다. (이들… .NET 인터페이스 제안을위한 장소가 있습니까?)

해당 NodeJS 예제의 이스케이프 함수는 당신의 것과 약간 다릅니다 : 따옴표로 문서화되지 않은 (그러나 .NET core 및 MSVCRT에 있음) "" 이스케이프를 사용합니다. 이렇게하면 백 슬래시 선택 작업이 단순화됩니다. 나는 주로 모든 강력한 cmd에 사용 되었기 때문에 \" 가 나머지 문자열을 인용 해제해서는 안된다는 것을 이해하지 못합니다. \^" 로 고군분투하는 대신, 나는 처음부터 비밀리에 사용되어 온 무언가로 더 나아질 것이라고 생각했습니다.

@ Artoria2e5 불행히도 ArgumentList는 Windows의 PowerShell 5.1에서 사용할 수 없습니다.

```널 값 표현식에서는 메서드를 호출 할 수 없습니다.
C : Usersyserdevtest.ps1 : 7 char : 37에서

• ... oreach ($ ArgumentList의 $ a) {$ proc.StartInfo.ArgumentList.Add ($ a)}
• ~ ~ ~ ~ ~ ~ ~ ~
  
  
  
  • CategoryInfo : InvalidOperation : (:) [], RuntimeException
  
  
  • FullyQualifiedErrorId : InvokeMethodOnNull
    
    ```
  
  

사용자 지정 인수 이스케이프 논리 이후 ....

NodeJS의`\ ^ "`에 관해서는 몇 년 전에해야했다고 생각합니다. :) 제대로 작동했다고 생각합니다.

System.Diagnostics.Process는 외부 실행 파일을 실행하는 유일한 방법입니다.

문제는 PowerShell의 출력 스트림과 통합되지 않고 파이프 라인에서 스트리밍 동작을 얻지 못한다는 것입니다.

다음은 PowerShell이 ​​호출을 수행하도록하려는 경우 필요한 해결 방법에 대한 요약입니다 (확실히 바람직 함) .

• _embedded_ " 문자를 사용하여 인수를 전달해야하는 경우, 가능하면 Windows에서 _double_ 또는 \ 이스케이프 :

  • Windows에서 _batch files_를 호출 할 때 대상 프로그램이 "" 를 이스케이프 된 " 인식한다는 것을 알고있는 경우 $arg -replace '"', '""'

    • Windows에서는 "" 를 사용하는 것이 좋지만 (Windows PowerShell 문제를 방지하고 Node.js 및 Azure와 같은 _stubs_와 같은 배치 파일을 사용하는 CLI에서 작동 함) 모든 실행 파일이이를 지원하지는 않습니다 (특히 Ruby 및 Perl).

  • 그렇지 않으면 (항상 Unix에서) $arg -replace '"', '\"'

  • 참고 : _Windows PowerShell_에서는 값에 _spaces_도 포함되어있는 경우에도 항상 제대로 작동하지 않습니다. 값에 리터럴 \" 가 있으면 상황에 따라 PowerShell Core와 달리 큰 따옴표를 묶는 _not_ 트리거를 수행하기 때문입니다. 예 : '3\" of snow' 휴식 통과.

  • 또한, 위의 이스케이프 전에 \ 바로 앞에 " \ 인스턴스를 두 번해야합니다.

    • $arg = $arg -replace '(\\+)"', '$1$1"'

• _empty_ 인수를 전달해야하는 경우 '""' .

  • '' -eq $arg ? '""' : $arg (WinPS 대안 : ($arg, '""')['' -eq $arg]

• Windows PowerShell에만 해당되며 PS Core에서이 작업을 수행하지 마십시오 (문제가 수정 된 경우).

  • 인수가 _ 공백을 포함 _하고 _ 끝 _ (하나 이상) \ 이면 후행 \ 인스턴스를 두 배로 늘립니다.

    • if ($arg -match ' .*?(\\+)$') { $arg = $arg + $Matches[1] }

• cmd / 공백이 _not_ 있지만 (따라서 PowerShell에서 자동 큰 따옴표를 트리거하는 _not_) 인수를 사용하여 배치 파일이 호출되는 경우 &|<>^,; (예 : a&b ), _embedded enclosing double-quoting_을 사용하여 PowerShell이 ​​큰 따옴표 토큰을 전달하고 따라서 cmd / 배치 파일 호출을 중단하지 않도록합니다.

  • $arg = '"' + $arg + '"'

• msiexec.exe 와 같이 잘못 작동하는 실행 파일을 처리해야하는 경우 인수를 작은 따옴표로 묶으십시오.

  • 'foo="bar none"'

언급했듯이 이러한 해결 방법은 근본적인 문제가 해결되면 _break_됩니다.

다음은 간단한 (고급이 아닌) 함수 iep ( "외부 프로그램 호출"용)입니다.

• msiexec 대한 자동 특수 케이스를 포함하여 위에서 설명한 모든 이스케이프를 수행하고 대상 프로그램에 따라 \" 보다 "" 이스케이프를 선호합니다.
  
  
  
  • 아이디어는 _PowerShell_의 문자열 구문에만 집중하여 모든 인수를 전달할 수 있으며, PowerShell이 ​​보는 축어 값도 대상 프로그램에서 볼 수 있도록 필요한 이스케이프를 수행하는 함수에 의존 할 수 있다는 것입니다.
  
  
  • PowerShell _Core_에서 이것은 매우 강력하게 작동합니다. Windows PowerShell에는 \" 이스케이프를 사용해야하는 경우 중단되는 큰 따옴표가 포함 된 예외적 인 경우가 있습니다 (위에서 설명한대로).
  
  
• 쉘 명령 호출 구문을 보존합니다.
  
  
  
  • 명령 줄 앞에 iep  를 추가하기 만하면됩니다.
  
  
• 직접 호출은 다음과 같습니다.
  
  
  
  • PowerShell의 스트림과 통합
  
  
  • 파이프 라인을 통해 한 줄씩 출력을 보냅니다.
  
  
  • 외부 프로그램의 종료 코드에 따라 $LASTEXITCODE 를 설정합니다. 그러나 $? 는 신뢰할 수 _ 없습니다 _.
  
  

참고 :이 함수는 가능한 한 눈에 띄지 않게하기 위해 의도적으로 최소한 (매개 변수 선언 없음, 명령 줄 도움말 없음, 짧은 (불규칙) 이름)입니다. 명령 줄 앞에 iep 를 추가하면됩니다. 작동합니다.

EchoArgs.exe 사용한 호출 예제 ( choco install echoargs -y 를 사용하여 _elevated_ 세션에서 Chocolatey를 통해 설치 가능) :

PS> iep echoargs '' 'a&b' '3" of snow' 'Nat "King" Cole' 'c:\temp 1\' 'a \" b'
Arg 0 is <>
Arg 1 is <a&b>
Arg 2 is <3" of snow>
Arg 3 is <Nat "King" Cole>
Arg 4 is <c:\temp 1\>
Arg 5 is <a \" b>

Command line:
"C:\ProgramData\chocolatey\lib\echoargs\tools\EchoArgs.exe" "" a&b "3\" of snow" "Nat \"King\" Cole" "c:\temp 1\\" "a \\\" b"

위는 PowerShell Core 출력을 보여줍니다. 빈 인수를 포함하여 모든 인수가 PowerShell에서 그대로 표시되는대로 올바르게 전달되었는지 확인합니다.

Windows PowerShell에서는 \" 이스케이프가 알 수없는 실행 파일을 호출하기 때문에 (위에서 설명한대로) 사용되므로 3" of snow 인수가 올바르게 전달되지 않습니다.

그 배치 파일이 제대로을 통해 인수를 전달 확인하려면, 당신은 만들 수 있습니다 echoargs.cmd 의 래퍼로 echoargs.exe :

'@echoargs.exe %*' | Set-Content echoargs.cmd

iep .\echoargs.cmd '' 'a&b' '3" of snow' 'Nat "King" Cole' 'c:\temp 1\' 'a \" b' 로 호출

이제 배치 파일이 호출되었으므로 "" -escaping을 사용하여 Windows PowerShell에서 호출 할 때 3" of snow 문제를 해결합니다.

이 함수는 Unix 계열 플랫폼에서도 동일하게 작동하며 echoargs 라는 sh 셸 스크립트를 만들어 확인할 수 있습니다.

@'
#!/bin/sh
i=0; for a; do printf '%s\n' "\$$((i+=1))=[$a]"; done
'@ > echoargs; chmod a+x echoargs

iep ./echoargs '' 'a&b' '3" of snow' 'Nat "King" Cole' 'c:\temp 1\' 'a \" b' 로 호출

중요 : 이 함수 의 ie ( I nvoke (external) E xecutable) 로 게시되었습니다. 방금 Native 모듈을 게시했습니다. 대신. 다음으로 모듈 설치
Install-Module Native -Scope CurrentUser
이 모듈에는 # 13068에서 논의 된 사용 사례를 해결하는 ins ( Invoke-NativeShell ) 명령도 포함되어 있습니다. https://github.com/PowerShell/PowerShell/issues/13068#issuecomment -671572939 참조 자세한 내용은.

Function iep 's 소스 코드 (대신 Native 모듈 사용-위 참조) :

function iep {

  Set-StrictMode -Version 1
  if (-not (Test-Path Variable:IsCoreClr)) { $IsCoreCLR = $false }
  if (-not (Test-Path Variable:IsWindows)) { $IsWindows = $env:OS -eq 'Windows_NT' }

  # Split into executable name/path and arguments.
  $exe, [string[]] $argsForExe = $args

  # Resolve to the underlying command (if it's an alias) and ensure that an external executable was specified.
  $app = Get-Command -ErrorAction Stop $exe
  if ($app.ResolvedCommand) { $app = $app.ResolvedCommand }
  if ($app.CommandType -ne 'Application') { Throw "Not an external program, non-PS script, or batch file: $exe" }

  if ($argsForExe.Count -eq 0) {
    # Argument-less invocation
    & $exe
  }
  else {
    # Invocation with arguments: escape them properly to pass them through as literals.
    # Decide whether to escape embedded double quotes as \" or as "", based on the target executable.
    # * On Unix-like platforms, we always use \"
    # * On Windows, we use "" where we know it's safe to do. cmd.exe / batch files require "", and Microsoft compiler-generated executables do too, often in addition to supporting \",
    #   notably including Python and Node.js
    #   However, notable interpreters that support \" ONLY are Ruby and Perl (as well as PowerShell's own CLI, but it's better to call that with a script block from within PowerShell).
    #   Targeting a batch file triggers "" escaping, but in the case of stub batch files that simply relay to a different executable, that could still break
    #   if the ultimate target executable only supports \" 
    $useDoubledDoubleQuotes = $IsWindows -and ($app.Source -match '[/\\]?(?<exe>cmd|msiexec)(?:\.exe)?$' -or $app.Source -match '\.(?<ext>cmd|bat|py|pyw)$')
    $doubleQuoteEscapeSequence = ('\"', '""')[$useDoubledDoubleQuotes]
    $isMsiExec = $useDoubledDoubleQuotes -and $Matches['exe'] -eq 'msiexec'
    $isCmd = $useDoubledDoubleQuotes -and ($Matches['exe'] -eq 'cmd' -or $Matches['ext'] -in 'cmd', 'bat')
    $escapedArgs = foreach ($arg in $argsForExe) {
      if ('' -eq $arg) { '""'; continue } # Empty arguments must be passed as `'""'`(!), otherwise they are omitted.
      $hasDoubleQuotes = $arg.Contains('"')
      $hasSpaces = $arg.Contains(' ')
      if ($hasDoubleQuotes) {
        # First, always double any preexisting `\` instances before embedded `"` chars. 
        # so that `\"` isn't interpreted as an escaped `"`.
        $arg = $arg -replace '(\\+)"', '$1$1"'
        # Then, escape the embedded `"` chars. either as `\"` or as `""`.
        # If \" escaping is used:
        # * In PS Core, use of `\"` is safe, because its use triggers enclosing double-quoting (if spaces are also present).
        # * !! In WinPS, sadly, that isn't true, so something like `'foo="bar none"'` results in `foo=\"bar none\"` -
        #   !! which - due to the lack of enclosing "..." - is seen as *2* arguments by the target app, `foo="bar` and `none"`.
        #   !! Similarly, '3" of snow' would result in `3\" of snow`, which the target app receives as *3* arguments, `3"`, `of`, and `snow`.
        #   !! Even manually enclosing the value in *embedded* " doesn't help, because that then triggers *additional* double-quoting.
        $arg = $arg -replace '"', $doubleQuoteEscapeSequence
    }
      elseif ($isMsiExec -and $arg -match '^(\w+)=(.* .*)$') { 
        # An msiexec argument originally passed in the form `PROP="value with spaces"`, which PowerShell turned into `PROP=value with spaces`
        # This would be passed as `"PROP=value with spaces"`, which msiexec, sady, doesn't recognize (`PROP=valueWithoutSpaces` works fine, however).
        # We reconstruct the form `PROP="value with spaces"`, which both WinPS And PS Core pass through as-is.
        $arg = '{0}="{1}"' -f $Matches[1], $Matches[2]
      }
      # As a courtesy, enclose tokens that PowerShell would pass unquoted in "...", 
      # if they contain cmd.exe metachars. that would break calls to cmd.exe / batch files.
      $manuallyDoubleQuoteForCmd = $isCmd -and -not $hasSpaces -and $arg -match '[&|<>^,;]'
      # In WinPS, double trailing `\` instances in arguments that have spaces and will therefore be "..."-enclosed,
      # so that `\"` isn't mistaken for an escaped `"` - in PS Core, this escaping happens automatically.
      if (-not $IsCoreCLR -and ($hasSpaces -or $manuallyDoubleQuoteForCmd) -and $arg -match '\\') {
        $arg = $arg -replace '\\+$', '$&$&'
      }
      if ($manuallyDoubleQuoteForCmd) {
        # Wrap in *embedded* enclosing double quotes, which both WinPS and PS Core pass through as-is.
        $arg = '"' + $arg + '"'
      }
      $arg
    }
    # Invoke the executable with the properly escaped arguments.
    & $exe $escapedArgs
  }
}

@ mklement0 인상적이지만 여기에 Windows에서 작동하지 않는 몇 가지가 있습니다.

iep echoargs 'somekey="value with spaces"' 'te\" st'

Arg 0 is <somekey="value>
Arg 1 is <with>
Arg 2 is <spaces">
Arg 3 is <te\">
Arg 4 is <st>

Command line:
"C:\ProgramData\chocolatey\lib\echoargs\tools\EchoArgs.exe" somekey=\"value with spaces\" te\\\" st

여기에 내 테스트 인수 배열이 있습니다. :)

$Arguments = @(
    'trippe slash at the end \\\',
    '4 slash at the end \\\\',
    '\\servername\path\',
    'path=\\servername\path\',
    'key="\\servername\pa th\"',
    '5 slash at the end \\\\\',
    '\\" double slashed double quote',
    'simple',
    'white space',
    'slash at the end \',
    'double slash at the end \\',
    'trippe slash at the end \\\',
    'trippe slash at the end with space \\\ ',
    '\\" double slashed double quote',
    'double slashed double quote at the end \\"',
    '\\\" triple slashed double quote',
    'triple slashed double quote at the end \\\"',
    # slash
    'single slashes \a ^ \: \"',
    'path="C:\Program Files (x86)\test\"'
    # quotes
    'double quote " and single quote ''',
    # windows env var syntax
    "env var OS: %OS%",
    # utf16
    ('"utf16 ETHIOPIC WORDSPACE: \u1361"' | ConvertFrom-Json),
    # special chars
    "newLine`newLine"
    "tab`tab"
    "backspace`bbackspace"
    "carriage`rafter",
    "formFeed`fformFeed",
    # JSON Strings
    @"
[{"_id":"5cdab57e4853ea7b5a707070","index":0,"guid":"25319946-950e-4fe8-9586-ddd031cbb0fc","isActive":false,"balance":"`$2,841.15","picture":"http://placehold.it/32x32","age":39,"eyeColor":"blue","name":{"first":"Leach","last":"Campbell"},"company":"EMOLTRA","email":"[email protected]","phone":"+1 (864) 412-3166","address":"127 Beadel Street, Vivian, Vermont, 1991","about":"Ex labore non enim consectetur id ullamco nulla veniam Lorem velit cillum aliqua amet nostrud. Occaecat ipsum do est qui sint aliquip anim culpa laboris tempor amet. Aute sint anim est sint elit amet nisi veniam culpa commodo nostrud cupidatat in ex.","registered":"Monday, August 25, 2014 4:04 AM","latitude":"-12.814443","longitude":"75.880149","tags":["pariatur","voluptate","sint","Lorem","eiusmod"],"range":[0,1,2,3,4,5,6,7,8,9],"friends":[{"id":0,"name":"Lester Bender"},{"id":1,"name":"Concepcion Jarvis"},{"id":2,"name":"Elsie Whitfield"}],"greeting":"Hello, Leach! You have 10 unread messages.","favoriteFruit":"strawberry"},{"_id":"5cdab57e8cd0ac577ab534a4","index":1,"guid":"0be10c87-6ce7-46c4-8dd6-23b1d9827538","isActive":false,"balance":"`$1,049.56","picture":"http://placehold.it/32x32","age":33,"eyeColor":"green","name":{"first":"Lacey","last":"Terrell"},"company":"XSPORTS","email":"[email protected]","phone":"+1 (858) 511-2896","address":"850 Franklin Street, Gordon, Virginia, 4968","about":"Eiusmod nostrud mollit occaecat Lorem consectetur enim pariatur qui eu. Proident aliqua sunt incididunt Lorem adipisicing ea esse do ullamco excepteur duis qui. Irure labore cillum aliqua officia commodo incididunt esse ad duis ea. Occaecat officia officia laboris veniam id dolor minim magna ut sit. Aute quis occaecat eu veniam. Quis exercitation mollit consectetur magna officia sit. Irure ullamco laborum cillum dolore mollit culpa deserunt veniam minim sunt.","registered":"Monday, February 3, 2014 9:19 PM","latitude":"-82.240949","longitude":"2.361739","tags":["nostrud","et","non","eiusmod","qui"],"range":[0,1,2,3,4,5,6,7,8,9],"friends":[{"id":0,"name":"Meyers Dillard"},{"id":1,"name":"Jacobson Franco"},{"id":2,"name":"Hunt Hernandez"}],"greeting":"Hello, Lacey! You have 8 unread messages.","favoriteFruit":"apple"},{"_id":"5cdab57eae2f9bc5184f1768","index":2,"guid":"3c0de017-1c2a-470e-87dc-5a6257e8d9d9","isActive":true,"balance":"`$3,349.49","picture":"http://placehold.it/32x32","age":20,"eyeColor":"green","name":{"first":"Knowles","last":"Farrell"},"company":"DAYCORE","email":"[email protected]","phone":"+1 (971) 586-2740","address":"150 Bath Avenue, Marion, Oregon, 991","about":"Eiusmod sint commodo eu id sunt. Labore esse id veniam ea et laborum. Dolor ad cupidatat Lorem amet. Labore ut commodo amet commodo. Ipsum reprehenderit voluptate non exercitation anim nostrud do. Aute incididunt ad aliquip aute mollit id eu ea. Voluptate ex consequat velit commodo anim proident ea anim magna amet nisi dolore.","registered":"Friday, September 28, 2018 7:51 PM","latitude":"-11.475201","longitude":"-115.967191","tags":["laborum","dolor","dolor","magna","mollit"],"range":[0,1,2,3,4,5,6,7,8,9],"friends":[{"id":0,"name":"Roxanne Griffith"},{"id":1,"name":"Walls Moore"},{"id":2,"name":"Mattie Carney"}],"greeting":"Hello, Knowles! You have 8 unread messages.","favoriteFruit":"strawberry"},{"_id":"5cdab57e80ff4c4085cd63ef","index":3,"guid":"dca20009-f606-4b99-af94-ded6cfbbfa38","isActive":true,"balance":"`$2,742.32","picture":"http://placehold.it/32x32","age":26,"eyeColor":"brown","name":{"first":"Ila","last":"Hardy"},"company":"OBLIQ","email":"[email protected]","phone":"+1 (996) 556-2855","address":"605 Hillel Place, Herald, Delaware, 9670","about":"Enim eiusmod laboris amet ex laborum do dolor qui occaecat ex do labore quis sunt. Veniam magna non nisi ipsum occaecat anim ipsum consectetur ex laboris aute ut consectetur. Do eiusmod tempor dolore eu in dolore qui anim non et. Minim amet exercitation in in velit proident sint aliqua Lorem reprehenderit labore exercitation.","registered":"Friday, April 21, 2017 6:33 AM","latitude":"64.864232","longitude":"-163.200794","tags":["tempor","eiusmod","mollit","aliquip","aute"],"range":[0,1,2,3,4,5,6,7,8,9],"friends":[{"id":0,"name":"Duncan Guy"},{"id":1,"name":"Jami Maxwell"},{"id":2,"name":"Gale Hutchinson"}],"greeting":"Hello, Ila! You have 7 unread messages.","favoriteFruit":"banana"},{"_id":"5cdab57ef1556326f77730f0","index":4,"guid":"f2b3bf60-652f-414c-a5cf-094678eb319f","isActive":true,"balance":"`$2,603.20","picture":"http://placehold.it/32x32","age":27,"eyeColor":"brown","name":{"first":"Turner","last":"King"},"company":"DADABASE","email":"[email protected]","phone":"+1 (803) 506-2511","address":"915 Quay Street, Hinsdale, Texas, 9573","about":"Consequat sunt labore tempor anim duis pariatur ad tempor minim sint. Nulla non aliqua veniam elit officia. Ullamco et irure mollit nulla do eiusmod ullamco. Aute officia elit irure in adipisicing et cupidatat dolor in sint elit dolore labore. Id esse velit nisi culpa velit adipisicing tempor sunt. Eu sunt occaecat ex pariatur esse.","registered":"Thursday, May 21, 2015 7:44 PM","latitude":"88.502961","longitude":"-119.654437","tags":["Lorem","culpa","labore","et","nisi"],"range":[0,1,2,3,4,5,6,7,8,9],"friends":[{"id":0,"name":"Leanne Lawson"},{"id":1,"name":"Jo Shepard"},{"id":2,"name":"Effie Barnes"}],"greeting":"Hello, Turner! You have 6 unread messages.","favoriteFruit":"apple"},{"_id":"5cdab57e248f8196e1a60d05","index":5,"guid":"875a12f0-d36a-4e7b-aaf1-73f67aba83f8","isActive":false,"balance":"`$1,001.89","picture":"http://placehold.it/32x32","age":38,"eyeColor":"blue","name":{"first":"Petty","last":"Langley"},"company":"NETUR","email":"[email protected]","phone":"+1 (875) 505-2277","address":"677 Leonard Street, Ticonderoga, Utah, 1152","about":"Nisi do quis sunt nisi cillum pariatur elit dolore commodo aliqua esse est aute esse. Laboris esse mollit mollit dolor excepteur consequat duis aute eu minim tempor occaecat. Deserunt amet amet quis adipisicing exercitation consequat deserunt sunt voluptate amet. Ad magna quis nostrud esse ullamco incididunt laboris consectetur.","registered":"Thursday, July 31, 2014 5:16 PM","latitude":"-57.612396","longitude":"103.91364","tags":["id","labore","deserunt","cillum","culpa"],"range":[0,1,2,3,4,5,6,7,8,9],"friends":[{"id":0,"name":"Colette Mullen"},{"id":1,"name":"Lynnette Tanner"},{"id":2,"name":"Vickie Hardin"}],"greeting":"Hello, Petty! You have 9 unread messages.","favoriteFruit":"banana"},{"_id":"5cdab57e4df76cbb0db9be43","index":6,"guid":"ee3852fe-c597-4cb6-a336-1466e8978080","isActive":true,"balance":"`$3,087.87","picture":"http://placehold.it/32x32","age":33,"eyeColor":"brown","name":{"first":"Salas","last":"Young"},"company":"PLAYCE","email":"[email protected]","phone":"+1 (976) 473-2919","address":"927 Elm Place, Terlingua, North Carolina, 2150","about":"Laborum laboris ullamco aliquip occaecat fugiat sit ex laboris veniam tempor tempor. Anim quis veniam ad commodo culpa irure est esse laboris. Fugiat nostrud elit mollit minim. Velit est laborum ut quis anim velit aute enim culpa amet ipsum.","registered":"Thursday, October 1, 2015 10:59 AM","latitude":"-57.861212","longitude":"69.823065","tags":["eu","est","et","proident","nisi"],"range":[0,1,2,3,4,5,6,7,8,9],"friends":[{"id":0,"name":"Day Solomon"},{"id":1,"name":"Stevens Boyd"},{"id":2,"name":"Erika Mayer"}],"greeting":"Hello, Salas! You have 10 unread messages.","favoriteFruit":"apple"},{"_id":"5cdab57ed3c91292d30e141d","index":7,"guid":"ef7c0beb-8413-4f39-987f-022c4e8ec482","isActive":false,"balance":"`$2,612.45","picture":"http://placehold.it/32x32","age":36,"eyeColor":"brown","name":{"first":"Gloria","last":"Black"},"company":"PULZE","email":"[email protected]","phone":"+1 (872) 513-2364","address":"311 Guernsey Street, Hatteras, New Mexico, 2241","about":"Laborum sunt exercitation ea labore ullamco dolor pariatur laborum deserunt adipisicing pariatur. Officia velit duis cupidatat eu officia magna magna deserunt do. Aliquip cupidatat commodo duis aliquip in aute dolore occaecat esse ad. Incididunt est magna in pariatur ut do ex sit minim cupidatat culpa. Voluptate eu veniam cupidatat exercitation.","registered":"Friday, June 26, 2015 7:59 AM","latitude":"38.644208","longitude":"-45.481555","tags":["sint","ea","anim","voluptate","elit"],"range":[0,1,2,3,4,5,6,7,8,9],"friends":[{"id":0,"name":"Abby Walton"},{"id":1,"name":"Elsa Miranda"},{"id":2,"name":"Carr Abbott"}],"greeting":"Hello, Gloria! You have 5 unread messages.","favoriteFruit":"strawberry"},{"_id":"5cdab57edc91491fb70b705d","index":8,"guid":"631ff8a0-ce4c-4111-b1e4-1d112f4ecdc7","isActive":false,"balance":"`$2,550.70","picture":"http://placehold.it/32x32","age":25,"eyeColor":"brown","name":{"first":"Deirdre","last":"Huber"},"company":"VERBUS","email":"[email protected]","phone":"+1 (871) 468-3420","address":"814 Coles Street, Bartonsville, Tennessee, 7313","about":"Ipsum ex est culpa veniam voluptate officia consectetur quis et irure proident pariatur non. In excepteur est aliqua duis duis. Veniam consectetur cupidatat reprehenderit qui qui aliqua.","registered":"Monday, April 1, 2019 2:33 AM","latitude":"-75.702323","longitude":"45.165458","tags":["labore","aute","nisi","laborum","laborum"],"range":[0,1,2,3,4,5,6,7,8,9],"friends":[{"id":0,"name":"Genevieve Clarke"},{"id":1,"name":"Black Sykes"},{"id":2,"name":"Watson Hudson"}],"greeting":"Hello, Deirdre! You have 8 unread messages.","favoriteFruit":"strawberry"}]
"@
)

System.Diagnostics.Process는 사용할 때 제한이 있기 때문에 STDOUT STDERR 및 그 조합을 변수로 캡처 할 수있는 능력을 가진 자체 러너를 작성해야했는데, 이는 제 사용 사례에는 충분하지만 완벽하지는 않습니다.

편집 : 당신이 말했듯이 Windows Poweshell 5에서 가장자리 케이스가있는 것 같습니다. Powershell 6에서 테스트했으며 훌륭하게 작동합니다! 불행히도 7이 Windows 케이스에서 인수 될 때까지 Poweshell 5를 처리해야합니다 ...

인상적이지만 여기에 Windows에서 작동하지 않는 몇 가지가 있습니다.

예, 이러한 제한 사항은 이전 의견에서 설명한대로 포함 된 " "" 이스케이프 지원을 가정 할 수없는 실행 파일과 함께 _Windows PowerShell_에 적용됩니다.
모든 호출에서 "" 이스케이프를 지원할 의향이 있다면 (_most_, Windows의 모든 실행 파일이 지원하지는 않음) 함수를 쉽게 조정할 수 있습니다.

그리고 편집에서 말한 내용을 확인하려면 PowerShell _Core_에서 :

• iep echoargs 'somekey="value with spaces"' 'te\" st' 잘 작동합니다.
• 인수의 테스트 배열도 잘 작동하는 것 같습니다.

모든 호출에서 "" 이스케이프에 대한 지원을 가정하고 싶다면 (_most_, Windows의 모든 실행 파일이 지원하지는 않음) 함수를 쉽게 조정할 수 있습니다.

감사합니다. 가까운 시일 내에 사용해 보겠습니다. 나는 때때로 sqlcmd를 다루며 "" 를 확실히 지원하지 않습니다. 이 경우 특정 인수에 대한 이스케이프 논리를 건너 뛸 수있는 옵션을 제공하기 쉽습니다.

Windows에서 명령 줄 인수를 구문 분석하는 방법은 C ++ 명령 줄 인수 구문 분석 에서 찾을 수 있습니다.

Microsoft C / C ++ 시작 코드는 운영 체제 명령 줄에 지정된 인수를 해석 할 때 다음 규칙을 사용합니다.

• 인수는 공백 또는 탭인 공백으로 구분됩니다.

• 캐럿 문자 (^)는 이스케이프 문자 또는 구분 기호로 인식되지 않습니다. 문자는 프로그램의 argv 배열로 전달되기 전에 운영 체제의 명령 줄 파서에 의해 완전히 처리됩니다.

• 큰 따옴표 ( " string ")로 둘러싸인

• 백 슬래시 (\ ")가 앞에 오는 큰 따옴표는 리터럴 큰 따옴표 문자 (")로 해석됩니다.

• 백 슬래시는 큰 따옴표 바로 앞에 나오지 않는 한 문자 그대로 해석됩니다.

• 짝수의 백 슬래시 뒤에 큰 따옴표가 오면 모든 백 슬래시 쌍에 대해 하나의 백 슬래시가 argv 배열에 배치되고 큰 따옴표는 문자열 구분 기호로 해석됩니다.

• 홀수의 백 슬래시 뒤에 큰 따옴표가 오면 모든 백 슬래시 쌍에 대해 하나의 백 슬래시가 argv 배열에 배치되고 큰 따옴표는 나머지 백 슬래시로 "이스케이프"되어 리터럴이됩니다. 큰 따옴표 ( ")는 argv 배치됩니다.

_exec, _wexec 함수 에서도 설명합니다.

문자열에 포함 된 공백으로 인해 예기치 않은 동작이 발생할 수 있습니다. 예를 들어 _exec 문자열에 "hi there" 를 전달하면 새 프로세스가 두 개의 인수, "hi" 및 "there" 얻습니다. 새 프로세스가 "hi there"라는 파일을 열도록하는 것이 의도 된 경우 프로세스가 실패합니다. "\"hi there\"" 문자열을 인용하여이를 방지 할 수 있습니다.

파이썬이 네이티브 실행 파일을 호출하는 방법

Python의 subprocess.Popen 는 Windows에서 인수 시퀀스를 문자열 로 args 를 문자열로 변환하여 이스케이프를 올바르게 처리 할 수 ​​있습니다. 구현은 subprocess.list2cmdline 입니다.

이것이 --% 또는 이중 이스케이프 (PowerShell 및 CMD 구문을 따름)를 사용하는 대신 PowerShell이이를보다 우아한 방식으로 처리 할 수있는 방법에 대한 정보를 제공 할 수 있기를 바랍니다. 현재 해결 방법은 실제로 Azure CLI (python.exe 기반) 고객에게 버그를줍니다.

이 문제를 처리하는 방법을 이해하기위한 명확하고 간결한 방법이 아직 없습니다. Powershell 팀의 누군가가 v7로 단순화하면 밝힐 수 있습니까?

좋은 소식은 PS 7.1의 초점 중 하나가 기본 명령을보다 쉽게 ​​호출 할 수 있도록하는 것입니다. 7.1 투자에 대한

대부분의 기본 명령은 PowerShell 내에서 제대로 작동하지만 인수 구문 분석이 이상적이지 않은 경우가 있습니다 (예 : 따옴표를 올바르게 처리). 의도는 사용자가 널리 사용되는 기본 도구에 대한 샘플 명령 줄을 잘라서 PowerShell에 붙여 넣을 수 있도록하는 것이며, PowerShell 특정 이스케이프 없이도 작동합니다.

그래서 아마도 (희망적으로) 이것은 7.1에서 해결 될 것입니다.

감사합니다, @rkeithhill 이지만 그렇지 않습니다.

의도는 사용자가 널리 사용되는 기본 도구에 대한 샘플 명령 줄을 잘라서 PowerShell에 붙여 넣을 수 있도록하는 것이며, PowerShell 특정 이스케이프 없이도 작동합니다.

본질적으로 개념적으로 문제가있는 --% (구문 분석 중지 기호)에 대한 또 다른 해석처럼 들리나요?

@ SteveL-MSFT,이 예정된 기능에 대해 자세히 설명해 주시겠습니까?

요약하자면, 여기에 제안 된 수정 사항은 _PowerShell_의 구문 요구 사항을 충족하고 PowerShell이 ​​모든 이스케이프 처리를 처리한다는 것입니다 (Windows에서는, Unix에서는 더 이상 필요하지 않습니다. 이제 .NET에서는 대상 프로그램에 축 어적 토큰 배열을 전달합니다)-하지만 이전 버전과의 호환성을 유지해야하는 경우 수정 사항이 옵트 인되어야한다는 것은 의심의 여지가 없습니다.

이 수정을 통해 다른 셸에 대한 명령 줄을 _some_ 조작해야하지만 더 간단 합니다. --% 비해 PowerShell의 구문 및 변수 확장 ( (...) 표현식)의 모든 기능을 그대로 유지합니다.

• \" 를 `" 로 바꿔야하지만 _ "..." _ 내부에서만 가능합니다.

• _no (other) shell_이 관련되어 있으므로 $USER 와 같은 Bash 스타일 환경 변수 참조는 작동하지 _ 않습니다 (이들은 _PowerShell_ 변수로 해석됩니다). 동등한 PowerShell 구문, $env:USER .

  • 제쳐두고 : --% 는-특히 _invariably_- cmd.exe - %USERNAME% 와 같은 스타일의 환경 변수 참조를 확장하여이를 보상하려고 시도하지만, 그렇지 않을뿐만 아니라 t 지원 Bash 스타일 참조 ( $USER )는 _verbatim_ 대상 프로그램에 전달되지만 예기치 않게 Unix 계열 플랫폼에서 cmd.exe 스타일 참조를 확장하고 '...' 인식하지 못합니다.
  • _does_가 각각의 플랫폼 네이티브 셸을 포함하는 대안은 아래를 참조하세요.

• PowerShell에는 그대로 사용하기 위해 인용 / 이스케이프 처리가 필요한 _additional_ 메타 문자가 있음을 알고 있어야합니다. 다음은 다음과 같습니다 ( @ 는 인수의 _first_ char로만 문제가됩니다.) :

  • POSIX 유사 셸 (예 : Bash) : @ { } ` (PowerShell에 의한 선행 확장을 방지하려는 경우 $ )
  • cmd.exe : ( ) @ { } # `
  • 개별적으로 ` -이러한 문자를 이스케이프합니다. 충분합니다 (예 : printf %s `@list.txt ).

다소 인위적인 예 :

다음 Bash 명령 줄을 사용합니다.

# Bash
$ printf '"%s"\n' "3\" of snow"
"3" of snow"        # output

장소에 제안 된 수정과 필요한 것을 모두 교체하는 것입니다 \" 내부 인스턴스 "..." 와 -enclosed 인수 `" :

# PowerShell - WISHFUL THINKING
PS> printf '"%s"\n' "3`" of snow"
"3" of snow"        # output

그것은 당신이에 대해 걱정할 필요가 없습니다 것입니다, 임베디드 " 내부 '...' , 내부 "..." 만 할 이스케이프 할 필요가 _PowerShell_의 행복 (당신은 또한 할 수있는 여기에 "" ).

위의 iep 함수 는 iep printf '"%s"\n' "3`" of snow" 가 의도 한대로 작동 할 수 있도록이 수정 사항을 (잠재적으로) 구현합니다.

Bash에서와 같이 명령이 작동하도록하려면 다음 단계를 건너 뛰어야하는 현재의 깨진 동작과 대조됩니다 ( \ 로 이스케이프하는 _additional_ 라운드가 필요합니다).

# PowerShell - messy workaround to compensate for the current, broken behavior.
PS> printf '\"%s\"\n' "3\`" of snow"
"3" of snow"        # output

수정을 통해 플랫폼의 _default shell_을 통해 주어진 명령 줄 _as-is_를 사용하려는 사람들은 _here-string_을 그대로 사용하여 sh -c (또는 bash -c 로 전달할 수 있습니다 cmd /c ; 예 :

# PowerShell - WISHFUL THINKING
PS> sh -c @'
printf '"%s"\n' "3\" of snow"
'@
"3" of snow"  # output

--% 사용은 여기서 작동하지 _ 않습니다 _ ( printf --% '"%s"\n' "3\" of snow" ), here-string 기반 접근 방식의 추가 이점은 다양한 --% 제한이 적용되지 않는다는 것입니다. , 특히 출력 리디렉션 ( > )을 사용할 수 없습니다.

_double_-quoted here-string ( @"<newline>....<newline>"@ )으로 전환하면 --% 과 달리 _PowerShell 변수 및 표현식 _을 포함 할 수도 있습니다. 그러나 확장 된 값이 대상 셸의 구문을 깨지 않는지 확인해야합니다.

이러한 호출에 대해 간결한 별칭 (예 : Invoke-NativeShell / ins )이있는 전용 cmdlet에 대해 생각할 수 있습니다 ( sh -c / cmd /c 필요하지 않음). 지정), 그러나 복잡한 명령 줄을있는 그대로 전달하기 위해 here-strings를 사용하는 방법을 생각하지 않습니다.

# PowerShell - WISHFUL THINKING
# Passes the string to `sh -c` / `cmd /c` for execution, as appropriate.
# Short alias: ins
PS> Invoke-NativeShell @'
printf '"%s"\n' "3\" of snow"
'@
"3" of snow"  # output

물론, 플랫폼 네이티브 셸의 기능에 의존하는 경우 이러한 호출은 정의에 따라 플랫폼 [-family] 에 따라 다릅니다. Windows 및 Unix와 유사한 플랫폼에서는 작동하지 않습니다.

이것이 장기적으로 _own 구문을 사용하는 PowerShell _alone_에 의존하는 것이 바람직한 이유입니다. 즉, 다른 셸용으로 제작 된 명령 줄을 다음과 같이 사용할 수없는 경우에도 외부 프로그램을 호출하는 데 예측 가능한 교차 플랫폼 환경을 제공합니다. 이다; PowerShell이 ​​인기를 얻음에 따라 필요한 수정 사항을 발견하고 아는 고통이 줄어들 것으로 예상하고 명령 줄의 PowerShell 버전을 보여주는 문서가 점점 더 많아 질 것으로 기대합니다.

• \" 를 `" 로 바꿔야하지만 _ "..." _ 내부에서만 가능합니다.

이것은 모든 곳에서 작동하지 않습니다.

# working everywhere but polluted with \
❯ node -e 'console.log(\"hey\")'
hey

# working in Node:
❯ node -e 'console.log(`"hey`")'
hey

# not working in Julia:
❯ julia -e 'print(`"hey`")'
`hey`

# not working anywhere:
❯ node -e "console.log(`"hey`")"
❯ node -e "console.log("hey")"
❯ node -e "console.log(""hey"")"
❯ node -e 'console.log(""hey"")'

Bash 구문 :

❯ node -e 'console.log("hey")'
hey

Powershell 제안 :

PowerShell 팀이 기호를 찾고 있다면 이전 구문을 깨뜨리지 않습니다. 리터럴을 자동으로 이스케이프하고 문자열 보간을 허용하는 Bash 유사 동작에 백틱`같은 것을 사용하지 않는 이유는 무엇입니까? 이것은 JavaScript의 구문과도 유사합니다.

❯ node -e `console.log("hey")`
hey

❯ $a=hey 
❯ node -e `console.log($hey)`
hey

왜 Bash와 같은 행동을 위해 백틱과 같은 것을 사용하지 않는 이유

백틱은 이미 POSIX 쉘의 백 슬래와 같은 목적으로 물건을 이스케이프하는 데 사용됩니다. 당신이 언급하고있는 코멘트는 이미 그것을 지적하고 있습니다. 우리는 모든 ASCII 따옴표 같은 것들을 다 사용했습니다. $ 접두사를 일반 문자열 리터럴에 추가하면 작동 할 수 있지만 충분히 의미가 없다고 생각합니다.

Windows가 명령 줄 인수를 구문 분석하는 방법은 다음에서 찾을 수 있습니다.

문제는 Windows MSVCR이 단순히 그렇게하는 것이 아니라 문서화되지 않은 방식으로 코너 케이스 것 입니다. "" 은 매우 견고하여 .NET을 Unix로 이식 할 때 CoreFX에 넣을 수도 있습니다. 그러나 어쨌든 적어도 누군가가 globbing을 요청할 때까지는 탈출하기에 충분합니다.

모든 사람이 다르게 수행하는 고전적인 문제도 있지만 원시 cmdline에 대한 .NET이 항상 있기 때문에 걱정할 필요가 없습니다.

왜 Bash와 같은 행동을 위해 백틱과 같은 것을 사용하지 않는 이유

백틱은 이미 POSIX 쉘의 백 슬래와 같은 목적으로 물건을 이스케이프하는 데 사용됩니다. 우리는 모든 ASCII 따옴표 같은 것들을 다 사용했습니다.

구문 분석기가 여기서`가 문자열을 도입하고 있음을 감지 할 수없는 경우 기호 조합을 사용할 가능성이 있습니다. '' 와 같은 것이 작동 할 수도 있습니다.

@aminya 는 이전 Windows Powershell 5.1 및 6 이상을 사용하지 않는 솔루션입니다.
https://github.com/PowerShell/PowerShell/issues/1995#issuecomment -562334606

Windows에서는 PowerShell 5,1을, Linux / mac에서는 6+를 처리해야하므로 kubectl, helm, terraform 및 복잡한 JSON을 전달하는 다른 도구와 함께 작업 할 수 있도록 몇 년 동안 문제없이 작동하는 자체 구현이 있습니다. 매개 변수 내의 개체 :
https://github.com/choovick/ps-invoke-externalcommand

GitHub

choovick / ps-invoke-externalcommand

GitHub에서 계정을 만들어 choovick / ps-invoke-externalcommand 개발에 기여하세요.

@choovick 다소 짧은 구현이 위의 스레드 에서 제공되었지만 여전히 실패 할 경우를 찾고 있습니다. 이것은 v3부터 PS에서 작동합니다.

@AndrewSav @TSlivede 의 Run-Native 함수 는 매우 영리하고 간결하며 _Windows PowerShell_에서도 안정적으로 작동합니다. 주목할 가치가있는 몇 가지 사항 : 필요에 따라 자식 프로세스는 aux를 봅니다. commandlineargumentstring 환경 변수 (아마도 드물지만 실제로는 문제가 될 수 있음), 인수없는 호출은 현재 올바르게 처리되지 않습니다 (함수 만 사용하는 경우 문제가되지 않고 쉽게 수정 됨) _with_, _all_ 인수와 같은 큰 따옴표 (예를 들어, 뭔가 얻을) 그것이위한 것입니다 인수, 42 로 전달됩니다 "42" Windows에서 (불행히도)에 대한 부작용이있을 수 있습니다) 큰 따옴표 (또는 msiexec 경우와 같이 부분적으로 큰 따옴표) 인수를 다르게 해석하는 프로그램.

@aminya , node -e 'console.log(`"hey`")' (일종)이 작동하는 유일한 이유는 현재의 고장난 동작 때문입니다 (아래 참조). 전달하려는 내용이 _verbatim_ console.log("hey") 라고 가정합니다. Windows의 PowerShell이 ​​여기에 제안 된대로 올바르게 이스케이프 처리 된 경우 작은 따옴표로있는 그대로 전달합니다 : node -e 'console.log("hey")' . 이것은 _ 자동으로 _ node -e "console.log(\"hey\")" 로 번역되어야합니다 (큰 따옴표, \ 이스케이프 처리 된 그대로 " ).

이 스레드가 얼마나 오래되었는지를 고려하여 요약 해 보겠습니다.
_PowerShell_의 구문 요구 사항에 대해서만 걱정할 필요가 있으며, PowerShell의 자체 구문 분석 결과 인 _verbatim 인수 값 _이 외부 프로그램 _as-is_에 전달되도록하는 것은 _ 쉘로서의 PowerShell의 작업입니다.

• Unix와 유사한 플랫폼에서 이제 .NET Core 지원이 제공되므로 프로그램이 기본적으로 인수를받는 방법 인 _array_ 인수의 요소로 그대로 전달 될 수 있으므로이 작업은 간단합니다. .
• Windows에서 외부 프로그램은 인수를 _single 명령 줄 문자열 _ (유감스러운 역사적 디자인 결정)로 수신하고 자체 명령 줄 구문 분석을 수행해야합니다. 단일 문자열의 일부로 여러 인수를 전달하려면 인수를 적절하게 설명하기 위해 인용 및 구문 분석 규칙이 필요합니다. 이것은 궁극적으로 자유롭지 만 (프로그램은 자유롭게 구문 분석 할 수 있음), 가장 널리 사용되는 구문 규칙 (이전에 언급되었으며 현재는 포기한 RFC 에서도 제안 Microsoft의 C / C ++ 컴파일러가 구현하는 것입니다 . 그렇게하는 것이 합리적입니다.
  
  
  
  • _Update_ : Windows에서도 .NET Core에서 System.Diagnostics.ProcessStartInfo 의 collection-of-verbatim-tokens ArgumentList 속성을 활용할 수 있습니다. Windows에서는 적절하게 인용되고 이스케이프 된 명령으로 자동 변환됩니다. -프로세스가 시작될 때 줄 문자열; 그러나 _batch 파일 _의 경우 여전히 특수 처리가 필요할 수 있습니다. https://github.com/PowerShell/PowerShell-RFC/pull/90#issuecomment -552231174 참조
  
  

위의 사항을 구현하는 것은 의심 할 여지없이 엄청난 변화이므로 아마도 옵트 인이 필요할 것입니다.
특히 유닉스 세계에서 계속 등장하고 PowerShell 채택을 방해하는 현재의 모든 인용 문제를 제거하려면이 작업을 진행해야한다고 생각합니다.

node -e 'console.log(`"hey`")' : 내부 '...' 경우 ` -해당 문자가있는 그대로 전달되기를 원하지 않는 한 사용하지 마십시오. PowerShell은 현재 " 문자를 그대로 이스케이프하지 _ 않기 때문입니다 _. 당신의 인수에서 \" 배후에서 node 이 명령 줄에서 보는 것은 console.log(`"hey`") 이며, 이는 두 개의 직접 인접한 문자열 리터럴로 구문 분석됩니다. 인용되지 않은 console.log(` 및 큰 따옴표 "hey`" . 박리 후 " 으로 인해되지 않는로 _syntactic_ 기능이있는, \ 적어 주며를 실행하기 자바 스크립트 코드는 궁극적으로 console.log(`hey`) , 그것은 단지 때문에 작업은 어떻게됩니까 `....` 에워 싸인 토큰은 자바 스크립트의 문자열 리터럴, 즉 _template literal_의 한 형태입니다.

@AndrewSav 나는 미친 테스트 개체로 테스트했으며 나를 위해 일했습니다! Linux의 Windows 5.1 및 PS 7에서 테스트 된 매우 우아한 솔루션입니다. 모든 것을 큰 따옴표로 묶어도 괜찮습니다. msiexec 또는 " 명시 적으로 취급하는 것으로 알려진 sqlcmd 도 다루지 않습니다.

내 개인 구현에는 언급 한 것과 유사한 간단한 이스케이프 논리도 있습니다. https://github.com/choovick/ps-invoke-externalcommand/blob/master/ExternalCommand/ExternalCommand.psm1#L278

하지만 해당 모듈 내에서 실시간으로 STDOUT 및 STDERR 스레드를 표시하고 캡처하는 코드를 많이 작성했습니다 ... 아마도 크게 단순화 할 수 있지만 필요가 없었습니다 ...

@ mklement0 이 스레드는 끝나지 않을 것입니다 (: 대부분의 사용 사례에 적합하고 사용하기에 충분히 간단 할 ps 갤러리에 게시 된 PowerShell 모듈을 제공하거나 다가오는 셸 개선을 기다려야합니다.

GitHub

choovick / ps-invoke-externalcommand

GitHub에서 계정을 만들어 choovick / ps-invoke-externalcommand 개발에 기여하세요.

@ mklement0 이 스레드는 끝나지 않을 것입니다 (: 대부분의 사용 사례에 적합하고 사용하기에 충분히 간단 할 ps 갤러리에 게시 된 PowerShell 모듈을 제공하거나 다가오는 셸 개선을 기다려야합니다.

PowerShell 팀이 프로그램 자체에서이 문제를 해결하지 않기로 결정하면 외부 프로그램을 기본적으로 올바르게 실행할 수없는 셸이 내가 선택한 셸이 아니라고 말할 것입니다! 이들은 PowerShell에서 누락 된 기본 항목입니다.

@aminya 예 , 나는 문제로 이동해야 할 때 문제가 매우 짜증나다는 것을 알았습니다. 그러나 아래와 같은 기능은 그만한 가치가 있습니다.

• 유연한 매개 변수 프레임 워크, 안정적인 CMDlet을 쉽게 구축 할 수 있습니다.
• 모듈 및 내부 모듈 리포지토리는 조직 전체에서 공통 로직을 공유하여 많은 코드 중복을 방지하고 한 곳에서 리팩토링 할 수있는 핵심 기능의 중앙 집중화를 방지합니다.
• 크로스 플랫폼. PS 5.1의 Windows와 PS 6/7의 linux / mac에서 내 도구를 실행하는 사람들이 있습니다.

나는 PS 팀이 앞으로 이것을 개선하여 덜 복잡하게 만들기를 정말로 바랍니다.

위의 사항을 구현하는 것은 의심 할 여지없이 엄청난 변화이므로 아마도 옵트 인이 필요할 것입니다.

https://github.com/PowerShell/PowerShell-RFC/pull/90 구현을 의미

@aminya , 인수를 사용하여 외부 프로그램을 호출하는 것이 셸의 핵심 명령이며 제대로 작동해야한다는 데 동의합니다.

@choovick 에서 제안한 모듈은 보안에 중요한 수정 전용 유지 관리 모드에있는 _Windows PowerShell_에 여전히 적합합니다.
보완 적으로, 외부 프로그램 호출에 대한 제안 된 개념 도움말 항목이 작성되면 https://github.com/MicrosoftDocs/PowerShell-Docs/issues/5152 참조 -이전 버전 / Windows PowerShell의 문제를 수정하는 도우미 함수, 위의 @TSlivede 와 같이 직접 게시 할 수 있습니다.

@iSazonov 예, https://github.com/PowerShell/PowerShell-RFC/pull/90 구현은 제가 의미하는 바입니다 .

스레드는 끝나지 않고 변경 사항에 대한 우려가 있습니다.

링크 된 RFC에 대한 마지막 공식 응답은 2019 년 7 월 8 일부터 @joeyaiello 의이 댓글 이었습니다 (강조 추가됨).

그러나 우리는이 [RFC] 가 기존 행동과 관계없이 그리고 그것의 관계없이 엄청난 의미를 갖는다 고 생각 합니다. 이제 실험적 기능이 있으므로 실험적 기능 플래그 뒤에이 기능을 오늘 구현하는 것이 합리적이라고 생각

_ 개인적으로 _, _ 기본적으로 _ 행동을 고치는 것은 중요하지 않습니다. 비록 그것이 주요 변경이라고해도 말입니다. RFC는 실제로이를 제안하고 _old_ (깨진) 동작을 원한다면 옵트 인을 제안합니다.

유지 관리 할 레거시 코드가있는 사람들이 반대 할 것이라고 생각합니다. _ 기존의 모든 해결 방법이 기능을 멈출 것입니다 _- 위 참조-이전 버전과의 호환성을 유지하는 것이 여전히 중요한 목표 인 것 같습니다.

새롭고 고정 된 동작이 옵트 인 된 경우 올바른 동작을 얻기 위해 무언가를해야하는 어색함이 여전히 있지만 적어도 기존 코드는 손상되지 않습니다.

그러나 기존 옵트 인 메커니즘 자체는 문제가 있습니다.
이제 @KirkMunro 의 선택적 기능 RFC 가 거부되었으므로 _preference 변수 _가 거의 남고 PowerShell의 동적 범위 지정 문제가 있습니다. 새로운 기능을 사용하도록 설계되지 않은 옵트 인 범위에서 호출 된 타사 코드 그런 다음 구현이 중단 될 수 있습니다 (기본 설정 변수가 일시적으로 재설정되지 않는 한).

_Lexical_ 여기에 옵트 인 범위가 필요하지만 현재는 없습니다. Strict 모드의 _lexical_ 범위 지정에 대한 RFC 는 using 문 (특히 일반적으로 _dynamically_ 범위)을 통해 어휘 범위 기능 (또는 다른 목적)의 구현을 제안합니다. 이 패턴에 따라 어휘 범위의 using ProperExternalArgumentQuoting 문 (이름은 WIP :) (기술적으로 가능한 경우)을 고려할 가치가 있습니다.

우리는 PowerShell위원회가 (다시) 검토하고 질문이 발생할 때마다 _timely_ 피드백과 함께 진행 방법에 대한 명확한 지침을 제공해야합니다. @ SteveL-MSFT?

• 그래도 참고 --% 7.1 블로그 게시물에 의해 암시 -like 솔루션 (참조 위 ) (나는 개인적으로 생각하는 가치 추구하지 않습니다 - 볼 위에 와 이 댓글 ) - PowerShell을의 기본을 고정하는 _separate_ 기능이 될 것입니다 (비 에뮬레이션) 행동은 여전히 ​​필수입니다.

개인적으로 나는 그것이 주요한 변화 임에도 불구하고 기본적으로 행동을 고치는 것을 신경 쓰지 않을 것입니다. RFC는 실제로이를 제안하고 이전 (깨진) 동작을 원한다면 옵트 인을 제안합니다.

새롭고 고정 된 동작이 옵트 인 된 경우 올바른 동작을 얻기 위해 무언가를해야하는 어색함이 여전히 있지만 적어도 기존 코드는 손상되지 않습니다.

동의합니다. 사실 저는 기본값을 깨뜨린 다음 올바르게 구현 버그 라는 사실을 감안할 때, 새로운 동작은 선택 해제가 아닌 선택이어야합니다. 왜냐하면 예기치 않게 중단되기 쉬운 깨진 외부 셸 호출을 계속 권장하는 것은 의미가 없기 때문입니다. 방법. 어쨌든 PowerShell 7은 레거시 Windows PowerShell보다 개선하기 위해 노력해야합니다.

@ SteveL-MSFT와 저는 # 13068에 찬성하여 이것을 닫아야한다는 데 동의했습니다. 여기서 우리가 만지는 것은 모두 큰 변화에 지나지 않으므로 옵트 인 모드 역할을하는 새 운영자를 통해 문제를 해결해야합니다.

# 13068이이 문제를 해결하는 방법을 전혀 모르겠습니다. 해당 연산자가 의도 한대로 도입 된 경우 주어진 인수 배열 또는 변수에서 생성 된 콘텐츠의 명시 적 인수를 사용하여 네이티브 실행 파일을 제대로 호출 할 수있는 방법이 없습니다.

@JustinGrote 가 해당 스레드에서 제공 한 예제

@joeyaiello 해당 연산자가 실제로 존재하고 누군가가이 스레드에서 언급 된 연산자가 어떻게 개선 할 수 있는지 보여줄 때까지이 문제를 열어 둘 수 있습니까?

아 그리고 Linux는 어떻습니까? 이 문제는 Windows에서는 어리 석고 예상치 못한 문제이지만 Linux에서는 훨씬 덜 의미가 있습니다. 특히 Linux powershell 스크립트의 역사가 없어서 깨질 것입니다.

이것에 대한 특수 연산자를 만드는 것은 명령 줄 셸에 전혀 의미가 없습니다. 주된 작업은 프로그램을 시작하고 인수를 전달하는 것입니다. 이 작업을 위해 system() 를 수행하는 새 연산자를 도입하는 것은 산술에 버그가 있기 때문에 calc.exe 를 호출하는 방법을 도입하는 Matlab과 같습니다. 대신해야 할 일은 다음과 같습니다.

• pwsh 팀은 기본 제공 cmdlet 뒤에 현재 동작을 이동하여 명령 줄 항목을 수정하는 새로운 주요 릴리스를 준비합니다.
• 임시 방편 솔루션으로 곧 출시 될 pwsh 버전에는 명령 줄 전달에 대한 새롭고 올바른 동작을 사용하는 기본 제공 cmdlet이 제공됩니다.

Start-Process 에도 동일하게 적용됩니다. (사실 -QuotingBehavior Legacy ...와 같은 일부 옵션이있는 "new"cmdlet에 대한 꽤 좋은 후보입니다.) # 13089를 참조하십시오.

Powershell이이 두 상황에서 다르게 작동하는 이유는 무엇입니까? 특히, 공백을 포함하는 인수를 큰 따옴표로 묶어 일관성없이 래핑합니다.

v.7에서 일관된 결과를 얻습니다. 고정 된 것 같습니다.

PING 'A \"B'

Ping 요청이 호스트 A "B를 찾을 수 없습니다.

PING 'A\" B'

Ping 요청이 호스트 A "B를 찾을 수 없습니다.

ping 되어야하는 축어 호스트 이름은 A \"B 및 A\" B -_with_ \ 문자이기 때문에 수정되지 않았습니다.

PowerShell은 셸로서 _its_ 규칙에 따라 인수를 구문 분석 한 다음 대상 프로세스가 PowerShell 자체 구문 분석의 결과와 동일한 축어 값을 볼 수 있도록 투명하게 확인해야합니다.

_other_ 셸-전달 된 개별 인수를 추출하기 위해 _command line_을 구문 분석해야하는 방식으로 자신의 셸처럼 작동해야하는 Windows에서 실행되는 불량 프로그램- \ 를 이스케이프로 사용 문자는 여기에 그림을 입력해서는 안됩니다. (Windows에서만 필요하고 Unix에서는 축 어적 인수를 배열로 직접 전달하기 만하면됩니다) PowerShell이 ​​쉘 역할을하는 _behind the scenes_.

제쳐두고, PowerShell 자체가 " _inside '...' _ (작은 따옴표로 묶인 문자열)의 이스케이프를 요구하지 않는 것처럼 bash 와 같은 POSIX 호환 쉘도 마찬가지입니다. 예를 들어 bash 에서 실행하면 /bin/echo 'A \"B' (분명하게) A \"B 인쇄합니다 ( \ 는 작은 따옴표로 묶인 문자열에서 리터럴로 처리됨). PowerShell에서 (예기치 않게) 매우 동일한 명령이 생성됩니다.
A "B - \ 누락-여기에서 논의 된 문제의 표현입니다.

나는 명확히해야한다 :

• 궁극적으로 A "B _verbatim_을 전달하려는 관점에서 PowerShell에서 'A "B' 를 사용할 수 있어야합니다.

• PowerShell이 ​​현재 백그라운드에서 구성하는 명령 줄에는 "A "B" 가 포함되어 있습니다. 대상 프로세스는 A B 로 표시됩니다. 즉, _embedded_ " 를 이스케이프하지 않고 "..." 의 블라인드 엔클로저입니다. " 는 삽입 된 " 의 효과적인 손실을 초래했습니다. 이 경우 비하인드 스토리 명령 줄에서 PowerShell _should_ 사용하는 것은 "A \"B" 입니다. 즉, 포함 된 " \ -escaping이 필요합니다.

• 마찬가지로, 같은 블라인드 인클로저는 원인이 'A \"B' 표현하도록 "A \"B" 막후에는 그래서 _embedded_ 설정하는 일이 줄 명령 \" _escaped_로를 " 문자, 따라서 대상 프로세스는 A "B 로 간주합니다. 즉, _automatic_ 이스케이프가 없기 때문에 포함 된 \ 의 효과적인 손실이 발생했습니다. 이 경우 비하인드 스토리 명령 줄에서 PowerShell _should_ 사용해야하는 것은 "A \\\"B" 입니다. 즉, \ 및 " 이스케이프가 필요합니다.

ping 되어야하는 축어 호스트 이름은 A \"B 및 A\" B -_with_ \ 문자이기 때문에 수정되지 않았습니다.

"그것"은 여기에서 인용 된 불만을 의미하며 다행히도 재현 할 수 없습니다.

@ yecril71pl , 내가 본다 : 내 (잘못된) 가정은 "큰 따옴표 안에 공백을 포함하는 인수를 일관성없이 래핑"하는 것은 삽입 된 " 및 \ 문자 _의 자동 이스케이프 _ 부족을 나타냅니다. 이전 의견에서 설명했습니다. 이것이이 문제의 핵심입니다.

Windows PowerShell에는없는 PowerShell Core의 사소한 수정 사항이 있습니다. 지금은 하나만 생각할 수 있습니다.

• Windows PowerShell은 후행 \ 경우 블라인드 큰 따옴표를 사용합니다. 'A B\' 가 (부러짐) "A B\" 로 바뀝니다.-PS Core가 올바르게 처리합니다 ( "A B\\" ). .

이 repo는 PS Core 전용이므로 PS Core에서 여전히 손상된 부분에 집중하는 것으로 충분합니다 (차이점을 언급하는 것이 도움이 될 수 있지만 _ 제외로 _하지만 해당 측면을 명시 적으로 만드는 것이 가장 좋습니다).

그리고 염두에 두었던 시나리오조차도 _ 아직 PS Core에서 깨졌습니다.하지만 _ 인수에서 \ 를 생략 한 경우에만 _ :

'A" B' 전달하면 여전히 배후에서 _non_-double-quoted A" B 결과가 발생합니다 ( 'A\" B' 결과 "A\" B" 결과도 마찬가지입니다. 다르게).

이 repo는 PS Core 전용이므로 PS Core에서 여전히 손상된 부분에 집중하는 것으로 충분합니다 (차이점을 언급하는 것이 도움이 될 수 있지만 _ 제외로 _하지만 해당 측면을 명시 적으로 만드는 것이 가장 좋습니다).

메타 제쳐두고 : 다른 사용자의 댓글에 언급 된 잘못된 행동이 적용되지 않는다는 것을 아는 것이 유용합니다. 물론 사용자가 현재 버전을 확인하지 않았기 때문에 댓글을 무시할 수도 있습니다. 잘. 무질서한 기자들이 무질서하고 있는지 확인하는 것이 여전히 좋습니다. IMHO.

거기에는 인수가 없지만 _asides_에 _ 적절한 프레이밍 및 컨텍스트 _를 제공하는 것이 중요합니다. 실제로 인용되는 원래 주석에 _link_).

이 토론이 차이를 만드는지 궁금합니다. 위원회의 결정은 커뮤니티가 원하는 것과는 무관합니다. 태그를보십시오 : Resolution- won't fix. 그러나 PowerShell은 오픈 소스 (MIT)이기 때문에 커뮤니티는이를 별도의 포크에서 수정할 수 있으며이 PowerShellCommunity ( pwshc )를 짧게 호출 할 수 있습니다.

따라서 이전 버전과의 호환성이 필요하지 않습니다. 나중에 PowerShell 8에서위원회는 포크를 통합 할 수 있습니다.

이전 버전과의 호환성 정보 : PowerShell은 어떤 운영 체제에도 사전 설치되어 있지 않으며, 저에게 PowerShellCommunity 설치의 어려움은 PowerShell 와 동일합니다. 나는 미래의 8 버전을 기다리거나 새 연산자로 코드를 더 복잡하게 만드는 대신 커뮤니티 버전을 설치하고 즉시 사용하는 것을 선호합니다.

위원회는 모든 것을 깨뜨리기로 결정했기 때문에 그것이 얼마나 심하게 깨 졌는지 아는 것이 좋습니다. 나는 커뮤니티가 옳은 일을하는 Invoke-Native 와 함께 살 수 있다고 생각합니다. 그들의 의지에 반하여 마이크로 소프트의 얼굴을 구하는 것은 커뮤니티의 일이 아닙니다.

그들이 얼마나 심하게 부서 졌는지 아는 것이 좋습니다

나는 그 순간에 문제가 해결 될 수 없더라도 원칙적으로 올바른 일을하는 법을 아는 것 _ 원칙적으로, 때가 오면 _ 중요한 일을 아는 것-그 시간이 _ 절대 _ 주어진 언어의 맥락에서 오지 않더라도 _ 전적으로 동의합니다.

커뮤니티는 옳은 일을하는 Invoke-Native 와 함께 살 수 있습니다.

확실하게:

• Invoke-NativeShell 와 같은 것은 # 13068의 주제 인 _ 다른 사용 사례 _를 다루며, 해당 사용 사례의 경우 이러한 cmdlet은 임시 방편이 _ 아닙니다 _ : 적절한 솔루션입니다-https://github.com/ 참조 PowerShell / PowerShell / issues / 13068 # issuecomment -656781439

• _이 _ 문제는 _PowerShell 자체 _ (플랫폼 -_ 네이티브 _ 기능에 관한 것이 아님)를 수정하는 것이며, 이에 대한 _stopgap_ 솔루션은 낮은 의식을 제공하는 것입니다. _opt-in_-따라서 기능 iep 를 기본 -in 함수, 이전 버전과의 호환성을 실질적으로 중단 할 수있는 향후 버전에서 _proper_ 수정을 보류합니다.

Microsoft의 얼굴을 구하는 것은 커뮤니티의 일이 아닙니다.

@aminya 의 우려는 누군가의 얼굴을 구하는 것이 아니라 셸의 핵심 임무 인 영역에서 근본적으로 손상된 행동을 수정하는 것입니다.

즉, 포크로 PowerShell 에코 시스템을 조각화하는 것이 올바른 방법인지 잘 모르겠습니다.

지금은이 모든 것에 응답 할 시간이 없지만 이것이 합리적이라고 생각하므로 다시 시작하겠습니다.

해당 연산자가 실제로 존재하고 누군가가이 스레드에서 언급 된 연산자를 어떻게 개선 할 수 있는지 보여줄 때까지이 문제를 열어 둘 수 있습니까?

관련 문제에서 말했듯이 네이티브 호출 연산자는 UX에 복잡성 을 추가하고 잘못된 방향입니다.
동시에 여기서 전체 논의는 네이티브 애플리케이션과의 상호 작용을 단순화 하는 것입니다.

우리를 막는 유일한 것은 그것이 파괴적인 변화라는 것입니다. 우리는 이것이 너무 많은 파괴라고 여러 번 말했지만, 그것을 평가 해 보겠습니다.

대화 형 세션을 살펴 보겠습니다. 사용자는 새 PowerShell 버전을 설치하고 기본 애플리케이션을 호출 할 때 새로운 동작을 발견합니다. 그가 뭐라고 말할까요? "감사합니다. 드디어 타이핑 만하면 작동합니다!"라고 말할 것입니다.

스크립트 실행 / 호스팅 시나리오를 살펴 보겠습니다. 새로운 버전의 애플리케이션 (하나만 변경하더라도!)은 비즈니스 프로세스를 망칠 수 있습니다. 우리는 항상 이것을 기대하고 업데이트 후 프로세스를 확인합니다. 문제를 발견하면 몇 가지 방법이 있습니다.

• 업데이트 롤백
• 스크립트에 대한 빠른 수정 준비
• 이러한 문제가 해결되거나 시간이 지남에 따라 자체적으로 죽을 때까지 스크립트를 중단하는 기능을 끄십시오.

_ 버전 업데이트는 항상 무언가를 깨뜨리기 때문에 마지막 옵션은 우리가 가질 수 있고 받아 들일 수있는 최선입니다 ._

(현재 PowerShell Core는 Windows의 구성 요소가 아니므로 호스팅 응용 프로그램을 직접 망칠 수 없으며 스크립트 만 직접 영향을 받는다는 점을 지적하고 싶습니다.)

위에서 Jason이 말한 것을 상기시키고 싶습니다. 이것은 버그 수정입니다.
모든 사람을 위해 문제를 해결하고 모든 것을 단순화하겠습니다. 사용자가 powershell-y 합니다.

관련 문제에서 말했듯이 네이티브 호출 연산자는 UX에 공모 를 추가하며 잘못된 방향입니다.

복잡성 ❓

대화 형 세션을 살펴 보겠습니다. 사용자는 새 PowerShell 버전을 설치하고 기본 애플리케이션을 호출 할 때 새로운 동작을 발견합니다. 그가 뭐라고 말할까요? "감사합니다. 드디어 타이핑 만하면 작동합니다!"라고 말할 것입니다.

저는 다른 시나리오가 있습니다. 새로운 사용자가 PowerShell을 사용해보고, 불가사의하게 실패한다는 사실을 깨닫고, 휴지통으로 옮기고 절대 반환하지 않습니다. 그게 내가 할 일입니다.

스크립트에 대한 빠른 수정 준비

그것은 사용자 스크립트에서 명백한 경우를 다루기 위해 우리가해야 할 일입니다.

불가사의하게 실패한다는 것을 깨닫다

여기서 전체 논의는이 "신비한 실패"를 제거하는 것입니다. 그리고이를 단순화하면서 새로운 신비한 것들을 추가하지 않는 것이 가장 좋습니다.

여기에서 전체 논의는 이것을 제거하는 것에 관한 것입니다. 그리고이를 단순화하면서 새로운 신비한 것들을 추가하지 않는 것이 가장 좋습니다.

우리는 실행 가능한 프로그램을 직접 호출하는 기능을 없애고 싶지 않습니다.

이전 호출은 무언가가 이미 인용되었는지 여부를 추측하여 cmdline에 직접적이지 않습니다. 또한, 상기 능력은 여전히-%로 유지됩니다.

또한, 상기 능력은 여전히-%로 유지됩니다.

--% 에는 미리 정의 된 명령 줄이 필요하므로 유틸리티가 제한됩니다.

뿡 빵뀨

우리는 실행 가능한 프로그램을 직접 호출하는 기능을 없애고 싶지 않습니다.

@iSazonov 는 버그가있는 동작을 제거하는 것을 의미한다고 생각합니다. 즉, 기존의 해결 방법을 깨는 것을 의미하더라도 버그를 올바르게 수정 (추가 구문을 통한 옵트 인없이)하는 것입니다. 맞아요, @iSazonov?

@ Artoria2e5 :

이전 호출은 이미 인용되었는지 여부를 추측하여 cmdline에 직접적이지 않습니다.

[_ 업데이트 _ : 인용 된 줄을 잘못 읽었지만 정보가 여전히 흥미 롭기를 바랍니다.]

• _guess_ 할 필요가 없으며 규칙은 간단합니다.

  • _ 명령 이름 또는 경로가 _quoted_- '/foo bar/someutil '-및 / 또는 _variable 참조 (또는 표현식)가 포함 된 경우- $HOME/someutil - & 가 _required_ 인 경우에만 해당됩니다.

• 이러한 요구가 불행하다고 생각할 수도 있지만 PowerShell 언어의 핵심이며 두 가지 기본 구문 분석 모드 인 인수 모드와 표현식 모드를 구문 적으로 구별 할 수 있어야합니다.

  • 이 문제는 _external 프로그램 _ 호출에만 국한되지 않습니다. 따옴표로 묶인 문자열 / 변수 참조를 통해 지정된 경우 기본 PowerShell 명령에도 & 호출이 필요합니다.

• 이 간단한 규칙을 외우고 싶지 않다면 더 간단한 규칙은 다음과 같습니다. _always_ use & , 당신은 괜찮을 것입니다-아무것도 필요하지 않은 것보다는 다소 덜 편리하지만 정확히 고난은 아닙니다 (그리고 더 짧습니다. --% , 이것은 절대적으로 잘못된 솔루션입니다-아래 참조)

상기 능력은 여전히-%로 유지됩니다.

[_ 업데이트 _ : 인용 된 줄을 잘못 읽었지만 정보가 여전히 흥미 롭기를 바랍니다.]

아니요, # 13068과 _this_ 문제의 불행한 혼동에도 불구하고, --% -_its_, 변함없이 _platform-specific_ 구문을 사용하여 _native shell_을 호출하는 기능은 당면한 문제에 대한 해결 방법이 아닙니다. 그것은 혼란을 더할뿐입니다 .

--% 는 매우 다른 사용 사례이며 현재 제안 된대로 심각한 제한이 있습니다. _operator_를 도입 할 가치가 _ 않은 _ 무언가가 있다면 (또는 기존의 동작을 변경하는) 명령 줄을 네이티브 셸에 전달할 수있는 능력입니다 (물론 sh -c '...' 이미 직접 수행 할 수 있습니다.) cmd /c '...' , _이 문제가 해결 된 경우에만 강력하게 적용 _; 바이너리 Invoke-NativeShell / ins cmdlet 구현, 주로 대상 셸의 세부 정보 추상화 CLI 구문은 당면한 문제를 피할 수 있으므로 ( System.Diagnostics.ProcessStartInfo.ArgumentList 를 직접 사용하여) 독립적으로 구현할 수 있습니다.

뿡 빵뀨

저는 다른 시나리오가 있습니다. 새로운 사용자가 PowerShell을 사용해보고, 불가사의하게 실패한다는 사실을 깨닫고, 휴지통으로 옮기고 절대 반환하지 않습니다. 그게 내가 할 일입니다.

명확하게 설명해 주시겠습니까? powershell의 현재 동작이 이러한 불쾌한 사용자 경험으로 이어질 수 있는지, 아니면 제안 된 변경 사항이 해당 사용자 경험으로 이어질까 두렵습니까?

제 생각에는 powershell의 현재 동작이 그러한 경험을 생성 할 가능성이 훨씬 더 높기 때문입니다. 위에서 말했듯이 : powershell의 현재 동작은 버그로 간주되어야합니다.

새 사용자가 PowerShell이 ​​손상되는 것을 알지 못하는 상태에서 왜곡 된 인수로 명령을 실행하는 이유는 무엇입니까?

@ yecril71pl 절대적으로 확신 할 수 있습니다. 제안 된 수정 사항이 아니라 인수에 대해 현재 필요한 형식이 "일그러진"것으로 간주됩니다.

나는 당신의 질문이 내가 불치의 괴짜라는 당신의 가정에서 비롯된 것이라고 생각합니다. 맞습니다. 그러나 저는 정상적인 임의의 챕터가 왜곡 된 것으로 간주하는 것을 상상할 수있는 능력을 유지했습니다.

뿡 빵뀨
@ Artoria2e5 는 다음과 같이 말할 때 인수 배열을 단일 lpCommandLine 문자열로 변환하는 것에 대해 이야기하고 있다고 생각합니다.

이전 호출은 이미 인용되었는지 여부를 추측하여 cmdline에 직접적이지 않습니다.

전화 할 때

echoargs.exe 'some"complicated_argument'

powershell이 some"complicated_argument 주위에 따옴표를 추가하는지 여부를 추측해야합니다.

예 1 : 대부분의 powershell 버전에서
echoarg.exe 'a\" b' 및 echoarg.exe '"a\" b"' 는
"C:\path\to\echoarg.exe" "a\" b" (테스트 버전 2.0; 4.0; 6.0.0-alpha.15; 7.0.1)
하지만 Win10 (버전 5.1.18362.752)의 기본 powershell은
echoarg.exe 'a\" b' ~ "C:\path\to\echoarg.exe" a\" b 및
echoarg.exe '"a\" b"' ~ "C:\path\to\echoarg.exe" ""a\" b"" .

예 2 : 이전 powershell 버전 번역
echoarg.exe 'a"b c"' ~ "C:\path\to\echoarg.exe" "a"b c"" (테스트 버전 2.0; 4.0;)
최신 버전은
echoarg.exe 'a"b c"' ~ "C:\path\to\echoarg.exe" a"b c" (테스트 버전 5.1.18362.752; 6.0.0-alpha.15; 7.0.1).

동작이 이미 여러 번 변경되었으므로 예상 동작을 얻기 위해 한 번 더 변경할 수없는 이유를 알 수 없습니다.

@TSlivede , 명확히 해주셔서 감사합니다. @ Artoria2e5라고 잘못 해석해서 죄송합니다.

실제 문제는 100 % 동의합니다. 실제로 lpCommandLine 가 Windows의 배후에서 사용되는 결과에 대해 생각할 필요조차 없습니다. PowerShell이 ​​옳은 일을했다면 아무도 할 필요가 없을 것입니다 (가장 큰 경우를 제외하고는 PowerShell의 잘못이 아닙니다. 이때 --% (현재 구현 됨))가 도움이 될 수 있습니다. Unix와 유사한 플랫폼의 경우).

단순히 문제를 올바르게 수정하는 것에 관해서는 분명히 내 투표가 있습니다 (그러나 기존 해결 방법은 깨질 것입니다).

요약 : Microsoft Windows NT 하위 시스템의 모든 프로그램에 대한 인수로 모든 값을 안정적으로 전달할 수 있다는 가정은 잘못 되었으므로 이것이 우리의 목표 인 척하는 것을 중단해야합니다. 그러나 논쟁의 범위 를 고려하면 여전히 구출 할 것이 많다.

네이티브 Windows 실행 파일을 호출 할 때 원래 인용문을 유지해야합니다. 예:

CMD /CSTART="WINDOW TITLE"

시스템이 WINDOW 파일을 찾을 수 없습니다.

 { CMD /CSTART="WINDOW TITLE" }. Ast. EndBlock. Statements. PipelineElements. CommandElements[1]

StringConstantType

BareWord

값

/ CSTART = 창 제목

StaticType

System.String

범위

/ CSTART = "창 제목"

부모의

CMD / CSTART = "창 제목"

범위 를 템플릿으로 사용하면 아무것도 잃지 않고 예상대로 네이티브 실행 파일을 호출 할 수 있습니다. 문자열 인수를 사용하는 해결 방법은 여기에서 작동하지만 PowerShell 내에서 적절한 지원이 구현되는 경우 기술적으로 엄격히 필요하다고 생각하지 않습니다. 이 접근 방식은 모든 경우에 적용됩니다.

백 슬래시 이스케이프를 해석하는 도구 ( TASKLIST "\\\"PROGRAM FILES" )와 해석하지 않는 도구 ( DIR "\""PROGRAM FILES" /B ) 및 방해하지 않는 도구 ( TITLE A " B ). 그러나 이스케이프하려는 경우 백 슬래시를 사용하는 표준 이스케이프는 단순히 따옴표를 전혀 지원하지 않고 이중 백 슬래시 \\ 완전히 다른 의미를 갖기 때문에 모든 일반적인 파일 관리 도구를 손상시킵니다 ( DIR "\\\"PROGRAM FILES" /B 시도). CMD /CECHO='A " B' )를 제공 할 수 없습니다.

환경 변수는 CMD 값을 나타내지 않고 환경 변수가 확장 될 때 다시 구문 분석되는 코드 조각을 나타내며 다른 명령에 대한 인수로 안정적으로 처리 할 수있는 규정이 없습니다. CMD 는 현재 수수께끼의 근본 원인 인 것처럼 보이는 문자열이 아닌 어떤 종류의 객체에서도 작동하지 않습니다.

요약 : Microsoft Windows NT 하위 시스템의 모든 프로그램에 대한 인수로 모든 값을 안정적으로 전달할 수 있다는 가정은 _wrong_이므로 이것이 우리의 목표 인 척하는 것을 중지해야합니다.

그게 목표가되어야하지 않나요? 프로그램이 수신하는 인수를 해석 할 수 없다면 PowerShell의 문제가 아닙니다.

네이티브 Windows 실행 파일을 호출 할 때 원래 인용문을 유지해야합니다. 예:

CMD /CSTART="WINDOW TITLE"

프로그램 호출이 PowerShell에서 호출 된 프로그램이 사용하는 언어로 동적으로 변경되어야한다고 제안하고 있습니까? 이 예제는 PowerShell에서 작성했습니다. 즉, 다음 중 하나와 동일해야합니다.

CMD "/CSTART=WINDOW TITLE"
CMD '/CSTART=WINDOW TITLE'
CMD /CSTART=WINDOW` TITLE

요약 : Microsoft Windows NT 하위 시스템의 모든 프로그램에 대한 인수로 모든 값을 안정적으로 전달할 수 있다는 가정은 _wrong_이므로 이것이 우리의 목표 인 척하는 것을 중지해야합니다.

그게 목표가되어야하지 않나요? 프로그램이 수신하는 인수를 해석 할 수 없다면 PowerShell의 문제가 아닙니다.

이 프로그램 CMD 해석 할 수있는 인수 /CECHO=A " B 하지만 PowerShell을을 왜곡없이 전달할 수 없습니다.

네이티브 Windows 실행 파일을 호출 할 때 원래 인용문을 유지해야합니다. 예:

CMD /CSTART="WINDOW TITLE"

프로그램 호출이 PowerShell에서 호출 된 프로그램이 사용하는 언어로 동적으로 변경되어야한다고 제안하고 있습니까? 이 예제는 PowerShell에서 작성했습니다. 즉, 다음 중 하나와 동일해야합니다.

CMD "/CSTART=WINDOW TITLE"
CMD '/CSTART=WINDOW TITLE'
CMD /CSTART=WINDOW` TITLE

Microsoft Windows NT 하위 시스템에서 외부 프로그램과 인터페이스 할 때 PowerShell은 모두 PowerShell과 동일하지만 수신 프로그램과 동일하지 않은 인수를 인코딩하는 무수한 방법을 제공한다고 제안하려고했습니다. 사용자가 실제로 어떤 인용 배열을 사용했는지에주의를 기울이지 않고 주장을 인코딩하는 One True Way ™를 무뚝뚝하게 강요하는 것은 도움이되지 않습니다.

@ yecril71pl 나는 당신의 의견에 정말 혼란 스럽습니다. 여기서 정확히 무엇을 제안하고 있습니까? 사용 사례는 모두 --% 됩니다. 이전에 다음과 같이 말하여 닫았습니다.

--% 에는 사전 정의 된 명령 줄이 필요하므로 유틸리티가 제한됩니다.

그러나 실제로 --% 와 함께 환경 변수를 사용할 수 있습니다. 이 시도:

PS > $env:mytitle='WINDOW TITLE'
PS > cmd --% /CSTART="%mytitle%"

그래서 나는 무엇을 놓치고 있습니까?

우리는 구문을 누락 CMD /CSTART="$mytitle" 하는 것을 누설하지 않고, ENV: .

끔찍한 생각으로 Environment.ExpandEnvironmentVariables 를 다른 것으로 대체 할 수있는 옵션이 있습니다. 어쨌든 Unix에는 기본 구현이 없으며 C #으로 다시 작성하면 처리하는 작업이 성능에 중요해질 것이라고 생각하지 않습니다.

어쨌든 env var 이름에는 등호가 허용되지 않으므로 %=$a% 의미 $a 가질 수 있습니다. 이것은 JS의 템플릿 문자열처럼 작동하도록 만드는 것과 같은 매우 유연하고 (아마도 나쁜) 확장을 허용하면서 기존의 어떤 것도 깨뜨리지 않을 것입니다. 지옥, 우리는 %VARNAME=$var% 도 일종의 대체 구문으로 정의 할 수 있습니다.

문서화 지옥에 관해서는 이것이 ... 사과드립니다.

• 파싱 ​​문제가 _ 아닙니다 _.

• 우리가 가지고있는 것은 _PowerShell이 ​​_its_ 구문 분석의 결과 인 문자열 화 된 인수를 외부 (네이티브) 실행 파일로 전달하는 방법에 대한 문제입니다.

  • _Windows_에서 문제는 백그라운드에서 생성 된 외부 실행 파일을 호출하는 명령 줄 이 Microsoft C / C ++ 컴파일러 설명서의 Parsing C ++ 명령에 자세히 설명 된대로 인수 인용에 가장 널리 사용되는 규칙을 따르지 _ 않는다는 것입니다 . 줄 인수 섹션.

  • 현재 일어나는 일은 _different_ 규칙이 사용된다는 것조차 아닙니다. 아마도 감독으로 인해 생성 된 명령 줄은 포함 된 큰 따옴표와 공백의 조합과 관련된 인수의 특성에 따라 상황에 따라 _ 구문 적으로 근본적으로 깨졌습니다 _ 뿐만 아니라 빈 문자열 인수.

  • 궁극적으로 문제는 Windows에서 프로세스 생성의 기본 아키텍처입니다. 인수를 인수의 _array_로 전달하는 대신 _ 명령 줄로 _-_all_ 인수를 나타내는 단일 문자열-프로세스에 전달할 인수를 인코딩해야합니다. 유닉스 계열 플랫폼이 수행하는 방식입니다). 명령 줄을 전달하려면 _ 인용 및 이스케이프 규칙 _을 구현해야하며, 주어진 명령 줄을 해석하는 방법은 궁극적으로 _ 각 프로그램에 달려 있습니다. 사실상, 이것은 불필요하게 프로그램이 일종의 미니 셸이되도록 강제하는 것과 같습니다. 그들은 셸이 이미 수행 한 작업을 _ 재수 행해야하는데, 이는 _shell only_의 범위 여야하는 작업입니다. 유닉스의 경우), 즉 명령 줄을 개별 인수로 구문 분석합니다. 간단히 말해서, 이것은 Windows에서 전달되는 인수 인 무정부 상태입니다 .

  • 실제로, 무정부 상태는 앞서 언급 한 규칙을 준수하는 _most_ 프로그램에 의해 완화되며, 개발중인 새로운 프로그램은이 규칙을 준수 할 가능성이 매우 높습니다. 주로 콘솔 응용 프로그램을 뒷받침하는 널리 사용되는 런타임이 이러한 규칙 (예 : Microsoft C / C ++ / .NET 런타임). 따라서 현명한 해결책은 다음과 같습니다.

    • 백그라운드에서 명령 줄을 빌드 할 때 PowerShell이이 규칙을 준수하도록합니다.
    • cmd.exe , 배치 파일 및 msiexec.exe 및 msdeploy.exe 와 같은 Microsoft 유틸리티를 포함하는이 규칙을 따르지 _ 않는 _ "악성"프로그램의 경우 명시 적으로 대상 실행 파일에 전달 된 명령 줄을 제어합니다. 이것이 --% , 파싱 ​​중지 기호가 제공하는 것입니다-비록 상당히 어색 하긴하지만.

  • _Unix_에서 문제는 _a 명령 줄이 완전히 생성되고 있다는 것입니다 _-대신 축어 인수 배열이 _as-is_로 전달되어야합니다. 대신 .NET Core가 지원하는 ProcessStartInfo.ArgumentList ; -현명하게도-_ 명령 줄이없고 _ 프로세스가 Unix와 같은 플랫폼에서 생성 될 때 인자 배열 만 있다는 점을 감안할 때 항상 _이를 지원해야합니다.

  • ProcessStartInfo.ArgumentList 사용하면 Unix의 모든 문제가 사라집니다.

이러한 문제를 해결하는 것은 @TSlivede 의 https://github.com/PowerShell/PowerShell-RFC/pull/90 이 전부입니다.

https://github.com/PowerShell/PowerShell-RFC/pull/90#issuecomment -650242411에서 저는 배치 파일의 "악성"에 대한 추가 자동 보상을 제안했습니다. -Azure와 같은 프로필 소프트웨어 (CLI az 는 배치 파일로 구현 됨, az.cmd ).
마찬가지로 msiexec.exe 및 msdeploy.exe 및 기타 유명 "악성"Microsoft CLI에 대해서도 동일한 작업을 수행하는 것을 고려해야합니다.

방금 ie 함수 를 통해 위의 모든 사항을 처리하는 모듈 Native , ( Install-Module Native -Scope CurrentUser )를 게시했습니다 ( i nvoke (external) e xecutable의 약어입니다. 위에서 소개 iep 함수의보다 완전한 구현입니다.

또한 # 13068을 주소로하는 ins ( Invoke-NativeShell ) 및 인수 전달 진단을위한 dbea ( Debug-ExecutableArguments )도 포함 됩니다 . https : // github를 참조하세요 com / PowerShell / PowerShell / issues / 13068 # issuecomment -671572939를 참조하세요.

즉, ie 는이 문제가 해결 될 때까지 기다리는 동안 간단하게 호출 앞에 ie 를 명령으로 사용하여 눈에 띄지 않는 임시 방편 역할을 할 수 있습니다.

대신에:

# This command is currently broken, because the '{ "name": "foo" }' argument isn't properly passed.
curl.exe -u jdoe  'https://api.github.com/user/repos' -d '{ "name": "foo" }'

다음을 사용합니다.

# OK, thanks to `ie`
ie curl.exe -u jdoe  'https://api.github.com/user/repos' -d '{ "name": "foo" }'

CMD /CSTART="WINDOW TITLE" 예제 (더 많은 관용적 형식은 이미 작동하는 cmd /c start "WINDOW TITLE" ) :

본질적으로 msiexec / msdeploy 대한 prop="<value with spaces>" 인수와 동일한 문제입니다. PowerShell-정당하게- /CSTART="WINDOW TITLE" 를 "/CSTART=WINDOW TITLE" . 그러나 cmd.exe 호출이 중단됩니다.

이 문제를 해결하는 방법에는 두 가지가 있습니다.

• ins / Invoke-NativeShell 위임합니다 ( cmd.exe /c 이 사실상 암시된다는 점에 유의하십시오) :

  • ins 'START="WINDOW TITLE"'
  • _expandable_ 문자열을 사용하는 경우 명령 문자열에 PowerShell 값을 포함 할 수 있습니다.
    
    
    
    • $title = 'window title'; ins "START=`"$title`""
    
    

• 또는 현재 --% 구현을 사용하되 제한 사항에 유의하십시오.

  • cmd --% /CSTART="WINDOW TITLE"
  • 설명했듯이 --% 의 문제가되는 제한은 _PowerShell_ 값을 포함하는 유일한 방법은 _aux를 사용하는 것입니다. 환경 변수 _ 및 %...% 구문으로 참조하십시오.
    
    
    
    • $env:_title = 'window title'; cmd --% /CSTART="%_title%"
    
    
    • 이러한 제한을 피하려면 --% 는 항상 _single_ 문자열 인수로 구현되어야합니다. 예 :
      
      cmd --% '/CSTART="WINDOW TITLE"' 또는 cmd --% "/CSTART=`"$title`"" -하지만 이전 버전과의 호환성을 깨뜨리지 않고는 변경할 수 없으므로 _new_ 기호를 도입해야합니다. 개인적으로 나는 기호가 필요하다고 생각하지 않습니다.
    
    

• 셸이 이미 수행 한 작업을 _ 재 수행 _해야합니다.

나는 CMD.EXE 가 명령 줄을 인수로 분할한다고 생각하지 않습니다. 필요한 유일한 것은 호출 할 실행 파일을 찾는 것이고 나머지는 사용자가 작성한 명령 줄뿐입니다 (환경 변수 대체 후, 인수 경계에 관계없이 수행됩니다.) 물론 내부 쉘 명령은 여기서 예외입니다.

본질적으로 msiexec / msdeploy 대한 msiexec prop="<value with spaces>" 인수와 동일한 문제입니다.

나는 어느 쪽도 자신있는 사용자가 아니기 때문에 더 친숙한 것을 가져 오는 것을 선호했습니다.

명확하게 말하면 다음은 이전 댓글에서 언급 한 사항에 영향을 미치지 않습니다.

CMD.EXE 명령 줄을 인수로 분할한다고 생각하지 않습니다.

• _external 실행 파일 _ (하위 프로세스의 다른 실행 파일에 의해 실행되는 명령)을 호출 할 때 _explicit_ 분할없이 벗어날 수 있지만 _batch files_에 대해서는이를 수행해야합니다.

• 외부 실행 파일을 호출 할 때에도 주어진 메타 문자 (예 : & )에 _syntactic_ 기능이 있는지 또는 큰 따옴표로 묶인 인수의 일부인지 따라서 처리해야하는지 여부를 결정하려면 인수 경계를 _ 인식해야합니다. 문자 그대로 :

:: OK - the "..." around & tells cmd.exe to use it verbatim
C:\>echoArgs.exe one "two & three"
Arg 0 is <one>
Arg 1 is <two & three>

Command line:
"C:\ProgramData\chocolatey\lib\echoargs\tools\EchoArgs.exe" one "two & three"

또한 cmd.exe 는 _embedded_ " 문자를 인식합니다. "..." 에서 "" 로 이스케이프되면 문자열이 인식됩니다.

:: OK - the "" is recognized as an escaped "
C:\>echoArgs.exe "3"" of rain & such."
Arg 0 is <3" of rain & such.>

Command line:
"C:\ProgramData\chocolatey\lib\echoargs\tools\EchoArgs.exe" "3"" of rain & such."

불행히도, cmd.exe _only_는 (Windows 전용) "" 하며 더 널리 사용되는 \" 도 지원하지 않습니다 (유닉스에서 POSIX와 유사한 _shells__exclusively_ 사용)-참고 : _programs_가 아닌 _shells_. 프로그램은 셸의 구문 분석 결과 인 축 어적 인수 배열 만 볼 수 있기 때문입니다.

Windows의 대부분의 CLI는 _both_ "" 및 \" 하지만 일부는 _only_ \" (특히 Perl 및 Ruby)를 이해하면 문제가 발생합니다.

:: !! BROKEN: cmd.exe misinterprets the & as *unquoted*, thinks it's the statement-sequencing operator, 
:: !! and tries to execute `such`:
C:\>echoArgs.exe "3\" of rain & such."
Arg 0 is <3" of rain >

Command line:
"C:\ProgramData\chocolatey\lib\echoargs\tools\EchoArgs.exe" "3\" of rain

'such."' is not recognized as an internal or external command,
operable program or batch file.

따라서:

• 가능하면 cmd.exe 직접 전화하지 마십시오.

  • _PowerShell's_ 구문을 사용하여 외부 실행 파일을 직접 (이 문제가 해결되면) 또는 ie (현재로서는)를 통해 호출합니다.

• cmd.exe 를 호출해야하는 경우 일반적인 단순성을 위해 ins / Invoke-NativeShell 를 사용하고 특히 명령 줄에 PowerShell 변수 및 식 값을 포함하는 것이 얼마나 쉬운 지에 대해 사용합니다. .

  • 여전히 cmd.exe 직접 호출하는 합법적 인 이유는 파이프 라인의 원시 바이트 데이터에 대한 PowerShell의 지원 부족을 보완하기위한 것 입니다. 예제는

나는 여기서 많은 문제를 발견 할 것이라는 것을 알고 있으며 토론의 깊이에 대해 정말 감사하지만 ... 오리 ... 실제 시나리오에서 실제로 중요한이 사례를 가진 사람이 있습니까? ?

Windows 인수 구문 분석에 현재 존재하는 "무정부 상태"를 해결하기 위해 PowerShell에서 권한을 부여받지 못한 것은 제 생각입니다. 문제를 해결할 수없는 많은 동일한 이유 때문에 Windows 및 VC ++ 컴파일러가이 동작을 중단하지 않기로 선택한 이유가 있습니다. 그것은 만연하고, 우리가 무언가를 바꾸면 새롭고 (대부분 해독 할 수없는) 문제들의 정말 긴 꼬리를 만들 것입니다.

이미 크로스 플랫폼이고 Windows와 Linux (예 : Docker, k8s, Git 등) 사이에서 많이 사용되는 유틸리티의 경우이 문제가 현실 세계에서 나타나지 않습니다.

그리고 저조한 작업을 수행하는 "불량"응용 프로그램의 경우 대부분 레거시 Windows 전용 유틸리티입니다.

@ mklement0에 대해 설명

매우 기본적인 사용법은 다음과 같습니다.

❯ git commit --allow-empty -m 'this is what we call a "commit message" which contains arbitrary text, often with punctuation'
error: pathspec 'message which contains arbitrary text, often with punctuation' did not match any file(s) known to git
❯ $a = 'this is what we call a "commit message" which contains arbitrary text, often with punctuation'
❯ git commit --allow-empty -m "$a"
error: pathspec 'message which contains arbitrary text, often with punctuation' did not match any file(s) known to git

❯ $PSVersionTable

Name                           Value
----                           -----
PSVersion                      7.0.3
PSEdition                      Core
GitCommitId                    7.0.3
OS                             Microsoft Windows 10.0.19042
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

git.exe 은 (는) 잘 작동하는 애플리케이션이므로 PowerShell의 수정은 간단하지만 모든 스크립터가 스마트 한 해결 방법을 되돌려 야합니다. cmd.exe 은 (는) 적응하기가 더 어렵고 몇 가지 문제를 해결할 수 있지만 전부는 아닐 수있는 훨씬 더 사려 깊은 접근 방식이 필요합니다. PowerShell이 ​​Windows NT 도구로 시작되었다는 점을 고려하면 실제로 끔찍합니다. 나는이 질문을 _ cmd.exe 와 같은 잘못 작동하는 레거시 유틸리티가 PowerShell에서 인터페이스에 문제를 일으키는 방식으로 호출되는 실제 시나리오가 있는지 여부를 이해합니다 _. PowerShell은 cmd.exe 에있는 대부분의 기능을 복제하여 cmd.exe 중복되도록이 문제에 접근하려고했습니다. 이는 다른 도구에서도 가능합니다. 예를 들어 MSI는 ActiveX를 통해 작동 할 수 있지만 그렇게하려면 상당한 지식이 필요합니다. 따라서 다루지 않는 필수 항목이 있습니까?

@ PowerShell / powershell-committee가 이에 대해 논의했습니다. 실제 세계에서 매력적인 예제를 명확하게 보여주는 git 예제에 감사드립니다. 우리는 7.2 초반에 그러한 주요 변경 사항을 적용했을 때의 영향을 검증하기 위해 실험적인 기능이 있어야한다는 데 동의했습니다. 추가 테스트 예제는 --% 도 파싱되지 않았어야하는데 문제가 있음을 보여줍니다.

PS> testexe --% -echoargs 'a b c "d e f " g h'
Arg 0 is <'a>
Arg 1 is <b>
Arg 2 is <c>
Arg 3 is <d e f >
Arg 4 is <g>
Arg 5 is <h'>

이것은 기본 명령 매개 변수 바인더의 문제인 것으로 보입니다.

예, @cspotcode 감사합니다. 그 예는 제게 확실히 아하 순간이었습니다.

저는 여전히 브레이킹 체인지 측면에 대해 우려하고 있으며, 이것이 여러 버전의 PowerShell에서 실험적으로 남아있을 수있는 실험적 기능에 대한 후보가 될 수 있다는 것이 제 생각이며, 이는 우리가 결국 만들 것이라고 확신하는 것이 아닙니다.

또한 RFC @ mklement0 의 허용 목록 / "루즈 앱"측면을 이해하기 위해 더 자세히 조사해야합니다. 그런 목록을 유지하기 위해 얼마나 등록 할 것인지 모르겠습니다.

@joeyaiello 와 @ SteveL-MSFT, 먼저 메타 관찰을하겠습니다.

@cspotcode 의 예제가 문제에 대한 _glimpse_를 제공 좋지만 , 귀하의 응답은 여전히 ​​근본적인 문제에 대한 근본적인 이해와 감사의 부족을 배신합니다 (나중에이 점을 논의 할 것입니다). .

이것은 _ 개인적 _ 판단이 아닙니다. 저는 매우 얇게 펴서 짧은 시간에 매우 광범위한 주제에 대해 결정을 내려야하는 것이 얼마나 어려운지 잘 알고 있습니다.

그러나 이것은 _structural_ 문제를 가리 킵니다. @ PowerShell / powershell-committee가 논의중인 문제에 대한 피상적 인 이해를 기반으로 일상적으로 결정을 내리는 것으로 보이며 커뮤니티 전체에 해를 끼칩니다.

나에게 여기서 논의되는 문제에 대한위원회의 반응은 지금까지이 구조적 문제의 가장 중요한 예입니다.

따라서 이것을 고려해 주시기 바랍니다.

위원회가 협의하는 주제별 _sub_-위원회를 임명하는 것은 어떻습니까? 관련 문제에 대해 필요한 이해를 가지고 있습니까?

testexe SteveL-MSFT의 콘텐츠를 공유 할 수 있습니까?

@TSlivede 는 https://github.com/PowerShell/PowerShell/issues/13068#issuecomment -665125375에 문제를 적절하게 요약했습니다.

반면 PowerShell은 셸이라고 주장합니다 (# 1995가 해결 될 때까지 _is_ 셸이라고 말하지 않겠습니다).

이전에 여러 번 언급했듯이 쉘의 핵심 임무는 인수를 사용하여 외부 실행 파일을 호출하는 것입니다.

큰 따옴표와 빈 문자열 인수가 포함 된 인수가 올바르게 전달되지 않았기 때문에 PowerShell은 현재이 명령을 이행하지 못합니다.

앞서 언급했듯이, 가능한 외부 CLI가 부족하여이 문제가 거의 드러나지 않는 Windows 전용 시대에는 문제가 적었을 수 있지만, 요즘은 사라지고 PowerShell이 ​​신뢰할 수있는 크로스 플랫폼으로 자리 매김하려는 경우 이 문제를 해결해야합니다.

@cspotcode 의 git 예제는 좋은 것입니다. JSON 문자열을 전달하려는 실행 파일 (예 : curl 은 다음과 같습니다.

# On Unix; on Windows, 
#   echoArgs.exe '{ "foo": "bar" }' 
# would show the same problem.
PS> /bin/echo '{ "foo": "bar" }'
{ foo: bar }  # !! Argument was incorrectly passed.

이전 버전과의 호환성을 제쳐두고 :

• Unix에서 문제는 배후에서 ProcessStartInfo.ArgumentList 를 사용하여 사소하고 _ 완전히 _ 해결됩니다.

• Windows에서 문제는 사소하게 해결되며 ProcessStartInfo.ArgumentList 배후에서 사용하여 _ 대부분 _ 해결됩니다.

  • 엣지 케이스 ( "불량"CLI)의 경우 ( 잘못 구현 됨 ) --%
  • _ 예의로, 우리는 --% 의 필요성을 줄이기 위해 잘 알려진 특정 케이스를 보상 할 수 있습니다. 아래를 참조하십시오.

따라서 _ 가능한 한 빨리 _ 다음 중 하나를 선택해야합니다.

• 인수 전달이 제대로 작동하도록하는 것의 중요성을 인식하고 _ 역 호환성을 희생하여 수정합니다 _.

• 이전 버전과의 호환성이 정말 중요하다면 Native 모듈 에서 ie 함수와 같은 새 연산자 또는 함수를 제공하여 문제를 해결하고 외부를 호출하는 유일한 신뢰할 수있는 방법으로 널리 공개하십시오. 실행 파일.

심하게 손상된 기본 기능을 해결하기 위해 _experimental_ 기능을 제안하는 것은 완전히 부적절합니다.

@ SteveL-MSFT

이 문제에 대한 해결책으로 --% 사용을 고려하더라도 근본적으로 잘못된 방법입니다.

"..." 인용 및 %...% 스타일 환경 변수 참조 만 아는 _Windows 전용 _ 기능입니다.

유닉스에서는 "파싱 중지"라는 개념이 기본적으로 적용되지 않습니다. _ 하위 프로세스에 전달할 명령 줄이 없습니다 _. 인수 배열 만 있습니다.

따라서 _someone_은 명령 줄을 ProcessStartInfo 클래스에 암시 적으로 위임 된 인수 _before_ 호출로 구문 분석해야합니다. 이는 .Arguments 속성을 통해 암시 적으로 위임되며 Unix에서는 명령 줄 구문 분석에 _Windows_ 규칙을 사용합니다. -따라서 "..." 인용 (내장 된 " 을 "" 또는 \" 로 이스케이프 처리) 만 인식합니다.

--% 는 "불량"CLI를 호출하는 것이 합법적 인 유일한 목적인 Windows 전용 기능입니다.

헉헉

Windows 및 VC ++ 컴파일러는이 동작을 중단하지 않기로 결정했습니다.

VC ++ 컴파일러는 _ 무정부 상태에 질서를 가져 오기 위해

ProcessStartInfo.ArgumentList 하면 자동으로 제공 되는이 규칙을 정확히 준수합니다 .

_ 이것만으로도 대부분의 통화를 처리 할 수 ​​있습니다. 모든 호출을 처리하는 것은 불가능하며 실제로 PowerShell의 책임이 아닙니다 ._

앞서 언급 한 바와 같이 비정상적인 견적 형식이 필요한 "불량"CLI의 경우 --% 사용해야합니다 (또는 Native 모듈에서 ins / Invoke-NativeShell ).

_ 예의로 _ 우리는 잘 알려진 "불량"시나리오, 즉 배치 파일 및 특정 유명 Microsoft CLI 호출을 자동으로 보상 할 수 있습니다.

• 배치 파일 케이스는 일반적인 케이스이며 쉽게 설명하고 개념화 할 수 있습니다 (예 : 인용 할 필요가 없더라도 a&b as "a&b" )-사용할 필요가 없습니다. 의 --% 모든 경기 선행 지수와 그러한 하늘빛의 그들의 진입 점으로 사용하는 배치 파일 (이 매우 일반적이다), az.cmd

• 혼란 스러울 수있는 특정 CLI에 대한 하드 코딩 예외에 대한 대안은 PowerShell의 구문 분석 결과 인 인수에서 다음 _pattern_을 감지하는 것입니다 ( <word>=<value with spaces> -및 "<word>=<value with spaces>" 전달하는 대신). , 현재와 같이 <word>="<value with spaces>" ; 후자는 "불량"CLI를 만족하는 동시에 규칙을 준수하는 CLI에서도 허용됩니다. 예를 들어 echoArgs "foo=bar baz" 궁극적으로 echoArgs --% foo="bar baz" 와 동일한 첫 번째 인수를 봅니다.

@musm https://github.com/PowerShell/PowerShell/blob/master/test/tools/TestExe/TestExe.cs 에서 TestExe 의 소스 코드를 찾을 수 있습니다 .

GitHub

PowerShell / PowerShell

모든 시스템을위한 PowerShell! GitHub에서 계정을 만들어 PowerShell / PowerShell 개발에 기여하세요.

기본적으로 예외를 수용하는 것은 사람들이 PowerShell의 "유용성"을 되돌려 야하는 현재 상황과 유사한 상황으로 이어질 것이라고 생각합니다. 예외가있는 경우 적용되고 있음이 분명해야합니다.

아마도 다음과 같습니다.

# Arguments passed correctly, without regard for the program's ability to handle them
& $program a "" 'c "d e" f'
# Try to pass the arguments intelligently based on the program being called
&[] $program a "" 'c "d e" f'
# Escape the arguments for a batch file, eg) " -> ""
&[bat] $program a "" 'c "d e" f'

나는 깨지지 않은 구문을 찾기 위해 정말 고심하고 있습니다. 프로그램을 캐스팅하는 것으로 생각한다면 적어도 이런 종류의 말이 맞지만, 프로그램을 포함하는 실제 변수를 캐스팅하려면 괄호를 묶어야합니다.

즉, 사람들이 원하는 모든 잘못된 동작에 대해 예외를 추가 할 수 있도록 허용하는 것 외에도 --% 의 필요성을 제거해야합니다. 등록한 예외 클래스는 프로그램에 적용 가능한지 (지능적 호출을 위해) 결정하는 방법과 명령 추상 구문 트리를 던지고 인수 배열 / 문자열을 반환하는 이스케이프 메서드를 갖게됩니다.

• "<word>=<value with spaces>" 전달하는 대신 <word>="<value with spaces>"

명령 줄을 구성하는 데 사용되는 인용 부호는 PowerShell에서 호출이 인용되는 방식을 따라야합니다. 따라서:

1. 텍스트에 큰 따옴표를 포함하지 않는 호출은 전체 값을 큰 따옴표로 묶어야합니다.
2. 큰 따옴표가 포함 된 호출은 _if possible_ 스크립트에 쓰여진대로 유지해야합니다.

특히:
| 스크립트 인수 | 명령 줄 |
| ----------------- | ---------------- |
| p=l of v | "p = l of v"|
| p=l` of` v | "p = l of v"|
| p="l of v" | p = "l of v"|
| p="l of v"'a s m' | p = "l of v"a "sm"|
| p="l of v"' s m' | p = "l of vsm"|

마지막 행은 원래 큰 따옴표를 유지할 수없는 예를 보여줍니다.

나는 여기서 많은 결함을 잡을 것이라는 것을 알고 있으며, 토론의 깊이에 대해 정말로 감사하지만 ..._ ducks _... 실제 시나리오에서 실제로 중요한이 사례를 가진 사람이 있습니까? ?

Powershell에서 ripgrep 을 사용할 때 많은 WFT 순간을

rg '"quoted"'

그리고 git bash에서는 그렇지 않았습니다.

슬프게도이 긴 github 문제를 발견하고 Powershel에 " 를 전달하는 것이 완전히 망가 졌다는 것을 알았 기 때문에 이제이 WTF 순간을 덜 얻습니다. 최근의 "git.exe"예제도 훌륭합니다.

솔직히 말해서, 이제는 문자열에서 매개 변수로 " 를 전달할 수 있다는 것을 알고있을 때 Powershell을 사용하여 네이티브 명령을 호출 할 수 없습니다. 잘못된 결과 나 오류가 발생할 수 있다는 것을 알고 있습니다.

정말, @ mklement0 은 그것을

이전에 여러 번 언급했듯이 쉘 의
큰 따옴표와 빈 문자열 인수가 포함 된 인수가 올바르게 전달되지 않았기 때문에 PowerShell은 현재이 명령을 이행하지 못합니다.
앞서 언급했듯이, 가능한 외부 CLI가 부족하여이 문제가 거의 드러나지 않는 Windows 전용 시대에는 문제가 적었을 수 있지만 요즘은 사라지고 PowerShell이 ​​신뢰할 수있는 크로스 플랫폼으로 자리 매김하려는 경우 이 문제를 해결해야합니다 .

그리고 브레이킹 체인지에 대해.
최근에 동료가 내 스크립트가 그의 컴퓨터에서 작동하지 않는다고 저에게 썼습니다. 저는 Powershel Core에서만 실행하고 있었고 그는 Windows Powershell에서 실행하고있었습니다. Windows Powershell에서는 "BOM"이 있고 Powershel Core에서는 BOM이없는 Out-File -Encoding utf8 인코딩 파일이 나옵니다. 이것은 어떻게 든 공개되지 않은 예이지만 Powershel에 이미 미묘한 변경 사항 이 있음을 보여 주며 유명한 언어에서 기이함과 직관적 인 동작을 제거하고 있기 때문에 좋습니다. Windows 외부에서 제공되는 크로스 플랫폼 Powershell이 ​​있고 Windows Powershell이 ​​"유지 관리"모드에 있으며 다음과 같은 경우 영원히 사용할 수 있음을 알고 있으므로 Powershel 팀이 변경 사항을 깨는 데 좀 더 관대하다면 좋을 것입니다. 최신 버전의 Powershell에서 중단 된 오래된 스크립트를 실행하기를 원합니다.

RE : 변경 사항의 마지막 지점은 전적으로 동의합니다. 다양한 이유로 인해 _many_ 개의 주요 변경 사항이 허용되었습니다. 그러나 점점 더 자주 일부 주요 변경 사항이 선호의 이유로 눈살을 찌푸리고 실제 가치에 대한 적절한 고려가 주어지지 않는 경우가 점점 더 많아지고 있습니다.

이와 같은 몇 가지 변경 사항은 항상 발생하는 작업을 수행하기 위해 PowerShell 외부에 접근해야하는 모든 사람을 위해 전반적인 셸 환경을 _ 대량 _ 개선합니다. 현재의 동작이 유지 될 수없고 가장 단순한 용도를 제외하고는 이미 대부분 손상되었다는 것이 몇 번이고 합의되었습니다. 그럼에도 불구하고 우리는 이미 승인 된 주요 변경 사항 중 일부가 비슷하게 큰 영향을 미치는 수십 개의 주요 변경 사항이 있음에도 불구하고 여전히 주요 변경 사항에 대한 이러한 고뇌에 직면하고 있습니다.

예제를 요청하는 사람들을 위해 잠시 시간을내어 Stack Overflow를 방문하십시오. @ mklement0 에는 최신 버전의 주요 변경 사항을 설명하기 위해 커뮤니티 도움이 필요한 예가 많이 있습니다. _ 항상 _ 발생합니다. 우리는 도움이되는 주요 변경 사항을 만들지 않을 변명의 여지 가 없습니다.

MSFT 팀이 동일한 내용을 반복해서 반복 할 때마다 공개적으로 말할 수있는 것보다 더 많이 알고 있다는 것을 확신 할 수 있습니다. 우리는 그들의 내적 규율을 존중하고 압력을 가해서는 안됩니다. _ 어쩌면 타협점을 찾을 수있을 것 같습니다. 오늘 시간이 지연된 마이그레이션의 대체 경로를 설명 할 시간이 있기를 바랍니다.

나는 그것을 알고 있으며 그것이 내가 그것에 대해 거의 질문하지 않는 이유입니다.

그러나 이것은 오픈 소스 프로젝트입니다. 그러한 결정에 대한 가시성이 없다면, 사람들은 필연적으로 좌절하게 될 것입니다. 그 동전의 양쪽에 던지는 책임은 없습니다. 그것이 바로 여기 상황의 현실입니다, IMO. 그렇습니다. 마이그레이션 경로가 있으면 그 고통이 다소 완화 될 수 있지만 가능한 한 많은 사람들이 작업을 수행 할 수 있도록 작동해야하는 방식에 대한 명확한 정책이 필요합니다. 하지만 정보가 부족하면 타협에 도달하기가 어렵습니다.

나는 당신이 당신의 소매에 무엇을 가지고 있는지보기를 고대합니다. 😉

@ mklement0 당신이 절대적으로 옳습니다. 그래서 지금은 당신의 메타 포인트에만 응답 할 수 있습니다. 안타깝게도 이와 같은 질문에 답하는 데 필요한 깊이 수준에 도달 할 수없는 경우 더 안전한 접근 방식은 시간이 더있을 때까지 중단 변경을 연기하거나 거부하는 것입니다.

그러나 주요 변경 사항에 대한 또 다른 메타 포인트를 만들고 싶습니다. 우리의 원격 분석 은 대부분의 PowerShell 7 사용자가 자신의 버전을 관리하지 않는다는 것을 의미합니다. 그들은 편안한 관리 환경에서 자동화 된 스크립트를 실행하고 있습니다. 예를 들어 사용자를 6.2에서 7.0으로 업그레이드합니다 (6.2 사용자가 8/3부터 7.0 사용자가되는 2 일 증가를 참조하십시오. 여기에서 유일한 데이터 포인트는 아니지만 요점을 만드는 것은 지금 편리한 것입니다). 이러한 사용자에게는 완벽하게 작동하는 스크립트를 작동하지 않는 스크립트로 바꾸는 주요 변경 사항이 허용되지 않습니다.

나는 또한 커뮤니티에 브레이킹 체인지의 영향에 대해 어떻게 생각하는지에 대한 블로그를 빚지고 있습니다. 즉, 브레이크의 식별 및 수정의 용이성에 비해 브레이크의 기존 사용률과 심각도를 상쇄하는 것입니다. 이것은 기존 스크립트에서 매우 널리 퍼져서 식별하고 수정하는 데 혼란스럽고 깨지는 동작은 전체 성공에서 전체 실패까지이므로 여기에서 무엇이든 할 수있는 극도의 과묵합니다.

나는 우리가 7.1에서 여기서 아무것도하지 않을 것이라고 말하는 것이 공평하다고 생각한다. 그러나 나는 이것을 7.2에 대한 조사 우선 순위로 만드는 것에 대해 확실히 열려있다 (즉 우리는 이것을 논의하는데 우리위원회 시간보다 더 많은 시간을 할애한다).

위원회가 협의하는 주제별 소위원회를 임명하는 것은 어떨까요?

우리는 이것을 위해 노력하고 있습니다. 이전에 말씀 드린 적이 있지만 우리는 매우 가깝습니다 (예를 들어, 블로그를 만들고 있으며 곧 새로운 레이블이 표시되는 것을 보게 될 것입니다).

모든 분들의 인내심에 감사 드리며, 토론에 엄청난 양의 생각과 배려를 쏟아 부을 때 2 주마다위원회에서 간소 한 답변을받는 것이 성가신 일임을 알고 있습니다. 그것은 우리가 사물에 대해 깊이 생각하지 않는다는 것을 의미하는 것처럼 보이지만, 우리가 여기에서하는 것만 큼 세부적으로 토론의 깊이를 표현하지 않고 있다고 생각합니다. 내 백 로그에는위원회 내에서 결정을 내리는 것에 대해 어떻게 생각하는지에 대한 브레이킹 체인지와 같은 전체 블로그 주제가 있지만, 앉아서이를 펌핑 할 기회를 얻지 못했습니다. 그러나 저는 여기서 사람들이 그것에 대해 많은 가치를 찾을 수 있다는 것을 알 수 있습니다.

이 토론에서 너무 멀리 떨어져 있지 않기를 바랍니다. 이 문제가 프로젝트 관리에 대한 메타 문제가되는 것을 원하지는 않지만 여기에서 볼 수있는 이해할 수있는 좌절감을 일부 해결하고 싶었습니다. 이 문제에 대해 더 자세히 이야기하고 싶은 분은 다음 주 커뮤니티 콜에 참여해 주시기를 간청합니다 ( 여기에 질문과 생각을 추가하시면 콜에서 해결하겠습니다).

메타 포인트에 대한 간단한 메모 : @joeyaiello라는 사려 깊은 답변에 감사드립니다.

브레이킹 체인지의 심각도에 관해서는 다음과 같은 내용이 상충되는 것 같습니다.

실제 시나리오에서 실제로 중요한이 사례가있는 사람이 있습니까?

대

이것은 기존 스크립트에서 매우 널리 퍼져서 식별하고 수정하는 데 혼란 스럽습니다.

이미 널리 퍼져있는 경우 필요한 해결 방법의 어색함과 모호함이 최종적으로이 문제를 해결해야하는 더 많은 이유입니다. 특히 케이스 수가 증가 할 것으로 예상해야합니다.

기존의 모든 해결 방법이 중단된다는 것을 알고 있습니다.

이를 피하는 것이 가장 중요하다면 이전에 제안 된이 접근 방식을 사용하는 것이

문제를 해결하는 Native 모듈에서 ie 함수와 같은 _new 연산자 또는 함수 _를 제공하고 외부 실행 파일을 호출하는 유일한 신뢰할 수있는 방법으로 널리 공개합니다.

ie 와 같은 _function_을 사용하면 _ 언어 _에 새로운 구문 요소 (연산자)에 대한 부담을주지 않고 _minimal fuss_, _ 중단 점으로 _ 올바른 동작을 선택할 수 있습니다. 너무 깨져서 고칠 수없는 레거시 버그를 해결하려면 :

• 임시 격차는 올바른 동작에 대한 _ 공식적으로 승인 된 _ 액세스를 제공합니다 (_experimental_ 기능에 의존하지 않음).
• 임시 방편이 필요한 한 널리 공개되고 적절하게 문서화되어야합니다.

기본 동작이 수정되는 경우 :

• 함수는 그것을 사용하는 코드를 깨지 않도록 그냥 연기하도록 수정할 수 있습니다.
• 더 이상 함수없이 새로운 코드를 작성할 수 있습니다.

ie와 같은 기능을 사용하면 사람들이 최소한의 소란으로 올바른 행동을 선택할 수 있습니다.

# 13428을 통해 채택을 단순화 할 수 있습니다. 우리는 이것을 Engine에서 @ mklement0 의 조사에 투명하게 주입 할 수 있습니다.

뿡 빵뀨

기본적으로 예외를 수용하는 것은 사람들이 PowerShell의 "유용성"을 되돌려 야하는 현재 상황과 유사한 상황으로 이어질 것이라고 생각합니다. 예외가있는 경우 적용되고 있음이 분명해야합니다.

내가 제안하는 편의 기능은 대부분의 호출을 "그냥 작동"하도록 만듭니다. Windows 명령 줄 무정부 상태에서 사용자를 보호하기 위해 최선을 다해야하는 유용한 추상화입니다.

정당한 가정은이 차폐가 _legacy_ 실행 파일에 대한 일회성 노력이며 새로 생성 된 것은 Microsoft C / C ++ 규칙을 준수한다는 것입니다.

그러나 _all_ 케이스에서 그렇게하는 것은 불가능합니다. 자동으로 수용 될 수없는 경우 --% 있습니다.

개인적으로, 주어진 유틸리티 foo 가 foo.bat 또는 foo.cmd 로 구현되는지 또는 foo="bar none" 필요한지에 대해 생각하고 싶지 않습니다 "foo=bar none" 허용하지 않고 규칙을 준수하는 실행 파일과 동일합니다.

그리고 &[bat] 와 같은 다양한 예외에 대해 별도의 구문 형식을 원하지는 않습니다.
대신, --% 은 (는) 대상 프로그램의 구체적이고 비 관습적인 요구 사항이 무엇이든간에 명령 줄을 전달하려는대로 정확하게 공식화하기위한 (Windows 전용) 포괄적 인 도구입니다.

구체적으로 제안 된 편의 사항은 다음과 같습니다.

노트 :

• 언급했듯이 _Windows에서만 _ 필요합니다. Unix에서 ProcessStartInfo.ArgumentList 로 위임하면 모든 문제를 해결할 수 있습니다.

• 적어도 높은 수준에서 이러한 편의는 개념화하고 문서화하기 쉽습니다.

• _after_ PowerShell의 일반적인 구문 분석이 (Windows 전용) 프로세스로의 변환 명령 줄 단계에서 적용됩니다. 즉, PowerShell의 자체 매개 변수 구문 분석은 관련되지 않으며 _shouldn't_ be , @ yecril71pl입니다.

• 이러한 조정으로 다루지 않는 진정으로 이국적인 경우는 사용자가 직접 처리해야합니다.
  --% -또는 Native 모듈이 설치된 상태에서 ins / Invoke-NativeShell 를 사용하면 PowerShell 변수 및 식 값을 호출에 포함하기가 더 쉽습니다.

  • Native 모듈의 dbea ( Debug-ExecutableArguments ) 명령은 궁극적으로 사용되는 프로세스 명령 줄을 진단하고 이해하는 데 도움이 될 수 있습니다. 아래 예제 섹션을 참조하십시오.

숙박 시설 목록 :

• 배치 파일의 경우 (이 사례를 자동으로 수용하는 것의 중요성은 Azure의 경우 az.cmd 와 같이 배치 파일을 진입 점으로 _ 사용하는 고 프로파일 CLI의 보급입니다).

  • 포함 된 큰 따옴표 (있는 경우)는 모든 인수에서 "" ( \" 아닌)로 이스케이프됩니다.
  • 공백이 없지만 중 따옴표 또는 포함 된 인수 cmd.exe 같은 메타 문자를 & 따옴표 (PowerShell을 반면 기본적으로 만 따옴표에 공백이 인수를 둘러싼)로 묶여; 예를 들어 PowerShell에서 a&b 로 표시되는 약어 인수는 배치 파일에 전달 된 명령 줄에서 "a&b" 로 배치됩니다.

• msiexec.exe / msdeploy.exe 및 cmdkey.exe 와 같은 주요 CLI의 경우 (하드 코딩 예외 없음) :

  • 다음 형식의 인수가 하나 이상 포함 된 호출은 아래 설명 된 동작을 트리거합니다. <word> 는 문자, 숫자 및 밑줄로 구성 될 수 있습니다.

    • <word>=<value with spaces>
    • /<word>:<value with spaces>
    • -<word>:<value with spaces>

  • 그러한 인수가있는 경우 :

    • 포함 된 큰 따옴표 (있는 경우)는 모든 인수에서 "" ( \" 아닌)로 이스케이프됩니다. -https://github.com/PowerShell/PowerShell/pull/13482#issuecomment -677813167에서이 작업을 _하지 말아야하는 이유를 확인 하십시오 . 이것은 <value with spaces> 에 _embedded_ " 문자가있는 드문 경우에 --% 사용해야 함을 의미합니다. 예 :
      msiexec ... --% PROP="Nat ""King"" Cole"
    • <value with spaces> 부분 만 큰 따옴표로 묶여 있으며 인수 전체가 아닙니다 (후자는 PowerShell-정당하게-기본적으로 수행하는 작업입니다). 예로서 PowerShell을 볼 축 어적 인수 foo=bar none 로 배치 foo="bar none" (보다 오히려 같은 프로세스의 커맨드 라인에 "foo=bar none" ).
  • 노트 :
    
    
    
    • 대상 실행 파일이 _not_ 일어나는 경우로 msiexec 규칙-준수 경기 선행 지수가 현명하게 생각하기 때문에 스타일 CLI, 전혀 해를 끼치이 수행되지 않습니다 <word>="<value with spaces>" 및 "<word>=<value with spaces>" _equivalent_, 모두 나타내는 그대로 <word>=<value with spaces>
    
    
    • 마찬가지로, 대부분의 실행 파일은 "" 와 \" 를 서로 바꿔서 사용할 수 있습니다. 단, PowerShell의 자체 CLI, Ruby 및 Perl (_not_performance)을 제외하고는 포함 된 " 문자를 이스케이프합니다. 적어도 PowerShell CLI가 호출되는 경우 편의는 가치가 있지만 하드 코딩 Ruby 및 Perl도 의미가 있다고 생각합니다.) https://github.com/PowerShell/PowerShell/pull/13482#issuecomment -677813167은 CommandLineToArgvW WinAPI 함수를 사용하는 모든 애플리케이션이 "" -escaping을 지원하지 _ 않는다는 것을 보여줍니다.
    
    

Windows에서 모든 다른 경우도 함께 처리 할 수 ProcessStartInfo.ArgumentList 암시 적으로 적용되는, 마이크로 소프트 C / C ++ 규칙 (특히 의미 \" 위해 " -escaping).

ie (현재 버전 함수 1.0.7 )의 Native 모듈 구현 PowerShell을 버전 3 및 최대 대 (깨진 인수 파싱 고정 이외에)이 편의 ( Install-Module Native ).

대부분의 외부 실행 가능 호출에 대해 "그냥 작동한다"는 주장을 테스트하기 위해 여기있는 모든 사람과 함께

현재 피할 수없는 제한 :

• 참고 : 이러한 기술적 제한은 ie 가 _function_으로 구현되는 데서 발생합니다 (엔진 자체의 적절한 수정은 이러한 문제가 _ 아닙니다 _).

  • $LASTEXITCODE 가 프로세스의 종료 코드로 올바르게 설정되어 있지만 $? 는 항상 $true 끝납니다. 현재 사용자 코드는이 기능을 추가하더라도 $? 명시 적으로 설정할 수 없습니다. 녹색으로 켜져 있습니다 -https://github.com/PowerShell/PowerShell/issues/10917#issuecomment -550550490을 참조 && 및 || , 파이프 라인 체인 연산자 인 && 와 함께 ie 의미있게 사용할 수 없음을 의미합니다.
    그러나 0이 아닌 종료 코드를 감지하는 스크립트를 _aborting_하려는 경우 iee 래퍼 함수를 ​​사용할 수 있습니다.

  • -- 인수는 항상 PowerShell 매개 변수 바인더에 의해 "먹 힙니다". 단순히 전달하는 순서를 통과 _twice_ -- (대상 실행까지 foo -- -- 대신 foo -- ).

  • , 의 인용되지 않은 토큰은 배열로 해석되고 여러 인수로 전달되지 않도록 인용해야합니다. 예를 들어이 통과 'a,b' 보다는 a,b ; 유사하게 -foo:bar (이름이 지정된 PowerShell 인수처럼 보이는 것)를 '-foo:bar' (필요한 것은 아니지만 버그 때문입니다. # 6360); 유사하게 '-foo.bar must be passed as '-foo.bar'` (외부 실행 파일에 대한 직접 호출에도 영향을 미치는 또 다른 버그 : # 6291)

• 이 기능이 PowerShell _Core_에서 강력하게 작동 할 것으로 기대합니다. 시간이 지남에 따라 _Windows PowerShell_의 변경 사항으로 인해 다음 두 가지만 알고 있지만 제대로 처리되지 않는 경우가 발생할 수 있습니다.

  • msiexec 스타일 CLI에 대한 부분 인용 조정은 버전 3 및 4에 적용될 수 없습니다. 이러한 버전은 전체 인수를 추가 큰 따옴표 세트로 래핑하기 때문입니다. 그러나 v5.1에서는 작동합니다.

  • "" -escaping은 기본적으로 문제를 해결하기 위해 사용되지만 \" 가 필요한 경우 (PowerShell CLI, Perl, Ruby) 3" of snow 와 같은 토큰은 다음과 같습니다. 모든 Windows PowerShell 버전은 이러한 인수를 큰 따옴표로 묶지 않기 때문에 실수로 _3_ 인수로 전달되었습니다. 이것은 공백 문자가 앞에 있지 않은 초기 " 문자가 아닌 인수에 대해 발생하는 것 같습니다.

Windows 10에서 PowerShell Core 7.1.0-preview.5의 출력을 사용한 예 :

참고 : dbea ( Debug-ExecutableArguments ) 함수는 외부 실행 파일 / 배치 파일에서 인수를받는 방법을 설명하는 데 사용됩니다.

현재 잘못된 인수 전달 :

• 규칙을 준수하는 애플리케이션 호출 (기본적으로 dbea 사용되는 .NET 콘솔 애플리케이션) :

# Note the missing 2nd argument and the effective loss of embedded double quotes,
# due to the embedded " chars. not having been escaped.
PS> dbea -- 'a&b' '' '{ "foo": "bar" }'

2 argument(s) received (enclosed in <...> for delineation):

  <a&b>
  <{ foo: bar }>

Command line (helper executable omitted):

  a&b  "{ "foo": "bar" }"

• 배치 파일 호출 :

-UseBatchFile 를 사용하여 dbea 대신 인수를 도우미 _batch file_에 전달합니다.

# Note that only *part of the first argument* is passed and that the `&` is interpreted as cmd.exe's
# statement separator, causing `b` to be run as a command (which fails).
PS> dbea -UseBatchFile -- 'a&b' '' '{ "foo": "bar" }'

1 argument(s) received (enclosed in <...> for delineation):

  <a>

'b' is not recognized as an internal or external command,
operable program or batch file.

• msiexec -style CLI 호출, cmdkey.exe :

# The call fails, because `cmdkey.exe` requires the password argument to 
# to be quoted exactly as `/password:"bar none"` (double-quoting of the option value only), 
# whereas PowerShell - justifiably - passes `"/password:bar none"` (double-quoting of the whole argument).
PS> cmdkey.exe /generic:foo /user:foo /password:'bar none'

The command line parameters are incorrect.

ie 문제 해결 :

dbea 호출에서 -ie 를 사용하면 호출에 ie 가 사용됩니다.

• 규칙을 준수하는 애플리케이션 호출 (기본적으로 dbea 사용되는 .NET 콘솔 애플리케이션) :

# OK
# Note that the empty 2nd argument is correctly passed, and that \" is used for embedded "-escaping.
PS> dbea -ie -- 'a&b' '' '{ "foo": "bar" }'

3 argument(s) received (enclosed in <...> for delineation):

  <a&b>
  <>
  <{ "foo": "bar" }>

Command line (helper executable omitted):

  a&b "" "{ \"foo\": \"bar\" }"

• 배치 파일 호출 :

# OK
# - `a&b` was enclosed in "...", due to the presence of metacharacter `&`
# - "" is used for escaping of embedded " chars.
# Note that `echo %1`, for instance, prints the argument exactly as passed on the command line, including quoting.
# `echo %~1` strips the surrounding double quotes, but embedded escaped ones still print as "".
# However, if you pass these arguments (`%*`) through to convention-compliant CLIs, they are parsed correctly.
PS> dbea -ie -UseBatchFile -- 'a&b' '' '{ "foo": "bar" }'

3 argument(s) received (enclosed in <...> for delineation):

  <"a&b">
  <"">
  <"{ ""foo"": ""bar"" }">

• msiexec -style CLI 호출, cmdkey.exe :

# The call now succeeds, because `ie` ensure the value-only double-quoting that cmdkey.exe requires.
# (Use `cmdkey /del:foo` to remove the credentials again.)
PS> ie cmdkey.exe /generic:foo /user:foo /password:'bar none'

CMDKEY: Credential added successfully.

dbea 를 통해 실제 명령 줄에 값 전용 큰 따옴표가 적용되었음을 표시하려면 다음을 수행하십시오.

PS> dbea -ie -- cmdkey.exe /generic:foo /user:foo /password:'bar none'

  <cmdkey.exe>
  </generic:foo>
  </user:foo>
  </password:bar none>

Command line (helper executable omitted):

  cmdkey.exe /generic:foo /user:foo /password:"bar none"

다음 코드는 데이터 손실을 유발합니다.

{ PARAM($A) $A } | OUT-FILE A.PS1
PWSH A.PS1 -A:(1,2)

1

@JamesWTruher 에 제안 된 수정 사항이

제안 된 수정 사항에 대한 풀 요청이 있습니까? PR에 대해 언급 할 수 있으면 좋을 것 같습니다. 이것을 고치는 것은 IMO가 결코 복잡한 부분이 아니었기 때문입니다. 복잡한 부분은 이전 버전과의 호환성을 처리하는 방법이었습니다. 그리고 제안 된 수정이 어떻게 처리하는지 볼 수 있다면 좋을 것입니다 ....

좋은 소식입니다. @ SteveL-MSFT-여기서 논의 된 _all_ 문제에 대한 수정 사항입니까? 결국 v7.1의 경우? 그리고 두 번째 @TSlivede 의 요청입니다.

@ yecril71pl , 이것은 좋은 발견입니다. 비록 이것이 실제로 PowerShell의 자체 구문 분석 (외부 실행 파일에 대한 _some_ 특수 케이스가 있음)과 관련이 있지만 기본 명령 줄이 구성되는 방법 _after_ 구문 분석 (이전에 논의 된 문제가 발생하는 곳)과는 관련이 없습니다. 에서).

Unix에서 문제를보다 간결하게 재현합니다.

PS> printf '<%s>\n' -a:(1,2,3)
<-a:1>
<2>
<3>

즉, _first_ 배열 요소 만 -a: 에 직접 연결되고 다른 요소는 별도의 인수로 전달되었습니다.

PowerShell 매개 변수와 비슷하지만 그렇지 않은 인수와 관련된 문제가 있습니다.

$args / @args : # 6360을 사용하는 _PowerShell_ 명령에 대한 호출에만 영향을주는 관련 문제가 있습니다.

• & { $args.Count; $args } -foo:bar 2, '-foo:', 'bar' 산출합니다.

PowerShell 명령과 외부 실행 파일 모두에 영향을주는 # 6291도 있습니다 ( . ).

• & { $args.Count; $args } -foo.bar 2, '-foo', '.bar' 산출합니다.

한 가지 주목할 점은 (...) 를 베어 워드의 일부로 사용하면 일반적으로 (...) 의 출력이 전체적으로 _separate_ 인수가되므로 첫 번째 요소 _is_가 printf 첨부된다는 사실입니다
& { $args.Count; $args.ForEach({ "$_" }) } foo('bar', 'baz') 2, 'foo', 'bar baz' & { $args.Count; $args.ForEach({ "$_" }) } foo('bar', 'baz') 산출하고 두 번째 인수는 배열 'bar', 'baz' 의 문자열 화입니다.

PowerShell이 ​​외부 실행 파일에 대해 -A:(1,2) 를 전달해야하는 경우 -A: 는 문자열이고 (1,2) 는 '1 2'로 마샬링되어야하는 배열임을 알아냅니다. PowerShell은 호출의 원래 구문을 유지하려고 시도하므로 모두 합치면 '-A : 1 2'가 표시되지만 올바른 결과는 '-A : "1 2"'가됩니다. 마샬링 코드에서 사소한 누락처럼 보입니다.

@ yecril71pl 의 특정 문제가 구문 분석과 관련이 있다고 말하지는 않겠습니다 (이 문제에서 논의되는 "배열을 명령

PowerShell이 ​​외부 실행 파일에 대해 -A : (1,2)를 전달해야하는 경우 -A :가 문자열이고 (1,2)가 배열임을 파악합니다.

거의 : -A: 는 명명 된 매개 변수이고 배열은 해당 매개 변수의 값입니다 (테스트하려면 - 앞에있는 @ 아닌 $ 사용하더라도 항상 (거의) 항상 스플래 팅된다는 것입니다. 배열이 (1,2) 와 같은 표현식에서 시작된 경우에도 마찬가지입니다.

예를 들어 테스트 printf '<%s>\n' -a:('a b',2) : 문자열 a b 에 공백이 포함되어 있으므로 올바르게 인용되지만 2 가 다음 배열 요소에 있고 배열이 표시되므로 2 는 첫 번째 인수의 일부가 아닙니다.

170 행에서 powershell은 현재 인수 값에 대한 열거자를 가져 오려고합니다.

IEnumerator list = LanguagePrimitives.GetEnumerator(obj);

list 가 null list 가 아닌 경우 powershell은 목록의 각 요소 (공백이 포함 된 경우 따옴표로 묶음)를 lpCommandLine에 추가합니다.

요소는 기본적으로 공백 ( 449 행 )으로 구분됩니다. 유일한 예외는 배열이 리터럴 인 경우입니다.
( printf '<%s>\n' -a:1,2 ).
그런 다음 powershell은 스크립트 줄에서 사용 된 lpCommandLine에서 동일한 구분 기호를 사용하려고합니다.

준비되면 PR을 기대합니다. 7.1로 만들면 가져 가고 그렇지 않으면 7.2가됩니다. 역 호환성은 그가 다루고있는 것입니다. 아마도 도움이되는 것은 Pester 테스트를 작성하는 데 도움이 될 것입니다 (build.psm1에서 publish-pstesttools 를 사용하여 빌드 할 수있는 testexe -echoargs 사용).

준비되면 PR을 기대합니다

이것이 바로 제가 피하고 싶었던 것입니다. 준비되지 않은 코드를 보여주세요 (PR을 진행중인 작업으로 표시).

또는 적어도 그가하고 싶은 일에 대해 언급하십시오.

그가 이전 버전과의 호환성을 어떻게 처리하고 싶은지 논의 할 수 있다면 좋을 것입니다.

@TSlivede , PowerShell _CLI_가 호출 되었기 때문에-외부 실행 파일- -A:(1,2) 이 파싱 됨 _before_이 토큰이 결국 _named_ -A 매개 변수에 바인드 됨-이러한 매개 변수 _eventually_가 작동하게 됨 문제에 부수적입니다.

@ yecril71pl :

-A: 이 문자열임을 알아냅니다.

아니요, PowerShell 매개 변수와 _ 같이 보이기 때문에 구문 분석 중에 특수한 경우입니다.

이 특수한 경우는 $args 를 사용하는 PowerShell 명령에 대한 호출에서도 발생하지만 (바인딩 된 실제 선언 된 매개 변수가있는 것과는 반대) 외부 실행 파일에 대해 _ 다르게 _ 발생합니다 (일반적으로 별도의 인수는 연결된 상태로 유지됩니다. 그러나 컬렉션의 경우 _first_ 요소 만).

미리 -- 를 전달하면 실제로이 특수 케이스를 옵트 아웃 할 수 있지만, 물론 _PowerShell_ 명령에 대한 호출에 대해서만 제거되는 -- 도 전달됩니다.

PS> printf '<%s>\n' -- -a:(1,2,3)
<-->   # !! not removed
<-a:>
<1>    # array elements are *all* now passed as indiv. arguments, because (...) output is separate (splatted) argument
<2>
<3>

인수 _doesn't_가 PowerShell 매개 변수처럼 보이면, 일반적인 동작 ( (...) 출력이 별도의 인수가 됨)은 외부 실행 파일 (_array_의 일반적인 동작이 splatted, 즉 외부 실행 가능한 경우의 개별 인수).

# Note: No "-" before "a:" -> output from `(...)` becomes separate argument(s)
PS> printf '<%s>\n' a:(1,2,3)
<a:>
<1>
<2>
<3>

이 동작을 _consistently_ 적용하면 의미가 있습니다. (...) 표현식이 베어 워드의 일부로 _always_ 별도의 인수가되어야합니다. # 13488을 참조하십시오.

하나의 인자 통과하기 위해서는 '-A:1 2 3' 배열 _stringified_으로,이 경우 당신이 필요로하는 (N 암시 적) _expandable string_를 사용 $(...) 보다는 (...) _AND_ - 놀라 울 -현재 "..." :

PS> printf '<%s>\n' "-a:$(1,2,3)"  # quotes shouldn't be needed; `-a:"$(1,2,3)"` would work too.
<a:1 2 3> # SINGLE argument with stringified array.

이 경우에는 "..." 필요하지 않습니다.-매개 변수와 유사한 토큰과 관련된 이상 (일반적으로 _both_ PowerShell 및 외부 실행 가능 호출에 적용됨-# 13489 참조)과 관련된 예외 때문에 다시 필요합니다. 그렇지 않은 경우 인용 할 필요가 없습니다.

# Anomaly due to looking like a parameter: $(...) output becomes separate argument
PS> Write-Output -- -a:$(1,2,3)
-a:
1
2
3

# Otherwise (note the absence of "-"): no quoting needed; treated implicitly like 
# "a:$(1,2,3)"
PS> Write-Output -- a:$(1,2,3)
a:1 2 3  # SINGLE argument with stringified array.

인수 모드에서 복합 토큰의 세계는 여러 가지 불일치가있는 복잡한 것입니다. # 6467을 참조하세요.

@ SteveL-MSFT

현재 형식에서 testexe -echoArgs 는 원시 명령 줄 자체가 아니라 원시 명령 줄 (Windows)에서 .NET Core 실행 파일이 구문 분석 한 개별 인수 만 인쇄합니다.

따라서 배치 파일 및 msiexec 스타일 CLI에 대한 선택적 인용을 사용하여 조정을 테스트 할 수 없습니다. 이러한 조정이 구현 될 것이라고 가정합니다. 예를 들어, PROP='foo bar' 가 PROP="foo bar" 로 전달되었는지 확인할 수 없으며 값 부분을 큰 따옴표로 묶은 것입니다.

그러나, 원시 명령 줄을 인쇄하기 위해, testexe .NET 코어가 항상 사용하는 가상의 명령 line_을 _recreates 때문에, 닷넷 _Core_ 실행 파일이 아니어야합니다 \" 임베디드에 대한 -escaping을 " chars., "" 가 사용 된 경우에도 일반적으로 어떤 인수가 큰 따옴표로 묶 였는지, 그렇지 않은지 정확하게 반영하지 않습니다. 배경은 https://github.com/ 참조 dotnet / runtime / issues / 11305 # issuecomment -674554010.

.NET _Framework_- 컴파일 된 실행 파일 만 Environment.CommandLine 에 실제 명령 줄을 표시하므로 testexe 는 그런 방식으로 컴파일해야합니다 (선택적으로 원시 명령 줄을 인쇄하도록 변경).

배치 파일에 대한 조정을 테스트하려면 별도의 테스트 _batch_ 파일이 필요합니다. 'a&b' 가 "a&b" 되고 'a"b' 가 "a""b" 로 전달되었는지 확인합니다. 예.

@ mklement0 .NET Framework 용 컴파일은 가능하지 않으며 올바른 동작을 얻으려면 .NET Framework에서 실행해야 할 것입니다. PS 리포지토리에서 모든 네이티브 코드 컴파일을 의도적으로 제거했으며 다시 추가하고 싶지는 않습니다 ... 한 가지 옵션은 미리 빌드 된 네이티브 testexe (Windows, macOS, 그리고 다양한 Linux 배포판 (예 : Alpine 별도). testexe를 작성하는 것은 쉽습니다. 게시하는 모든 작업을 수행하는 데 시간이 걸립니다.

또는 Linux / macOS 용 간단한 bash 스크립트를 사용하여 args를 내보낼 수 있습니까?

#!/bin/bash
for i; do
   echo $i
done

그리고 Windows에서는 배치 파일과 비슷한 것입니다.

.js 스크립트와 함께 노드를 사용하는 것은 어떻습니까?

console.log(process.execArgv.join('\n') 또는 당신을 처리하는 어떤 문자열
출력물을 멋지게 만들고 싶습니까?

@cspotcode , 원시 명령 줄을 가져 오려면 WinAPI 호출이 필요합니다.

@ SteveL-MSFT :

Windows 에서는 CLI를 통해 컴파일을 _Windows PowerShell_에 위임 할 수 있습니다. 이 작업은 dbea . 다음은 원시 명령 줄 (전용)을 반영하는 .NET _Framework_ 실행 파일을 생성하는 간단한 예입니다. ./rawcmdline.exe :

powershell.exe -noprofile -args ./rawcmdline.exe -c {

  param([string] $exePath)

  Add-Type -ErrorAction Stop -OutputType ConsoleApplication -OutputAssembly $exePath -TypeDefinition @'
using System;
static class ConsoleApp {
  static void Main(string[] args) {
    Console.WriteLine(Environment.CommandLine);
  }
}
'@

}

샘플 호출 :

PS> ./rawcmdline.exe --% "a&b" PROP="foo bar"
"C:\Users\jdoe\rawcmdline.exe"  "a&b" PROP="foo bar"

인수를 반영하는 _batch file_의 경우 dbea 도 요청시 하나를 만듭니다 .

Unix 에서는 의견에 표시된 것처럼 간단한 쉘 스크립트로 충분 하며 /bin/sh 에 _argument_로 전달하는 임시 스크립트를 사용할 수도 있습니다 .

@ PowerShell / powershell-committee는 오늘 이것을 논의했습니다. 우리는 @JamesWTruher 에게 자신의 PR을 업데이트하여 인수 배열을 다시 문자열로 재구성하는 네이티브 명령 프로세서의 단계를 건너 뛰고 통과하는 실험 기능의 일부로 포함하도록 요청합니다. ProcessStartInfo의 새 배열 인수에 추가합니다 (매개 변수 이름과 값이 적절하게 일치하는지 확인하는 약간의 코드가 있습니다). 또한 제안 된 변경 사항으로 여전히 실패하고 나중에 추가 할 수있는 특수한 경우 알려진 명령에 대한 허용 목록이 필요할 수 있음을 받아들입니다.

눈치 채지 못한 분들을 위해 : PR이 (WIP로) 게시되었으며 이미 논의 중입니다 : https://github.com/PowerShell/PowerShell/pull/13482

PS, @ SteveL-MSFT, Windows에서 원시 명령 줄 가져 오기와 관련하여 : 물론 컴파일을 Windows PowerShell / .NET _Framework_에 위임하는 대안은 기존 .NET _Core_ 콘솔 응용 프로그램을 강화하여 (플랫폼 조건부) 아래에 설명 된대로 GetCommandLine() WinAPI 함수에 대한 P / Invoke 호출.

using System;
using System.Runtime.InteropServices;

namespace demo
{
  static class ConsoleApp
  {
    [DllImport("kernel32.dll")]
    private static extern System.IntPtr GetCommandLineW();

    static void Main(string[] args)
    {
      Console.WriteLine("\n{0} argument(s) received (enclosed in <...> for delineation):\n", args.Length);
      for (int i = 0; i < args.Length; ++i)
      {
        Console.WriteLine("  <{0}>", args[i]);
      }

      // Windows only: print the raw command line.
      if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
      {
        Console.WriteLine("\nCommand line:\n\n  {0}\n", Marshal.PtrToStringUni(GetCommandLineW()));
      }

    }

  }

}

@ SteveL-MSFT

역 호환성은 그가 다루고있는 것입니다.

ProcessStartInfo.ArgumentList (Unix에서있는 그대로 사용하고 .NET Core 자체에 의해 Windows에서 MS C / C ++-컨벤션 준수 명령 줄로 변환되는 _verbatim_ 인수의 _collection_) )를 사용해야하지만 명시 적으로 설명하겠습니다.

• 이 문제를 적절하게 수정하면 _ 이전 호환성에 대한 양보가 배제됩니다 _.

• @JamesWTruher 의 PR은이 글을 쓰는 시점에서 올바른 방향으로 가고 있습니다. 유일한 문제는 빈 인수가 여전히 전달되지 않는다는 것 입니다.

  • 이 문제가 해결되면 _Unix_에서 수정이 완료되지만 _Windows_의 CLI에 대한 중요한 조정이 부족합니다 (아래 참조).

제안 된 변경으로 여전히 실패하고 나중에 추가 할 수있는 특수한 경우 알려진 명령에 대한 허용 목록이 필요할 수 있습니다.

나는 이것을 나중에까지 미루지 말 것을 촉구한다 .

_allowlist_ (특정 실행 파일에 대한 특수 사례) 대신, @TSlivede 와 좀 더 논의한 후 위의 규칙 에서 개선 된

_Windows에서만 필요 _하는 다음 조정 :

• Windows에서 대부분의 호출이 제대로 작동합니다.

• 제안 된 about_Native_Calls 도움말 항목 에서 쉽게 개념화하고 문서화 할 수 있습니다.

• 구현이 간단합니다. 여기에 테스트와 함께 PowerShell로 작성된 개념 증명이 있습니다.

구체적으로 다음과 같습니다.

• Unix와 마찬가지로 ProcessStartInfo.ArgumentList 가 기본적으로 사용됩니다. 단, 다음 조건 중 _ 하나 또는 둘 다 _가 충족되는 경우 _이 경우 프로세스 명령 줄을 수동으로 구성해야합니다 _ (그리고 다음과 같이 ProcessStartInfo.Arguments 할당해야 함). 현재) :

  • 배치 파일 ( .cmd , .bat ) 또는 cmd.exe 직접 호출됩니다.
  • 이 경우 _embedded_ " 는 "" ( \" 아닌) 및 다음 cmd.exe 메타 문자를 포함하는 공백없는 인수로 이스케이프됩니다. 또한 큰 따옴표로 묶여 있습니다 (일반적으로 _ 공백이있는 인수 만 큰 따옴표로 표시됨) : " & | < > ^ , ; -이렇게하면 배치 파일에 대한 호출이 안정적으로 작동합니다. 이는 많은 유명 CLI가 배치 파일을 _entry로 사용하기 때문입니다. 포인트들_.

  • 독립적으로 (및 가능하면 추가로) 정규식과 일치하는 인수가 하나 이상있는 경우
    '^([/-]\w+[=:]|\w+=)(.*? .*)$' 이 (가) 존재합니다. 이러한 모든 인수는 _value 부분에만 _partial_ 큰 따옴표를 적용해야합니다 _ ( : 또는 = 뒤에 오는 내용)

    • 예 : msiexec.exe / msdeploy.exe 및 cmdkey.exe -PowerShell에서 다음과 같은 형식으로 표시되는 스타일 인수
      FOO=bar baz 및 /foo:bar baz / -foo:bar baz 는 프로세스 명령 줄에 다음과 같이 배치됩니다.
      foo="bar baz" 또는 /foo:"bar baz" / -foo:"bar baz" 이 스타일의 견적이 필요한 _any_ CLI를 만족스럽게 만듭니다.

  • 인수에있는 그대로 \ 문자는 MS C / C ++ 규칙에 따라 처리되어야합니다.

이러한 편의에 의해 보장되지 _ 않는 __ :

• msiexec.exe (그리고 아마도 msdeploye.exe 도)는 _only_ "" -_embedded_ " 문자의 이스케이프를 지원합니다 cmd /c 를 통해 호출하는 경우는 예외입니다.

  • 이것은 시작하기에 충분히 드 물어야합니다 (예 :
    msiexec.exe /i example.msi PROPERTY="Nat ""King"" Cole" ),하지만 misexec 호출은 일반적으로 설치가 끝날 때까지 _ 동기화 됨 _되므로 다음 중 하나에서 문제를 피할 수 있습니다. 두 가지 방법:
  • cmd /c start /wait msiexec /i example.msi PROPERTY='Nat "King' Cole' - cmd.exe 호출에 의존하여 "" -escaping 트리거
  • Start-Process -Wait msiexec '/i example.msi PROPERTY="Nat ""King"" Cole"' - -ArgumentList ( -Args ) 매개 변수를 사용하여 단일 문자열 인수를 프로세스 명령 줄로 그대로 전달합니다 (이 매개 변수가 작동하는 방식은 아니지만- # 5576 참조).

• 위의 조정으로 충분하지 않은 다른 비 전통적인 CLI-개인적으로 알지 못합니다.

하루가 끝나면 항상 해결 방법이 있습니다. cmd /c 를 통해 호출하거나 콘솔이 아닌 애플리케이션의 경우 Start-Process 를 통해 호출하거나 --% . ins ( Invoke-NativeShell ) cmdlet을 제공하는 경우 다른 옵션입니다. dbea ( Debug-ExecutableArguments echoArgs.exe 와 유사한 기능을 가진 Debug-ExecutableArguments cmdlet은 필요에 따라 배치 파일에 대해서도 _diagnose_ 문제를 해결하는 데 도움이됩니다.

브레이킹 체인지와 옵트 인의 경로는 다음과 같습니다.

• 이 기능을 실험적 기능으로 구현하면 충분한 관심이 표시되면 _default_ 동작이되어 (사소한) 주요 변경 사항이 될 것이라는 의미입니까?

• 이 실험적 기능이 그 중요성을 감안할 때 널리 공개되었는지 확인해 주시겠습니까?

  • 실험적 기능에 대한 일반적인 우려는 _all_ 실험적 기능이 기본적으로 켜져 있다는 점을 감안할 때 미리보기 버전에서 종종 _ 무의식적 _ 일 수 있다는 것입니다. 우리는 사람들이이 기능을 의도적으로 알고 사용하기를 바랍니다.