나는 아이디어를 좋아하고 유용하다고 생각하지만, 단일 문자열 확장을 얻을 수 있다면 훨씬 더 유용 할 것이라고 생각합니다 (DSL의 경우 특별히 생각하고 있습니다). 따라서 내 PS에서 cmd.exe 호환 문자열을 구축했다면 cmd.exe에 그대로 문자열을 지정할 수 있습니다. 혹시

&n -command $string

잠재적으로 내 통역사를 지정할 수 있습니다.

&n -shell /bin/sh -command $string
또는
&n -shell cmd.exe -command $string

이름 / 연산자 측면에서 "&!" 사용? shbang ( "#!")과 유사합니다.

$! 은 좋은 제안입니다!

쉘은 단순히 명령으로 지정하여 지정할 수 있습니다.

&! /bin/sh -c blah

$var 확장은 $ 가 기본 명령 / 셸에 전달되기 위해 리터럴이어야한다는 문제를 만듭니다. 이것이 피하려고하는 문제 중 하나는 사람들이 모든 것을 적절히 피하는 방법을 알아 내야 할 때입니다. 변수 확장이 필요한 경우 항상 다음을 수행 할 수 있습니다.

$mycommand = "/bin/sh ls"
Invoke-Expression "&! $mycommand"

그러나 PowerShell을 기본 명령과 혼합하려는 경우 현재 구문을 사용하고 고급 사용법을 고려할 때 적절하게 이스케이프해야하는 항목을 인식하는 것이 가장 좋습니다.

$mycommand = "/bin/sh ls"
Invoke-Expression "&! $mycommand"

방금 iex를 제안하신 다니 믿을 수 없습니다. :-)

@essentialexch 적절한 곳이 몇 번 있습니다. :)

이 예제에서 예상되는 것은 사용자가 실행하기 전에 $mycommand 의 내용을 제대로 확인했음을 의미합니다!

당신이 설명한 것과 같은 문제에 대한 훌륭한 글과 해결책이 반드시 필요합니다.
나도 --% 에 대해 몰랐고 안타깝게도 본 적이 없었습니다. 따라서 제안 된 &n 연산자는 유사한 검색 가능성 문제를 겪을 수 있으며 기호를 문자와 결합하는 것이 자연스럽지 않습니다 (C printf 문에서 % f를 상기시킵니다). 어쨌든 주요 변경 사항이므로 예를 들어 && 일 수없는 이유가 있습니까?
실행하려는 영역을 표시하기 위해 대괄호 (또는 이중 중괄호?)와 같은 것을 사용하는 것이 더 직관적 일 수 있습니다. 예 : & [ wsl ls ] | less

나는 &! 가 다른 셸에서 오는 사람들을위한 더 직관적 인 방법이라는 데 동의하지만, super-duper-linter에서는 일반적으로 매개 변수 배열을 빌드 한 다음 명령에 스플래 팅하여 기본 명령을 실행합니다.

$command = 'linter'
$myargs = @(
    '-config'
    'linterconfig.path'
)
if ($Test) {$myargs += 'test'}
& $command <strong i="7">@myargs</strong>

그래서 이것은 조건부 경우에 가장 좋은 방법입니다.

@bergmeister 저는 원래 && 를 시각적으로 생각했는데 오늘날 많은 사람들이 알고있는 & 와 비슷합니다. 그러나 && 가 파이프 라인 체인 연산자 인 경우 수행해야 할 작업에 대해 혼란을 줄 수 있습니다. 현재 &! 제안이 마음에 듭니다.

@JustinGrote , 계속 사용하지 않을 이유가 없습니다. &! 구문은 실제로 잘라내어 붙여 넣기를 원하거나 PowerShell 구문과 충돌하는 인수가 있고 제대로 이스케이프하는 방법을 원하지 않거나 모르는 경우에 적합합니다.

오 이런, 10 년 전에 브루스와 제이슨과 토론했던 기억이 난다. 내 직감은 여기서 다른 연산자를 발명하는 것이 불필요 해 보인다는 것입니다. 이 스레드의 일부 사람들은 --% 에 대해 들어 보지 못했지만 당신이 생각하는 것보다 더 많은 것을 걸겠습니다. 문제 :

# run ls in wsl, return results to powershell, then pipe to wsl again, to grep.
& wsl ls | wsl grep -i "foo"  

#  the entire pipeline right of wsl will run in wsl. 
& --% wsl ls | grep -i "foo"

왜 아무도 이것을 제안하지 않았습니까? "이 이후의 모든 것은 특별한 powershell 처리없이 전달 될 것입니다."라고 말하는 것은 다른 곳에서 --% 사용과 논리적으로 일치합니다.

@oising , 실행하려는 명령으로 시작해야하므로 해당 명령이 작동하지 않습니다. 기능 추가를 제안합니까?

이것은 예상대로 수행됩니다.
function Invoke-LiteralCommand ($command) {Invoke-Expression "& $command --% $args"}

Invoke-LiteralCommand ping -W 200 www.google.com | grep icmp

@JustinGrote 예, 지금 작동하지 않는다는 것을 알고 있습니다. :) &n 또는 &! 또는 그 밖의 이야기를 _ 대신 _ 제안하고 있습니다. 그것은 나에게 더 의미가 있습니다. & 는 호출이고 --% 는 powershell 구문 분석을 억제합니다. 함께 그들은 새로운 것을 추가하는 것보다 일관되고 발견 가능합니다. 나는 "통화"와 "원래 전화"교환 원이 있다는 생각이 싫다.

차이점을 보여주기 위해 예제를 확장했습니다.

@oising 나는 이것이 의미하는 것이라고 생각하는 "bash를 아는 새로운 powershell 사용자"에 대한 많은 둔한 타이핑이지만 새로운 연산자에 대해 멋질 것입니다.

@oising 나는 이것이 의미하는 것이라고 생각하는 "bash를 아는 새로운 powershell 사용자"에 대한 많은 둔한 타이핑이지만 새로운 연산자에 대해 멋질 것입니다.

전혀. PowerShell / cmd.exe / bash 사이의 복잡한 인용 규칙을 이해하지 못하는 PowerShell 사용자를위한 것입니다. 이슈 제목에 "call native"라고 적혀 있기 때문에 네이티브 실행 파일을 호출합니다.

@oising 나는 이것이 의미하는 것이라고 생각하는 "bash를 아는 새로운 powershell 사용자"에 대한 많은 둔한 타이핑이지만 새로운 연산자에 대해 멋질 것입니다.

전혀. PowerShell / cmd.exe / bash 사이의 복잡한 인용 규칙을 이해하지 못하는 PowerShell 사용자를위한 것입니다. 이슈 제목에 "call native"라고 적혀 있기 때문에 네이티브 실행 파일을 호출합니다.

사실, 또는 그들에 대해 전혀 생각할 필요가없는 우리를위한 것입니다.

네, @oising입니다. 이 개념은 존재하지만 매우 불충분합니다. 완전히 새로운 것을 구현하려면 이전 구문을 폐기 / 제거하는 것이 좋습니다.

나는 종종 이러한 아이디어가 목소리를 내고 실제 대상 인구 통계에 충분한 가중치가 부여되지 않는다고 느낍니다. 사용자가 _already_은 기존의 방법을 찾기 위해 애 쓰고, 그들이 발견되면 부족한 기존의 방법을 찾는 경우는 A A에 호출) 문서를 개선하고, b)는 향상 기존 사업자의 실제 기능입니다.

대신에 우리는 어떻게 든 이미 사용자가 자연스럽게 그것을 발견하기위한 접근 것만으로는 충분하지 않습니다 문서에 의존 아직 _another_ 연산자를 도입하면서 과거 문제를 해결하도록되어 이상한 옵션 c)를 얻는다.

이러한 개념을 소개하는 데 오류 메시지 및 / 또는 제안 시스템을 사용해야한다는 데 동의합니다. 우리가 세 번째가 필요하다는 데 동의하지 않습니까? 네번째? 다섯? (나는 말 그대로 카운트를 잃었습니다. 누군가가 나를 도와줍니다) 명령을 호출하는 방법. 기존 방법은 불충분합니다. 즉, 사용자가 파고 들기 시작할 때 사용자를 더 혼동시키기 위해 거미줄처럼 남겨 두지 말고 _ 개선해야합니다 _.

사람들이 무언가를하는 5 가지 방법이 있다는 것을 깨달을 때받는 첫 번째 질문은 "말 그대로 같은 일을하지만 잘 작동하지 않는 2 ~ 3 가지 방법이있는 이유"입니다. 제 대답은 항상 그렇습니다. -PS 팀은 기능을 추가 / 개선하려고 할 때 지난 10 년간의 모든 것 ++이 여전히 작동하는지 확인하는 데 너무 집중하고 있습니다. 여기에서 다시 볼 수 있습니다. 기존이지만 수정 및 개선이 필요한 불충분 한 구현이 있으며 제안 된 솔루션은 잠재적으로 불완전한 다른 구현을 추가하여 풀을 더욱 혼란스럽게 만드는 것입니다.

우리는 IMO라는 다른 구현을 다시 시작하는 것이 아니라 시작하는 것을 끝내야합니다.

나는 우리가 &를 몇 가지 이상의 고유 한 사용 사례에 사용하려면 이것을 동사로 간주하거나 언어 전반에 걸친 표준화를 살펴 봐야한다고 생각합니다.

내가 원하는 마지막 것은 &가 무엇을 할 것인지에 대한 혼란입니다. 전체적으로.

3 가지 시나리오를 고려합니다.

1. 전체 확장-현재 PowerShell 동작.
2. 전체 리터럴-OP에서 제안됩니다.
3. 부분 확장- wsl ls $path 여전히 작동

@ mklement0 댓글이 어디에 있는지 궁금합니다. :-)

이 글을 읽을 때 나는 생각했다. 좋은 생각이야! 그러나 댓글을 읽은 후 생각하기 시작했습니다. 나는 항상 & 명령이 'PS 표준이 아님'과 'PERL days'(ugh)를 상기시켜주는 것을 발견했습니다. 또 다른 비표준 PS 명령 (명사 동사가 아님)을 도입하는 것은 도움이되지 않습니다. 추신.

-% 매개 변수에 대해서도 몰랐습니다. 솔루션으로 @JustinGrote 와 동일한 원칙을 사용합니다.

PS 셸로 자르기 / 붙여 넣기 명령이 나의 주요 '것'이었던 적이 없습니다.
이러한 기본 명령을 PowerShell 명령으로 바꾸는 것이 더 낫지 않을까요?
cmd.exe를 완전히 대체 할 경로를 만드십시오 ...

나는 기존 명령을 개선하기 위해 투표합니다. 그리고-실제로-% 및 & 사용에 대한 일부 문서 개선

@iSazonov @ SteveL-MSFT가 제안하는 사용 사례는 '컷 붙여 넣기'시나리오입니다. 부분 확장은 일을 훨씬 더 어렵게 만들 것입니다 (AST 측에서)

즉시 "#!" 그리고 "!#". "&!"를 좋아합니다.

토크 나이저의 함수 호출에 토큰 가속기를 추가하는 방법을 살펴볼 수 있습니다. 이것은 다음의 사용을 허용합니다.

Iex -l
또는 전달하기 전에 구문 분석을 중지하는 Invoke-Expression -literal.

파싱 ​​수준에서 더 많은 고유 토큰을 추가하면 진입 장벽이 올라가고이 기능에 대한 검색 가능성이 낮아집니다.

예를 들어 Get-Help &는 아무것도 표시되지 않습니다. 그리고 about_Operators에서 찾아야합니다.

그러나 문서화되지 않은 call_operator에 대한 고유 한 경우가 있습니다.
& modulename {명령}
모듈로 범위를 지정할 수 있습니다. 그리고 더 많은 것이 있다고 확신합니다. 그러나 검색 가능성이 너무 낮아서 기본 문서 내에서 찾기가 어렵습니다. 그리고 커뮤니티는 JSnover와 그가 우리에게 멋진 것을 보여준 강연을 통해서만 그것에 대해 알고 있습니다.

새로운 사용자 관점에서이 "기능"이 얼마나 검색 가능한지 완전히 고려해야한다고 생각합니다. 새로운 사용자는 pwsh 코어에 대한 새로운 사실을 알지 못해도 Powershell 5에서이 기능을 사용하려고 할 것입니다. 검색 가능성이 너무 낮습니다.

기존 동작을 변경하고 싶지만 PowerShell에서 이러한 기본 API를 변경하면 많은 것을 망칠 수 있습니다. 구성으로 마이그레이션하는 것을 고려할 수 있습니다.

PS 6가 GA되기 전에 더 직접적으로 문제를 해결하는 것이 가능했을 수도 있지만 솔직히도 이전 버전과의 호환성에 심각한 위협이되었을 것입니다 (Python의 print() 함수와 다르지 않음).

하위 프로세스에 인수를 전달하는 측면에서 동기 호출과 Start-Process 호출 모두 이미 정밀 검사에 대해 논의한 문제가 있다고 생각하며 일관성을 위해 한 번에 투자해야한다는 느낌이 있습니다. 특히 Start-Process는 인수 배열 전달 지원을 업데이트해야합니다.

cmdline arg 전달을 사용한 동기 호출의 경우 네 가지 종류의 인수 전달이 가능합니다.

• Windows에서 CommandLineToArgvW 을 받고 예상치 못한 결과가 발생하는 레거시가 될 현재 동작
• 표현식 값으로 인수를 전달해야하지만 일반적인 베어 워드 토큰 규칙을 적용하여 > 및 | 와 같은 항목이 별도의 명령을 수행하도록하는 기본 동작입니다. 이 모드에서 하위 프로세스가 표현식에서 가져 오는 값은 Write-Host $val 표시되는 값이어야합니다.
• 이스케이프 토큰이 보일 때까지 모든 토큰이 베어 워드 문자열로 해석되는 축 어적 동작입니다. 이것은 --% 이 오늘해야하는 일이지만 이상적으로는 --% ... %-- 와 같이 같은 줄에 삽입 할 수있는 끝 토큰이 하나뿐입니다.
• 대체 sh 지향 이스케이프 논리가 적용되어보다 간단한 호환성을 허용하는 Bash readline 동작

첫 번째 동작은 두 번째 기능을 실험적 기능으로 도입 한 다음 교체하여 천천히 단계적으로 제거해야한다고 생각합니다.

두 번째 및 세 번째 동작은 &! 및 &# 또는 +% ... -% 의 고유 한시길을 가질 수 있습니다. 그러나 축어 모드의 경우 더 많은 토큰이 축 어적으로 취해 지도록 이스케이프 토큰을 단순화하는 것이 중요하다고 생각합니다. heredoc과 유사합니다.

요청이 "이 연산자 이후의 모든 텍스트 내용은 실행할 OS의"기본 셸 "을 호출합니다."와 같은 복사-붙여 넣기 시나리오를 처리하는 것 뿐인 경우. shell 이것을 명시 적으로 말하지 않는 이유는 무엇입니까?
```파워 쉘
PS> 쉘 wsl ls | 적게
PS> (shell wsl ls * .txt) | Select-String Hello

Forth / APL 스타일의 암호 연산자보다 검색 및 읽기가 더 쉽습니다.

나는 이것이 어떻게 해결 될지 모르겠다 # 1995 : https://github.com/PowerShell/PowerShell/issues/1995#issuecomment -653174261 참조

또한 WSL의 문제는 powershell이 ​​아닌 wsl.exe (https://github.com/PowerShell/PowerShell/issues/12975#issuecomment-650353021 참조) 동작의 문제입니다.
(좋아요, powershell에 문제가 있지만 그건 # 1995입니다)

아, 그리고 이것은 https://github.com/PowerShell/PowerShell/issues/12975의 거의 중복되지 않습니까? 본질적으로 대부분 반복 할 수 있기 때문에 여기서 언급 한 내용은 다음과 같습니다.

뿡 빵뀨

문제는 varbatim을 수신하는 명령 / 스크립트로 전달할 명령 줄의 일부를 구분하는 기능이 없기 때문에 항상 사용자를 방해한다는 것입니다.

"varbatim을 전달할 명령 줄 부분"이란 무엇을 의미합니까? 의미합니까 1. 호출 된 실행 파일에 문자 시퀀스를 그대로 전달하여 호출 된 실행 파일이 인수 배열의 한 요소에이 문자 시퀀스를 갖도록합니다 (예 : 이러한 문자는 [main]의`argv [1]`에서 사용할 수 있습니다. ] (https://docs.microsoft.com/en-us/cpp/cpp/main-function-command-line-args?view=vs-2019#command-line-arguments)) 또는 2. insert를 의미합니까? 일부 문자 시퀀스는`CreateProcess`의 [`lpCommandLine` 매개 변수에 그대로 포함] (https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessw#parameters)- -(1.)을 의미하면 기본적으로 이미 작동합니다.

PS /home/User> /bin/echo 'cd / && ls . | cowsay'
cd / && ls . | cowsay
PS /home/User>

(https://github.com/PowerShell/PowerShell/issues/1995에서 논의 된 삽입 된 따옴표 문제를 제외하고) 누군가는 여기에 한 줄 문자열을 추가하면 일부 사용 사례가 향상 될 것이라고 주장 할 수 있지만, 저는 다음과 같이 생각합니다. 그게이 문제의 핵심이 아닙니다. 이것은 이미 어느 정도 작동하므로 (2.)를 의미한다고 생각합니다 .--- (2.)를 의미한다면, 그것에 대한 제 의견을 다소 극적인 방식으로 말하겠습니다 : 제발 제발 추가하지 마십시오 이것에 대한 특별한 구문. 이것은 기본적으로`-%`가 시도한 일이며, 구현 된 적이 없어야합니다. 내가 왜 그렇게 강력하게 반대하는 걸까요? 1. Windows에서만 발생하는 문제이므로 구문을 추가하면 Windows의 powershell이 ​​Linux와 다른 구문을 갖게됩니다. (또는 구문이 지원되지만 현재`-%`의 경우이므로 완전히 의미가 없습니다.) 2. Microsoft에서 게시 한 Windows의 기본 명령 줄 셸이 via가 아닌 특수 구문을 통해 일류 기능을 추가하는 경우 a cmdlet)를 사용하여 일반적인 [명령 줄 구문 분석 규칙] (https://docs.microsoft.com/en-us/cpp/cpp/main-function-command-line-args?view=vs)을 따르지 않는 실행 파일을 호출합니다. -2019 # parsing-c-command-line-arguments) (도구가 일반적인 규칙을 따르는 경우 필요하지 않습니다 (2.), 일반적으로 더 잘 사용할 수 있습니다 (1.)). 그러면 명령 줄 작성자에게 권장됩니다. 도구를 사용하여 이러한 규칙을 따르지 않으면 [ "Windows 명령 줄 무질서"] (https://stackoverflow.com/a/4094897/2770331)가 악화 될뿐입니다. 일반적인 규칙을 따르는 사람이 적을수록 프로그래밍 방식으로 외부 실행 파일을 호출하거나 일반적으로 크로스 플랫폼 코드를 작성하기가 더 어려워 지므로 프로그램 작성자는 이러한 일반적인 규칙을 따르도록 권장해야합니다. 3. 이것이 일반적인 사용 사례라는 것은 의심 스럽습니다. 그리고 이것은 WSL에만 영향을 미치는 문제가 아닙니다. Windows 터미널의 wt 명령 줄 호출 및 기타 많은 도구에도 영향을줍니다. 그러한 문제가 발생하는 몇 가지 예를 추가 할 수 있습니까? WSL의 경우 WSL의 명령 줄 구문 분석은 단순히 [깨진] (https://github.com/Microsoft/WSL/issues/1746) (문제는`bash.exe`에 관한 것이지만 상황은 기본적으로`wsl.exe`를 사용하는 것이 좋지 않음)-일반적인 [명령 줄 구문 분석 규칙] (https://docs.microsoft.com/en-us/)을 따르지 않는 모든 도구를 고려합니다. cpp / cpp / main-function-command-line-args? view = vs-2019 # parsing-c-command-line-arguments) 고장 났지만 WSL의 기본 동작은 IMHO가 제대로 문서화되지 않았습니다. "`wsl.exe`의 동작이 깨졌습니다.이 응답을 작성하는 동안`-e`를 사용할 때`wsl.exe`가 실제로 예상대로 동작하는 것처럼 보입니다.

PS C:\> wsl -e bash -c 'cd / && ls . | cowsay'
 _______________________________________
/ acct bin boot cache cygdrive data dev \
| etc home init lib lib64 lost+found    |
| media mnt opt proc root run sbin snap |
\ srv sys tmp usr var                   /
 ---------------------------------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||
PS C:\>

따라서이 명시 적 사용 사례에서 누락 된 유일한 것은 다른 일반 exe에서와 같이 구문 분석 된 명령 줄 인수로 기본 셸을 호출하는`wsl.exe`에 대한 매개 변수 인 IMO입니다.

"수신 명령 / 스크립트에 varbatim을 전달할 명령 줄 부분"에 관한 유일한 것은이 연산자로 개선 될 것입니다. 위의 의미 (2.)가 될 것입니다. 앞서 언급했듯이 그 방향으로 개발하는 것은 다음과 같습니다. 나쁜.

바로 가기 만 있으면 기존 명령 줄을 복사하여 붙여 넣기 만하면됩니다. cmdlet (예 : Invoke-Shell , linux에서는 bash -c 호출, cmd /c 호출) 창문?
그럼 당신은 할 수 있습니다

Invoke-Shell @'
whatever existing comandline containg '"quotes"' or whatnot
'@

한 줄이어야한다면 여기에 한 줄 문자열 구문을 추가하십시오.하지만 제대로 찾을 수없고 모든 것을 복잡하게 만드는 특수 연산자를 구현하지 마십시오.

그리고 이것을 위해 # 1995를 포기하지 마십시오!

"sigil"이라는 단어 사용시 +10 점.

&! 대 shell 은 "shell"이 일반적인 영어 단어이므로 사람들이 shell이라는 기존 명령을 가질 수 있다는 것입니다. (사실 "shell"이라는 이름의 함수와 "n"이라는 이름의 함수가 모두 있습니다 (따라서 &n 는 마음에 들지 않습니다).)

@oising : & --% 는 멋지 지만 , 제안 된 기능의 명시적인 목적 중 하나는 | 가 기본 쉘로 전달되는 무언가가된다는 것을 의미하는 것입니다. PowerShell 구문 분석으로 돌아가는 것은 아닙니다 . 그리고 & --% 의 파이프 라인 우선 순위를 foo $blah --% more args 와 다르게 만들면 당황 스러울 것입니다 ... & $foo --% more args | blah 했다면 어떨까요? 따라서 제 생각에는 제안 된 &! 는 다른 연산자를 갖는 것을 보증 할만큼 충분히 다릅니다. (다시 말해 : 제안 된 기능은 관련이 있지만 & 및 --% 결합하는 것과는 다릅니다 .)

이 기능은 "bash를 알고있는 새 PowerShell 사용자"와 "복잡한 인용 / 이스케이프 규칙을 모두 모르는 사용자"를위한 것 이상입니다. 또한 모든 것을 조작 할 필요없이 StackOverflow에서 명령을 복사 / 붙여 넣기 만하는 가장 전문적인 사용자를위한 것입니다. 이것은 나에게 꽤 많이 발생합니다. 내가 작업하는 제품에는 작업 방법에 대한 많은 문서가 있고 언어 프랑카는 cmd.exe 명령입니다. 따라서 % VARIABLE_REFERENCES % 등을 수정해야합니다. .; &! 를 입력 한 다음 붙여 넣는 것이 훨씬 더 좋을 것입니다. 실제로 이것이 구현 된 경우 "StackOverflow 연산자"라고합니다. :디

@ vexx32 : 이것은 "모두를 지배하는 하나의 링"호출 교환 원이 아닙니다. 일반적인 문제를 해결하기위한 도구 상자의 또 다른 도구입니다. 이 도구를위한 공간을 만들기 위해 기존 도구를 제거해야한다고 생각하지 않습니다. 그들은 다른 일을합니다. 도구 상자에 망치, 스크루 드라이버, 드릴, 임팩트 드릴, 네일 건이있을 때 신규 사용자가 압도 감을 느낄 수 있다는 것을 알고 있습니다. 사물 "은 전문가에게 매우 중요합니다. 모두 서로 다른 상황에서 사용됩니다.

@TSlivede : # 1995가 별도라는 데 동의합니다. 하지만 "Windows 전용 문제"에 동의하지 않습니다. StackOverflow에서 플랫폼 별 명령을 복사하여 붙여 넣는 것은 모든 OS에 동일하게 적용됩니다. (사실, 이것은 한 플랫폼에서 다른 플랫폼보다 더 강한 저와 같은 많은 사람들에게 매우 도움이 될 것입니다. 저는 Windows 기술에 더 능숙하기 때문에 Linux에서 나는 SO에서 복사 및 붙여 넣기를 많이하는 경향이 있습니다.)

새로운 연산자 &! 또는 Invoke-Shell 명령을 통해 다른 사람들처럼 강한 감정을 느끼지 않습니다 ... 저는 연산자를 찾기가 어렵다고 불평하는 사람들에게 공감합니다. 저는 &! 의 간결함을 정말 좋아합니다.

@jazzdelightsme 이것은 "현재 이미 _okay_이고 개선 될 수있는 약 3-5 개의 스크루 드라이버를위한 또 다른 믿을 수 없을만큼 구체적인 스크루 드라이버 부착"만큼 "도구 상자의 또 다른 도구"가 아닙니다.

@jazzdelightsme "Windows 전용"부분은 내가 원래 그 성명서를 게시 한 문제와 더 관련이있을 수 있습니다. 예, 그렇습니다. 이것은 해당 문제의 정확한 중복이 아닙니다.

# 1995가 포기되지 않고 여기에서 요청 된 기능이 특수 구문을 통해 해결되지 않고 커맨드 렛 (또는이 특수한 경우뿐만 아니라 모든 곳에서 작동하는 한 줄의 여기 문자열에 대한 새로운 구문)을 통해 해결되면 실제로 찬성합니다. 이 기능을 추가합니다. (또는 "찬성"이 아니라 "내가 전적으로 받아 들일 수있는 일")

또 다른 아이디어 : 이것이 문제가 실제로 네이티브 셸용으로 의도 된 전체 명령을 복사 및 붙여 넣기에 관한 것이라면 PsReadLine은 명령을 대략적으로 bash 또는 cmd 스타일에서 powershell로 변환하는 기능을 추가 할 수 있습니다. 변환은 특수 키 조합에 의해 트리거되거나 명령을 실행하려고 할 때 구문 분석 오류가 발생하는 경우 자동으로 트리거 될 수 있습니다.

이것은 사용자에게 powershell의 구문을 가르치는 추가적인 이점이 있습니다.

검색 가능성과 관련하여 : PsReadLine은 구문 상 잘못된 콘텐츠 (번역 후 유효 함)를 붙여 넣을 때마다 특정 키 조합을 사용할 수 있다는 메시지를 항상 짧은 시간 동안 표시 할 수 있습니다.

그러나 이것이 실현하기가 조금 복잡하다는 것을 이해할 수있었습니다.

@jazzdelightsme @joeyaiello 와 이야기 했습니까? 나는 그가 그것을 StackOverflow operator 라고 불렀다고 생각했는데 그것이 매우 사실 임에도 불구하고 나를 움찔하게 만들었다

@ SteveL-MSFT 아니요 저는 이것에 대해 아무에게도 말하지 않았습니다. 나는 "StackOverflow operator"에 독립적으로 도착했습니다. xD

안녕하세요.

... 제안 된 기능의 명시 적 목적 중 하나가 다음을 의미한다는 점을 제외하고 | 네이티브 셸로 전달되는 것이됩니다. PowerShell 구문 분석으로 돌아가는 것은 아닙니다.

제 제안을 이해 하셨는지 잘 모르겠습니다. 당신이 말하는 것은 _ 정확하게 _ 내가 말하는 것입니다. 전략적으로 대문자로 된 힌트를 좀 더 자세히 설명하겠습니다 .D

# NON-OPTIMAL SOLUTION: run "ls" in wsl, return results to powershell, then pipe to wsl again, to "grep."
& wsl ls | wsl grep -i "foo"  

# NEW SOLUTION: the entire pipeline/string, INCLUDING THE PIPE SYMBOL, right of wsl will be executed in wsl. 
& --% wsl ls | grep -i "foo"

# NEW SOLUTION: the entire pipeline AS ABOVE is sent to WSL, then the results are returned to powershell
# and piped, in powershell, to foreach-object
(& --% wsl ls | grep -i "foo") | % { "match {0}" -f $_ }

# NEW SOLUTION: allow placing --% beyond first argument
# pass everything right of --% to the command in $wsl 
$wsl = gcm wsl
& $wsl --% ls | grep -i "foo"

# or

& wsl --% ls | grep -i "foo"

# NEW SOLUTION: execute multiline pasted code without powershell parsing.
& --% @'
(pasted multiline code)
@'

내가 여기서 무엇을 놓치고 있습니까? 파이프가 --% 뒤에 나타나면 그것은 또 다른 멍청한 문자 인 인수입니다. 연산자 우선 순위를 뒤틀 지 않습니다. 중첩 된 파이프 라인 또는 하위 식에 포함 된 경우 powershell에 대한 구문 분석을 다시 시작합니다.

만약 당신이 & $ foo-% 더 많은 args | 어쩌구?

음, $foo 에서 인수를 실행하고 "more" , "args" , "|" 및 "blah" 을 전달하여 $foo 원합니다. 규칙은 나에게 충분히 간단 해 보이지만, 저는 오랫동안 powershell / monad를 사용해 왔습니다. & $foo --% ... 는 --% 다른 인수처럼 취급하므로 이는 & 대한 주요 변경 사항이 아닙니다. 그래서 우리가이 인장을 다른 곳에서 사악하게 사용하지 않았다면 우리는 안전해야합니다.

생각?

부분 줄 평가, 여러 줄 평가 및 --% 의 변수 위치를 다루기 위해 위를 여러 번 편집했습니다. 새로운시길, 연산자 또는 이상한 구문을 도입하지 않아도됩니다. 나는 그것이 그것을 커버한다고 생각한다. 유일한 것은 : 파서가 그것을 처리 할 수 ​​있는가? @lzybkr @JamesWTruher @BrucePay ?

@TSlivede를 듣고, 듣고.

무뚝뚝한 저를 용서하십시오. 그러나 우리는 이러한 문제에 대해 오랫동안 이야기 해 왔습니다.

이 문제가 제안하는 것은 마 법적 사고에 해당합니다.
이는 불운하고 본질적으로 문제가되는 "구문 분석 중지 기호" --% 와 관련이 있습니다.이 기호는 현재 형식에서 _Windows_에서 제한적으로 사용됩니다 (https://github.com/MicrosoftDocs/PowerShell- 참조). Docs / issues / 6149) 및 _Unix와 유사한 플랫폼 _에서는 거의 쓸모가 없습니다 (https://github.com/MicrosoftDocs/PowerShell-Docs/issues/4963 참조).
--% 은 (는) 구현되어서는 안되며이 제안도 제시된대로 구현되어서는 안됩니다.

마 법적 사고는 두 가지 아이디어가 개념적으로 혼돈 된 것입니다.

• (a) " & 또는 | 와 같은 쉘 메타 문자에 대해 걱정할 필요없이 공백으로 구분 된 토큰을 일부 외부 프로그램에 전달하여 베어 워드를 허용하고 싶습니다." - 참조 https://github.com/PowerShell/PowerShell/issues/12975#issuecomment -646276628

  • 물론 이러한 기능은 _ 파이프 라인의 일부로 _ 또는 _pipeline-chaining operator_ ( && 및 || )와 같은 명령을 사용하고 동일한 줄에 추가 명령을 배치하는 것과는 상충됩니다. ; -그리고 명령 줄에서 _PowerShell 변수 및 식 _을 사용할 수 있습니다.

• (b) "내 명령 줄이 _ 일반적으로 사용하는 셸 (또는 명령 줄이 원래 작성된 셸)에서 사용하던 방식으로 처리되기를 원합니다.", 물론 _는 따옴표없이 문자를 사용합니다. & 또는 | 와 같이 메타 문자로 해석되어 _syntactic_ 의미를 갖습니다.

  • 적절한 경우 : cmd 도 /bin/sh (또는 bash 와 같은 POSIX와 유사한 쉘)도 ls 을 통과하는 방식으로 wsl ls | less 를 허용하지 않습니다. ls , | 및 less _verbatim_에서 wsl -모두 _unquoted_ | 를 _their_ 파이프 기호로 해석합니다.

이러한 아이디어는 서로 상충되며 고유 한 솔루션이 필요합니다. 두 가지 모두 특별한 구문 자체가 필요하지 않습니다.

• (a)에 대한 해결책은 아이디어를 _abandon_하고 대신 _PowerShell의 기존 구문을 사용하여 메타 문자가 사용되도록 _verbatim_-항상 _quoting_ 또는 _escaping_이 필요합니다.

  • 다음 중 하나 : 메타 문자를 포함하는 베어 워드 (따옴표로 묶이지 않은 토큰) _ 전체 _ : wsl ls '|' less
  • 또는 : ` 베어 워드에서 _ 개별적으로 _ 메타 문자 이스케이프 : wsl ls `| less
  • 또는 : _array [변수] _를 사용하여 인수 전달 _verbatim_ : $wslArgs = 'ls', '|', 'less'; wsl $wslArgs
  • 물론, # 1995는 안타깝게도이 접근법이 _embedded_ " _ 외부 프로그램을 호출 할 때 _-_이 문제를 해결해야합니다 _ : 아래를 참조하십시오.

• (b)에 대한 해결책은 실제로 _ 내가 일반적으로 사용하는 셸을 호출하여 _ 명령 줄을 _ 단일 문자열로 전달 _하는 것입니다.

  • @TSlivede가 제안한대로 명령 줄을 _ 단일 문자열로 전달하고 _ _platform-native shell_을 호출하는 Invoke-Shell cmdlet이 해결책입니다. 이미 축어 문자열 ( '...' 대한 구문이 있습니다 @'<newline>...<newline>'@
  • 내 추천은 그것을 Invoke-NativeShell 라고 부르고, Unix와 같은 플랫폼에서 bash 아니라 /bin/sh 를 부르는 것입니다.
    
    
    
    • 또한 ins 를 간결한 별칭으로 정의하는 것이 좋습니다.
    
    
  • 이 접근 방식은 --% 및 제안을 통해 모든 개념적 문제를 해결합니다.
    
    
    
    • 네이티브 셸에 전달 된 명령이 끝나는 위치 (_ 단일 문자열 _이기 때문에)를 매우 명확하게하고 일반 PowerShell 파이프 라인에서 Invoke-NativeShell / ins 호출을 사용할 수 있습니다. 모호하지 않은 PowerShell 리디렉션.
    
    
    • 선택적으로 _expandable_ 문자열 ( "...." 또는 here-string 변형)을 사용하여 명령 줄에 _PowerShell_ 변수 값을 포함 할 수 있습니다 ( --% 로는 할 수없는 작업).
    
    

이전 버전과의 호환성이 손상되지 않도록 # 1995를 수정할 수 없다고 결론을 내린 권한이 있기 때문에 기존의 모든 해결 방법이 중단됩니다. https://github.com/PowerShell/PowerShell/issues/1995#issuecomment -562334606-the 우리가 할 수있는 최선의 방법은 가능한 한 간결한 구문을 사용하여 적절한 동작에 대한 옵트 인을 지원하는 것입니다. 그래야 항상 그랬어 야 할 동작을 얻기 위해 길을 벗어나야하는 고통을 최소화 할 수 있습니다. 기본.

따라서 : &! 와 같은 특수 구문 은 @TSlivede 의 RFC에서 제안 된 동작을 기반으로 # 1995를 해결하기 위해 외부 프로그램에 인수를 적절하게 전달하기위한 옵트 인으로 만 제공되어야합니다. https://github.com/PowerShell/PowerShell-RFC/pull/90. 향후 PowerShell 버전이 이전 버전과의 호환성을 중단하도록 허용 된 경우이 동작을 나타내야하는 것은 & 를 사용한 직접 호출 / 호출입니다.

사용자 관점에서 이것은 다음을 의미합니다. 내가해야 할 일은 _PowerShell's_ 구문 요구 사항을 충족하는 것입니다. https://github.com/PowerShell/PowerShell/issues/1995#issuecomment -640711192

예를 들어, 현재 의도 한대로 작동하지 _ 않는 _ 다음 명령 (직접 또는 & 하여 호출 할 때- 이 문서 문제 참조)

PS> &! bash -c 'echo "one two"'
one two   # Currently (invoked with & instead of &! or with neither) prints only 'one', 
          # because PowerShell passes the entire argument (brokenly) as  "echo "one two"",
          # which the target program sees as *2* verbatim arguments `echo one` and `two`

현재 / 이전 PowerShell 버전에서 해결 방법을 찾고있는 사용자는 https://github.com/PowerShell/PowerShell/issues/1995#issuecomment -303345059에서 대부분의 사용 사례를 다루는 간단한 함수를 찾을 수 있습니다 (제한 사항은 https : //에서 논의 됨). github.com/PowerShell/PowerShell/issues/1995#issuecomment-649560892) 및 https://github.com/PowerShell/PowerShell/issues/1995#issuecomment -562334606에서 더 정교한 버전

추신 : (심볼 기반뿐만 아니라) 연산자의 발견 문제는 그 자체로 해결할 가치가있는 별도의 문제입니다. 해결책은 연산자 조회를 허용하도록 Get-Help 를 _ 강화하는 것입니다 _-# 11339를 참조하십시오. 임시 솔루션에 대한 링크.

이전 버전과의 호환성이 손상되지 않도록 # 1995를 수정할 수 없다고 결론을 내린 권한이 있기 때문에-결국 기존의 모든 해결 방법이 중단됩니다. # 1995 (주석) 참조-우리가 할 수있는 최선의 방법은 선택을 지원하는 것입니다. 가능한 한 간결한 구문을 사용하여 적절한 동작을 수행하여 항상 기본값이어야하는 동작을 얻기 위해 길을 벗어나야하는 고통을 최소화합니다.

@ mklement0 옵트 인이 https://github.com/PowerShell/PowerShell/issues/1995 의 일부였으며 거부 된 것 같습니다. 그래서 나에게는 희망찬 생각처럼 들립니다. 내가 잘못?

@AndrewSav , 우리는 원래 구성 또는 환경 설정 변수를 통한 옵트 인에 대해서만 논의했습니다.

그러나 @joeyaiello 는 https://github.com/PowerShell/PowerShell/issues/1995#issuecomment -653164987에서 문제를 종결 할 때 다음과 같이 말했습니다 (강조 추가됨).

우리가 여기서 만지는 모든 것은 파괴적인 변화에 지나지 않으므로 새로운 운영자를 통해 문제를 해결해야합니다.

새로운 연산자는 일종의 옵트 인이지만 문제가없는 연산자입니다 (필요한 것은 안타깝지만 이전 버전과의 호환성의 대가입니다).

이 제안은 # 1995도 해결한다고 알려져 있지만 (주로) _other_ shell의 구문을 수용하는 것을 목표로한다는 점을 감안할 때 그렇지 않습니다. 두 문제가 독립적으로 해결할 가치가 있다는 점을 감안할 때 내 제안은 다음과 같습니다.

• 새 연산자를 소개해 보겠습니다.하지만 # 1995를 수정 (https://github.com/PowerShell/PowerShell-RFC/pull/90을 통해)하는 데만 사용합니다. 즉, PowerShell의 _own_ (non-other-shell-emulating) 오류를 수정합니다. 외부 프로그램으로 전달되는 인수 처리.

  • 그러면 새 코드는 외부 프로그램을 호출 할 때 & 대신 &! (또는 우리가 결정한 형식)을 항상 사용해야합니다 (외부 프로그램에 대해 & 를 더 이상 사용하지 않는 것으로 생각할 수 있음). .
  • _PowerShell_ 명령을 호출 할 때 &! 는 & 처럼 작동해야합니다 (문제가 없었 음). 따라서 &! 일관되게 사용할 수 있습니다.

• 다른 셸에서 명령 줄 재사용 문제를 해결하기 위해 플랫폼에 적합한 기본 셸 (Windows에서 cmd /c 을 호출하는 Invoke-NativeShell / ins cmdlet을 구현하겠습니다. , /bin/sh -c Unix 계열 플랫폼의 경우)) _single string_로 전달 된 명령 줄을 사용합니다.

  • 가장 간단한 경우에는 명령 줄에 ' 가 없으면 일반 작은 따옴표 문자열이 작동합니다. 예 :

    ins 'ls | 고양이 -n '

  • ' 있으면 _doubled_; 예 :

    ins '에코'안녕하세요 '| 고양이 -n '

  • 또는 명령 줄을 전혀 건드리지 않으려는 경우 here-string을 사용할 수 있습니다 (이미 @TSlivede에 표시됨).이 구문은 조금 더 번거롭지 만 항상 작동해야합니다.

    ins @ '
    에코 '안녕'| 고양이 -n
    '@

  • 또한 _expandable_ (보간) 문자열 ( "..." 또는 @"<newline>...<newline>"@ )을 사용하여 _PowerShell_ 변수를 기본 셸에 전달 된 문자열 ( --% 는 지원하지 않음) :

    $ foo = '안녕'
    @ "
    에코 '$ foo'| 고양이 -n
    "@

  • 노트 :

    • Invoke-NativeShell cmdlet은 cmd /c / /bin/sh -c 호출에 대한 상당히 얇은 래퍼로, 직접 직접 만들 수 있지만 그럴 필요가 없다는 이점이 있습니다. 특정 실행 파일 이름과 명령 줄 전달 구문을 알고 있어야합니다.
    • 잠재적으로 유익한 부작용으로 -OutVariable 와 같은 일반적인 매개 변수를 사용할 수 있으며 -Error* 매개 변수가 _stderr_에서 작동하도록할지 여부를 고려할 수 있습니다 (대칭의 경우 Invoke-Command 도 마찬가지입니다. 이는 주요 변경 사항이 될 것입니다.)
      
      
      
      • POSIX와 유사한 셸은 -c 하여 _multiple_ 인수를 지원하기 때문에-실행할 코드를 구성하는 첫 번째 코드와 $0 (!)로 시작하는 해당 코드에 전달할 인수를 후속하는 인수-예 : bash -c 'echo $@' _ 1 2 3 -선택적 추가 인수도 지원되어야합니다.
      
      
      • 플랫폼 네이티브 셸이 호출되기 때문에 이러한 호출은 cmd 및 sh 간의 근본적인 차이로 인해 정의에 따라 _not_ 이식 가능합니다.이것이 PowerShell의 _own_ argument-passing (# 1995)을 수정하는 것이 중요한 이유입니다. 그러면 외부 프로그램을 호출하는 신뢰할 수 있고 진정한 크로스 플랫폼 방법을 제공하기 때문입니다.
      
      

퍼즐의 마지막 조각은 _documentation_입니다.

https://github.com/MicrosoftDocs/PowerShell-Docs/issues/5152 는 단일 위치에서 외부 프로그램 호출 (예 : about_Native_Calls )에 대한 개념적 도움말 항목을 작성하기위한 오랜 제안입니다. 외부 프로그램 호출과 관련된 모든 측면을 다룹니다. 이미 다룬 내용 (추가 메타 문자로 인한 구문의 함정, 원시 바이트 파이프 라인 부재, PowerShell 오류 처리와의 비 통합 등) 외에도 당면한 문제도 논의해야합니다.

• 포함 된 " (및 _empty_ 인수)를 사용하여 인수를 전달하는 방법이 이전 버전 (곧 출시 될 예정)에서 분리되는 방식 (현재 별도의 제안 https://github.com/MicrosoftDocs/PowerShell-Docs에서 논의 됨) / issues / 2361) 및이를 해결하는 방법 (수동 \ # 1995의 도우미 함수 중 하나를 이스케이프 처리 또는 사용,이 중 하나는 주제에 직접 포함 할 수있을만큼 간결함).

• 적절한 인수 전달을 보장하기 위해 향후 네이티브 (외부) 실행 파일을 호출하는 데 &! 사용해야하는 방법입니다.

• Invoke-NativeShell / ins 을 (를) 사용하여 _ 플랫폼 고유 셸용으로 작성된 명령 줄을있는 그대로 _ 실행할 수 있습니다.

흥미롭게도 오늘날 사용자는 다음을 수행 할 수 있습니다.

1. 직접 호출
2. & 운영자
3. 시작 프로세스

사용자가 사용해야한다는 것이 전혀 명확하지 않습니다.

깨진 동작을 수정 한 후 사용자는 다음과 같은 기능을 갖게됩니다.

1. 직접 호출
2. & 운영자
3. 시작 프로세스
4. &! 운영자
5. 시작 -ProcessV2

쉘이 ping 127.0.0.1 를 실행하는 것이 너무 많지 않습니까?

예, @iSazonov뿐만 아니라 다른 연산자를 추가하는 것이 저의 주요 관심사입니다. 이미 혼란스럽고 도움이되지 않습니다. 문서화는 퍼즐의 일부일뿐입니다. 괜찮은 문서를 가지고 있다고하더라도 _5 가지 다른 방법 _이 있다는 사실만으로도 각각 조금씩 다르게 행동하는 것은 항상 혼란을 야기 할 것입니다.

우리가 UX에 대해 전혀 신경 쓰지 않는다면, 우리는 더 많은 것을 추가하는 것보다 기존 사례를 개선하는 것을 선택해야합니다.

우리가 UX에 대해 전혀 신경 쓰지 않는다면, 우리는 더 많은 것을 추가하는 것보다 기존 사례를 개선하는 것을 선택해야합니다.

이전 버전과 호환되어야하므로 할 수 없습니다. 나는 우리가 빙빙 돌고 있다고 느낍니다. https://github.com/PowerShell/PowerShell/issues/1995 는 바로 그 이유 때문에 폐쇄되었습니다.

@iSazonov :

새로운 운영자를 도입하지 않더라도 기존의 지침 부족을 해결해야합니다.

• 제안 된 about_Native_Calls 주제 를 통해 포괄적으로

• 특히 Start-Process 항목에서 사용이 적절한시기에 대한 지침이 현재 부족합니다. https://github.com/MicrosoftDocs/PowerShell-Docs/issues/6239 참조

간단히 요약하면 :

• _console_ (터미널) 프로그램을 호출하는 데 Start-Process 를 사용하지 마십시오 (Windows에서만 사용할 수있는 프로그램을 _ 새 창에서 실행하려는 경우 제외).

• & 를 통한 직접 호출 및 호출은 _equivalent_입니다. (스크립트 블록을 제쳐두고), & 는 명령 이름 또는 경로가 _quoted_이거나 _variable references_를 포함 할 때마다 _syntactic_ 이유로 만 필요합니다.

깨진 동작을 수정 한 후 사용자는 다음과 같은 기능을 갖게됩니다.
직접 호출

• & 운영자
• 시작 프로세스
• &! 운영자
• 시작 -ProcessV2

• 아니, 없을 것 Start-ProcessV2 , 단지 _new parameter_, -IndividualArguments 참조 - https://github.com/PowerShell/PowerShell/issues/5576#issuecomment -552124719

• 예, &! (또는 우리가 결정한 모든 기호)가 있지만 실제로 _ & 및 직접 호출 _을 모두 대체합니다 (적어도 _ 외부 프로그램 _의 경우 _,하지만 사용할 수 있음). _all_ 명령 형식)-통신하기 쉬워야합니다.

쉘이 ping 127.0.0.1 를 실행하기에 너무 많지 않습니까?

ping 127.0.0.1 은 (는) 계속 작동하지만 bash -c 'echo "one two"' 를 사용하려면 다음을 사용해야합니다.
&! bash -c 'echo "one two"'

그것은 불행한 일이지만-직접 호출 / & 동작 _ 수정할 수 없음 _을 감안할 때-가장 좋은 해결책이라고 생각합니다.

다행히도 외우는 것은 간단한 규칙입니다. _ 예측 가능한 인수가 외부 프로그램에 전달되기를 원한다면 &! _

선택의 대체 형식-구성 ( powershell.config.json ) 또는 환경 설정 변수-훨씬 더 문제가 있습니다.

• 기본 설정 변수의 동적 범위 지정은 의도하지 않게 설계되지 않은 레거시 코드에 옵트 인을 적용하는 것을 너무 쉽게 만듭니다. https://github.com/PowerShell/PowerShell/issues/1995#issuecomment -650262164 참조

• 구성은 세션 전체에 적용되므로 옵트 아웃이 완전히 불가능합니다.

• 두 경우 모두 특정 호출과 _ 분리 된 _ 조치가 필요하며, 주어진 호출을 보면 그것이 어떻게 동작할지 알려주지 않습니다. 반면에 &! 는 어떤 동작이 발생할지 의심 할 여지가 없습니다.

최종 사용자에게는 계산기를 시작하고 추가 작업을위한 5 개의 버튼을 찾은 것처럼 끔찍해 보입니다. 😄

우리가 그러한 합병증에 대비할 수있을 정도로 개선하고 싶다면, 아마도 이것은 동작을 단순화하고 V8.0을 릴리스하기 위해 브레이킹 체인지 (직접 호출 및 & )를 수용하기에 충분할 것입니다.

우리의 욕구가 그다지 강하지 않다면, testargs 프로그램이 표시하는 내용과 방법에 대한 권장 사항을 표시하도록 진단 ( prog.exe param1 param2 -Whatif 및 Start-Process -WhatIf에 대해서도 동일)을 충분히 개선 할 수 있습니다. 이스케이프를 올바르게 수행합니다.

스크립트 개발자는 디버거를 테스트하고 사용하는 데 시간을 할애 할 수 있습니다. 그러나 대화 형 세션에서는 모든 사용자가 단순성, 간결성 및 명확성을 원하며 이것이 모든 것보다 중요합니다.

@iSazonov :

그러면 아마도 이것은 동작을 단순화하고 V8.0을 릴리스하기 위해 브레이킹 변경 (직접 호출 및 &)을 수용하기에 충분할 것입니다.

당신은 확실히 _my_ 투표권을 가지고 있지만,이 계획을지지하는 힘이 있습니까? [_update_-# 13129 참조]
이 정도의 변화를 가져 오면 마침내 모든 과거의 짐을 다룰 수 있습니다. # 6745 참조

그토록 개선하고 싶다면

그렇게 많이 원하는 두 가지 이유가 있습니다.

• # 1995, 많은 관련 문제 및 수많은 스택 오버플로 질문에 의해 입증 된 바와 같이 잘못된 인수 통과로 인한 수년간의 고통을 끝내기 위해.

• 이전에 여러 번 언급했듯이 인수로 외부 프로그램을 호출하는 것은 모든 shell_의 _core 명령이기 때문입니다.

역사적으로 Windows 전용 시절에는 가능한 외부 CLI가 부족하여 제대로 호출 할 수 없게되었고, PowerShell의 벽으로 둘러싸인 정원 (PowerShell 네이티브 명령 만 호출)에 머물렀던 사용자는 고통을 느끼지 못했습니다. 하지만 시간은 변했습니다.

우리는 개발, CI 및 배포 작업에 중요한 다양한 크로스 플랫폼 CLI 시대에 살고 있습니다.
PowerShell을 셸로 심각하게 받아들이려면이 문제를 해결해야합니다.

이전 버전과의 호환성을 깰 수있는 v8.0이 발생하더라도 (손가락이 교차됨) 릴리스가 오래 걸릴 수 있으며 임시 솔루션이 필요합니다.

문서에 대해 제안 된 개선 사항이 필요한만큼, 쉽게 사용할 수있는 런타임 솔루션이 없기 때문에 그것들만으로는 충분히 고통을 덜어 줄 수 있다고 생각하지 않습니다.

연산자는 못 생겼지 만 형식이 어떻든간에 _necessitates_ 추가 구문 (타이핑이 더 많음)이 아닌 비파괴 솔루션입니다.

보기 흉하고 입력하기 쉬우 며 언어를 "오염"하지 않는 &! 의 대안은 iep 함수와 같은 간결한 이름으로 내장 _function_을 제공하는 것입니다. ( I nvoke- E xternal P rogram) 여기 에 표시된 모든 문제를 은폐
(우리는 이미 다른 기능 (예 : pause )을 래핑하거나 cmd.exe 사용자 (예 : cd.. [sic])를 수용하는 함수를 제공하고 있습니다.)

따라서 bash -c 'echo "one two"' 가 제대로 작동하도록하려면 iep bash -c 'echo "one two"' 호출합니다.
또는보다 현실적인 시나리오를 사용하려면 :

# Pass JSON to an external utility (Unix example)
# Without `iep`, the embedded double quotes are lost and *broken JSON* is passed.
iep /bin/echo '{ "foo": "bar" }'

다시 말하지만, 우리는 궁극적으로 이전 버전과의 호환성을 유지하기위한 서비스에서 _compromise_에 대해 이야기하고 있습니다. 이것은 최종 사용자에게 필연적으로 성가신 일입니다.

진단 (prog.exe param1 param2 -Whatif 및 Start-Process -WhatIf의 경우 동일)을 개선하여 testargs 프로그램이 표시하는 것과 이스케이프를 올바르게 수행하는 방법에 대한 권장 사항을 표시합니다.

직접 / & 기반 호출은 cmdlet 호출이 아니고 모든 인수가 통과 인수 인 것으로 간주되므로 -WhatIf 를 공통 매개 변수로 취급하는 것은 주요 변경에 해당합니다 (하지만 실제로).

그러한 변경을 기꺼이 받아들이고 싶다면, 우리는 (또한) -DoItRight 스위치 (또는 --% 와 유사한 기호 기반 스위치)를 옵트 인으로 지원할 수 있습니다. 고정 된 행동-그리고 그것은 iep -prefix / &! 접근 방식보다 더 나쁘다는 생각이 듭니다.

(내 생각에 깨지지 않는 진단 옵션은 현재 -WhatIf 지원하지 않는 Invoke-Command 을 향상시키는 것입니다. 그러나 우리가 올바르게 문서화 된 옵트 인을 제공한다면 행동, 나는 이것이 가치가 있다고 생각하지 않습니다.)

저는 @iSazonov에 동의합니다. 상황이 작동해야하는 작업을 수행하기위한 또 다른 일을 소개하는 것이 이상적이지 않지만 @ mklement0에서 언급했듯이 제대로 수정되는 브레이킹 릴리스를 기다리는 것은 매우 오랜 시간이 걸릴 수 있습니다. 우리 중 많은 사람들은 최대한 빨리 해결책이 절실히 필요합니다. 내가 볼 수 있듯이 현재 가장 좋은 해결책은
https://github.com/PowerShell/PowerShell/issues/1995#issuecomment -562334606 맞나요?

@ mklement0 cmdlet은 우리가 수정하려는 것과 동일한 매개 변수의 영향을 받기 때문에 iep / invoke-external 프로그램이 어떻게 작동 할 수 있는지 잘 모르겠습니다. 이것은 파서 문제입니다. cmdlet / 함수 내에서 모든 것을 숨기려고한다면, 뭉개거나 재구성 의도를 취소해야한다는 점을 감안할 때 엄청나게 복잡 할 것이라고 생각합니다. 아니면 내가 뭔가를 놓치고 있습니까?

@oising :

명확하게하려면 다음 링크 iep 기능 (내가 _not_ 가치를 추구해 생각 # 1995, _this_ 제안은 주로에 대해 그렇지 않은 것을 수정 위의 주장대로 ), 비록 영업 이익은이다에 의도 언급 한 것을 메모를 할 _also_ 해결 # 1995.

1995 년은 _PowerShell_의 구문 (다른 셸이 아님)을 사용하여 외부 프로그램에 인수를 _ 신실하게 전달할 수 있습니다.

PowerShell의 자체 구문 분석은 괜찮으며 _PowerShell_ 명령에 인수를 전달하는 한 문제가 없습니다.

대조적으로, _external 프로그램 _에 인수를 전달하는 것은 심하게 손상되었으며, 이것이 iep 수정 사항입니다.

궁극적으로 사용되는 명령 줄이 구성 될 때 _ 장면 뒤에서 _ 인수의 _ 다시 인용 및 이스케이프 _ 결함으로 인해 손상되었습니다.
https://github.com/PowerShell/PowerShell-RFC/pull/90 은 적절한 수정 사항을 제안합니다 (역 호환성을 처리하는 방법에 대한 합의가없고 아직 답변되지 않은 몇 가지 사소한 질문이 있음). 최근에 System.Diagnostics.ProcessStartInfo.ArgumentList 를 도입하여 적절한 재 인용 및 이스케이프를 수행합니다 (PowerShell의 자체 구문 분석에서 생성 된 인수 모음 만 전달합니다). 부수적으로 _on Windows_에서만 필요합니다. Unix에서는 프로세스 시작시 인수를 전달할 때 _ 명령 줄이 없습니다 _ (쉘 외부) : 인수를 배열로 그대로 전달합니다.

요컨대 :

• iep 를 내장 함수로 제공하는 것은 적절한 수정 (중단 변경의 맥락에서)이 구현 될 수있을 때까지 외부 프로그램에 적절한 인수를 전달하기위한 간단한 임시 옵션입니다.

• Invoke-NativeShell ( ins ) cmdlet은 _its_ 구문을 사용하여 _ 다른 셸 _ (네이티브 셸의) 명령 줄을 호출하는 방법을 제공하는 임시 방편이 아닌 적절한 솔루션입니다. 위 참조 .

현재, PERL 명령을 잘라내어 붙여 넣기가 Python에서 예상대로 실행되지 않는 경우가 있습니다. 그림을 이동. 이것은 모든 절단기와 붙여 넣기에 큰 단점이 될 것입니다. 파이썬에는이를위한 특별한 연산자가 있어야한다고 생각합니다.

제 제안을 이해 하셨는지 잘 모르겠습니다. 당신이 말하는 것은 _ 정확하게 _ 내가 말하는 것입니다. 전략적으로 대문자로 된 힌트를 좀 더 자세히 설명하겠습니다 .D

# NEW SOLUTION: the entire pipeline AS ABOVE is sent to WSL, then the results are returned to powershell
# and piped, in powershell, to foreach-object
(& --% wsl ls | grep -i "foo") | % { "match {0}" -f $_ }

내가 여기서 무엇을 놓치고 있습니까? 파이프가 --% 뒤에 나타나면 그것은 또 다른 멍청한 문자 인 인수입니다. 연산자 우선 순위를 뒤틀 지 않습니다. 중첩 된 파이프 라인 또는 하위 식에 포함 된 경우 powershell에 대한 구문 분석을 다시 시작합니다.

생각?

당신이 놓친 것은 외부 프로그램에 대한 인수로 닫는 괄호를 전달할 필요가 있다는 것입니다. 일반적인 DWIM 접근 방식이지만 PowerShell은 HAL이 아닙니다.

모든 자세한 피드백에 감사드립니다. 여기서 나 자신으로 말하고 있습니다. 핵심 내용에 대해 자세히 알아보기 전에 몇 가지 중요한 점을 알려드립니다.

• 나는 여전히 완전히 새로운 것을 깨기로 결정한 vNext / 8.0을 가지고 있지 않습니다. 이전 버전과의 호환성이 중요합니다. 고통 스럽다는 것을 알고 있으며, PowerShell이 ​​실수로 저지른 모든 실수를 다시 돌아가 수정할 수있는 세상에 살고 싶습니다. 그러나 대다수의 PS 사용자는 SO 엣지 케이스에서 무릎 깊이 문제를 겪고 있지 않습니다. 그들은 4-10 년 동안 동일한 해결 방법을 복사 / 붙여 넣기 해 왔으며, 작동 이유를 반드시 알지 못하며 업그레이드시 스크립트가 중단 될 때 "실수를 수정"하는 것에 대해 신경 쓰지 않습니다. 그들은 "PS를 업데이트하는 것이 나를 망가 뜨리고 나는 업데이트를 믿을 수 없다"는 것을 알고 있으며, 결국 더 많은 사용자가 업데이트와 채택을 늦추 게됩니다.
• 나는이 문제의 일부 사람들이이 문제에 많은 다른 희망과 욕구를 투사하거나 또는 다른 수정과 함께 그것을 볼 수 있다고 생각합니다. 나는 # 1995를 닫음으로써 그것을 악화 시켰다는 것을 알고 있으며, 그 점에 대해 유감스럽게 생각합니다 (하지만 구체적으로 고칠 수 있는지는 아직 확실하지 않지만 더 자세히 살펴 보겠습니다). 초보 사용자와 숙련 된 사용자 모두를 당황스러워하지 않고 신속하게 벗어날 수있는 "트랩 도어"솔루션입니다. 우리는 여전히 모든 것에 대한 진정한 크로스 플랫폼 솔루션을 제공 할 수 있도록 하우스의 PS 파싱 측면에 대한 수정 사항에 대해 장기적인 대화를 나눌 수 있습니다.

이제 내가 읽은 코멘트 :

• #! ( &! 또는 $! 중 하나를 사용하여 기본 경우 사용자가 통역사를 지정하지 않을 가능성이 있음)에 맞추려는 제안 된 욕구에 대해주의합니다. . $! net <stuff> 와 같은 작업을하고 싶다면 net.exe 는 내 인터프리터가 아닙니다. 그리고 Windows가 아닌 경우 "네이티브"작업은 여전히 ​​sh / bash / whatever 이전에 전달하는 것입니다. 진 존재의 실행에 전달합니다. 예 내가 파이썬은 구문 분석하지 않으려는 *.py 문자열에 $! /usr/bin/python *.py 또는 $! python *.py 내가 배쉬는 손에 다음 글 로빙하고 싶지. python 와 일치하는 목록.
• @oising이 제안한 것처럼 저는 연산자로 --% 를 선호합니다. 검색 가능성이 문제이며, 우리가 이미 10 년 동안이 검색 가능성을 연구하고 있다는 점을 감안할 때 ( 지금은 Google이 가능합니다! , 그냥 그렇게하겠습니다. (저는 @ SteveL-MSFT를 만든 사람이었습니다.) 대체 고려 사항으로 그의 제안에 넣습니다.)하지만 질문 : 여기에 & 호출 연산자도 필요합니까? --% native.exe do /some $stuff 줄을 시작하는 것은 어떻습니까?
• @rjmholt : 여기 에서 귀하의 의견을 완전히 이해하지는 못했지만 실행 파일 다음 에 오는 기존 --% 동작으로 아무것도 변경하지 말아야합니다.하지만 "새로 만들기"를 수행 할 수 있다고 생각합니다. 동작 "이 실행 파일 앞에 오는 위치와 함께 표시됩니다.

• @jazzdelightsme 에서

  또한 모든 것을 조작 할 필요없이 StackOverflow에서 명령을 복사 / 붙여 넣기 만하는 가장 전문적인 사용자를위한 것입니다.

  제 생각에 이것은 시나리오의 거대한 측면이며 아마도 가장 큰 것입니다. 당신이 Bash와 같은 쉘에 있다고 가정하는 것은 웹 주변의 문서입니다.

• # 1995와 같은 것이 고쳐 졌는지 여부에 관계없이 a) 그런 이상한 가장자리 케이스의 긴 꼬리가 있고 b) 사람들을 해치지 않고는 고치기가 정말 어렵다는 것이 요점입니다. 모든 사람들에게 반드시 해당되는 것은 아니지만 지난 몇 년 동안 우리는 사람들이 잠수하고 싶지 않은 털이 많은 상황에서 벗어나기 위해 이와 같은 "트랩 도어"가 필요하다는 것이 분명합니다. 중첩 탈출 우리의 토끼 구멍 (단지 # 1995과 같은 버그가있다 발견 할 것을 그들이 알고있는 것을 알고도 일단 작동 방지를).

댓글을 검토 할 때 아직 답변해야 할 두 가지 질문이 있다고 생각합니다.

1. PowerShell에서 명령 구분 기호와 그 이후의 모든 항목을 계속 구문 분석합니까? 아니면 명령 구분 기호도 그대로 네이티브 셸에 전달됩니까?
   현재는 할 수없는 일이기 때문에 모든 것을 그대로 네이티브 셸에 전달해야하며 @oising 의 선행 괄호 솔루션이 파이프, 파이프 라인 체인 등을 계속 지원할 수 있다는 점에서 솔루션 이 될
2. 운영자는 무엇입니까?
   위에서 언급했듯이, 저는 --% 좋아합니다. 왜냐하면 이미 "예전처럼하던 일을하세요"연산자로 명성을 얻었 기 때문입니다. 그리고 우리는 새로운 것을 발견 할 수 있도록 재설정해야 할 것입니다. 나는 @ mklement0 과 같은 주장을 이해하는데, 우리가 이렇게하면 --% 의 기술적 의미를 바꾸는 것입니다 (그리고 @ SteveL-MSFT도 나에게이 주장을했습니다).하지만 저는 생각하지 않습니다. 야생에있는 대부분의 사람들은 "cmd에서하던 작업을 수행합니다"라는 관점에서 --% 를 생각하고 있습니다. 나는이 가정을 "네이티브 쉘이 여기에서하는 일을한다"라고 연산자의 정의에 성문화하는 것은 무리라고 생각하지 않는다.

직교 적으로, 우리가 지원할 수도 있고 원하지 않을 수도있는 또 다른 시나리오를 생각했습니다.

Windows에서 cmd는 (효과적으로) PATH 조회에 현재 디렉토리를 포함합니다. 그러나 PowerShell에서는 현재 디렉터리가 PATH 없는 경우 EXE (또는 PATHEXT 모든 항목)를 실행하기 위해 사용자가 ./ 를 미리 추가해야합니다.

그래서 내 열린 질문은 : 실제로 전체 명령 문자열을 cmd에 전달하고 싶습니까? 이 연산자를 사용하여 복사 / 붙여 넣기 시나리오를 밝게하려면 대답은 예라고 제안합니다. 일부 타사 문서 / 튜토리얼은 사용자가 사용할 것으로 예상하는 도구를 배치하는 방법을 반드시 자세히 설명하지 않기 때문입니다. PATH . 그것은 아마 많은 방법 중 하나를 중요하지 않습니다,하지만 난 여기 열거 할을했다.

• 나는 여전히 완전히 새로운 것을 깨기로 결정한 vNext / 8.0을 가지고 있지 않습니다.

예, 문제를 해결하기가 엄청나게 어려운 방식으로 중단하지 않고 이러한 문제를 해결하는 방법을 모르겠습니다. 게다가 저는 여러분에 대해 잘 모르지만 여러 버전을 작성할 때 이러한 복잡한 바인더 / 파서 차이점을 모두 다루고 싶지는 않습니다.

일반적으로 변경 사항을 깨는 것에 반대하는 경우 다른 사람들을위한 것입니다. 그러나 이것은 ITT에있는 사람들에게도 다루어야 할 PITA 일 것입니다.

• @oising이 제안한 것처럼 --% 를 선호하며 전면에 사용하기 위해 오버로드되었습니다. (...) --% native.exe do /some $stuff 줄을 시작하지 않는 이유는 무엇입니까?

나는 이것을 정말로 좋아한다. 이상적으로는 CreateProcess / exec 호출에 최대한 가깝습니다 (nix env var 처리 및 인 / 아웃 리디렉션 또는 콘솔 연결 포함). 또는 cmd.exe / bash 완전히 돌아갈 수도 있습니다.

나는 --% 앞에 & 을 (를) 유지하는 것에 집착하지 않습니다. 나는 적어도 내 머리 속의 지시자 / 연산자처럼 원시 --% 를 취급한다는 생각을 정당화 할 수있다. 여러 줄은 어떻습니까? --% 를 @" 및 "@ 와 함께 var 대체 및 하위 표현식에 사용하고 작은 따옴표 @' 및 '@ 를 사용하여 리터럴을 전달할 수 있습니까? 여기에 문자열이 없으면 한 줄뿐입니까?

@oising이 제안한 것처럼 운영자로서-%를 선호합니다.

나를 위해 작동합니다.

하지만 질문 : 여기에 & call 연산자도 필요합니까?

--% & $computedPathToNativeExe foo;@workspace 한 괜찮습니다. 이것과 함께 호출 연산자를 사용할 수 있어야합니다.

현재는 할 수없는 일이기 때문에 모든 것을 그대로 네이티브 쉘에 전달해야한다고 말합니다.

동의합니다.

이 가정을 연산자의 (-%) 정의에 "네이티브 쉘이 여기에서하는 일을한다"로 성문화하는 것은 무리라고 생각하지 않습니다.

또한 동의했습니다!

또한 이것은 실행 파일의 세션에 대해서만 정의 된 실행 파일 앞에 env vars를 정의하는 기능을 가져 오는 방법 일 수 있습니다 (# 3316) :

--% JEKYLL_ENV=production jekyll build

그냥 생각.

@rkeithhill , call native operator 의 아이디어는 라인이 PowerShell에 의해 처리되지 않고 OS의 "기본 셸"에 그대로 전송된다는 것입니다. 따라서이 경우 첫 번째 예제 --% & $computerPathToNativeExe foo;@workspace 는 작동하지 않습니다. 현재 방법을 사용하고 적절하게 이스케이프해야합니다. 두 번째 경우 --% JEKYLL_ENV=productoin jekyll build 는 작동합니다.

이 라인은 PowerShell에 의해 처리되지 않고 그대로 OS의 "기본 셸"로 전송됩니다.

좋습니다. 그게 합리적입니다. 그러나이 --% JEKYLL_ENV=productoin jekyll build 은 Linux / macOS에서만 작동하지만 Windows에서는 작동하지 않습니다. 적어도 PowerShell의 도움 없이는 작동하지 않습니까?

@rkeithhill 은 현재 제안 된대로 OS "기본"셸에 의존하므로 Windows에서는 작동하지 않습니다. 프로세스에 대해 env var를 선언하는 PowerShell의 경우이를 논의하기 위해 다른 문제가 열렸습니다.

@ PowerShell / powershell-committee가 오늘이 문제를 논의했으며, 그 논의 결과를 반영하기 위해 원래 제안을 업데이트했습니다. 실험적인 기능 구현을 진행하고 작업 코드가있는 사용자로부터 더 많은 피드백을받을 것입니다. 우리는 여전히 운영자를 위해시길을 열고 있지만 지금은 --% 를 사용합니다.

여기서 $foo 는 리터럴 파일 이름이고 $PWD 는 WSL 내의 현재 디렉터리입니다. 첫 번째 예제에서 && 를 이스케이프해야 PowerShell이 ​​아닌 WSL 내에서 실행되도록 할 수 있습니다.

$foo 및 $PWD 모두 sh 평가할 변수 참조입니다.

이러한 실행의 출력을 다시 PowerShell로 파이프하려면 사용자는 먼저 결과를 변수에 저장해야합니다.

$out = --% ls *.txt
$out | select-string hello

현재 & 호출 연산자와 달리 PowerShell 구문을 사용할 수 없으므로 다음을 참고하세요.

--% $commandline

$commandline 문자 그대로 ( cmd ) 또는 쉘 확장 후 ( sh 아래) 실행하려고 시도합니다. PowerShell은 해당 변수를 확인하지 않습니다.

잘라 내기 및 붙여 넣기 문제는 &n 을 입력 한 후 붙여 넣기 만하면 해결됩니다.

--% 뒤에 붙여 넣기 만하면됩니다.

wsl 대한 위의 예는 다음과 같습니다.

어느 것?

--% 이후의 모든 인수가 "default"셸로 전달되므로 PowerShell 로의 파이프 라이닝을 지원하려면 다음과 같은 변수를 사용해야합니다.

이것은 반복입니다.

유용한 것을 추가하려면 피벗을 제안합니다.

왜 우리는 herestring Literal과 같은 것을 가질 수 없습니다.

@! ""! @

따라서 자체 문제가있는-% 대신이 작업을 수행하는 실제 방법을 사용할 수 있습니다.

그렇게하면 "더 나은"디자인 전략으로 문제를 해결할 수 있습니다.
그리고 이러한 엣지 케이스가 해결되어야하는 About_Strings에 위치 할 수 있습니다.

그냥 생각.

@!"…"!@ 이 Invoke-NativeShell @"…"@ 보다 더 나은 방법을 보지 못했습니다. PowerShell을 좀 더 Brainfuck처럼 만들려고 노력하고 있습니까?

뿡 빵뀨

@!"…"!@ 이 Invoke-NativeShell @"…"@ 보다 더 나은 방법을 보지 못했습니다. PowerShell을 좀 더 Brainfuck처럼 만들려고 노력하고 있습니까?

나는 @ romero126 이 한 줄의 herestring 리터럴을 제안

Invoke-NativeShell @!"complicated native command with "quotes" and | pipe"!@

대신에

Invoke-NativeShell @"
complicated native command with "quotes" and | pipe
"@

이러한 한 줄짜리 herestring을 고려할 경우 @"""…"""@ 및 @'''…'''@ 와 같은 구문을 사용하는 것이 좋습니다. IMO는 @!"…"!@ 보다 입력하기가 더 쉽습니다.

@ romero126 당신이 의미하는 바를 명확히 할 수 있습니까?

@ yecril71pl 오류를 잡아 주셔서 감사합니다.

--% 가 명령 줄 또는 배치 파일로 실행되는지 여부는 지정되지 않습니다.

나는 @ romero126 이 한 줄의 herestring 리터럴을 제안

Invoke-NativeShell @!"complicated native command with "quotes" and | pipe"!@

대신에

Invoke-NativeShell @"
complicated native command with "quotes" and | pipe
"@

이러한 한 줄의 herestring을 고려할 경우 @"""…"""@ 및 @'''…'''@ 와 같은 구문을 사용하는 것이 좋습니다. @!"…"!@ 보다 IMO 입력이 더 쉽습니다.

@ romero126 당신이 의미하는 바를 명확히 할 수 있습니까?

구문 분석되지 않은 "거의 원시"데이터를 처리하기 위해 Strings에 유연성을 추가하면이 팝업에 대한 문제가 발생하지 않을 것이라고 생각합니다.
@TSlivede 나는 당신이 말한 것에 거의 완전히 동의합니다. 약간의 차이 만 있습니다. 따옴표 안에 아무것도 삽입하지 않고 단일 행과 여러 행을 모두 처리 할 수 ​​있어야합니다. 우리가 그렇게하기 위해 어떤 구문을 사용하든 저는 열려 있습니다. 콘셉트에 더 집중하고 있습니다 ..

이 예제를 사용하면 문자열을 반환하기 때문에 "Invoke-NativeShell"이 필요없는 많은 유연성이 추가됩니다. 즉, 문자열처럼 자유롭게 조작 할 수 있습니다. 그래서 이것이 잠재적으로 멋진 모습의 스테이플이 될 수 있습니다.

이와 같은 피벗은 또한 우리가 엣지 케이스를 처리 할 수있을 때 거의 해결책으로 바퀴를 돌리는 문제를 처리 할 필요가 없다는 것을 의미합니다.

빠른 예 :

# For this scenario let @!"<text>"!@ be our HereString Verbatim

Invoke-NativeShell @!"complicated native command with "quotes" and | pipe"!@
# or
Invoke-NativeShell @!"
Complicated native command with "quotes" and pipe and <tabs>
"!@

#or 
$r = @!"
complicated native command with custom arguments: {0}
"!@ -format "foo"
Invoke-NativeShell $r

이 주석 의 두 번째 부분에서 @ mklement0이 다루는 문제는 다루지 않습니다. 문제의 사실은 우리가 모든 컴 랜드에게 단일 문자열을 전달할 수 없다는 것입니다. 많은 경우에 그들은 분리되어야합니다.

구문 분석되지 않은 "거의 원시"데이터를 처리하기 위해 Strings에 유연성을 추가하면이 팝업에 대한 문제가 발생하지 않을 것이라고 생각합니다.

이것이 ' 및 @' 의 목적입니다.

이 예제를 사용하면 문자열을 반환하기 때문에 "Invoke-NativeShell"이 필요없는 많은 유연성이 추가됩니다. 즉, 문자열처럼 자유롭게 조작 할 수 있습니다. 그래서 이것이 잠재적으로 멋진 모습의 스테이플이 될 수 있습니다.

기본 명령은 문자열 시퀀스를 반환합니다. @!" 은 이해할 수없는 것처럼 보이는 스테이플이 될 가능성이 있습니다.

구문 분석되지 않은 "거의 원시"데이터를 처리하기 위해 Strings에 유연성을 추가하면이 팝업에 대한 문제가 발생하지 않을 것이라고 생각합니다.

이것이 ' 및 @' 의 목적입니다.

이 예제를 사용하면 문자열을 반환하기 때문에 "Invoke-NativeShell"이 필요없는 많은 유연성이 추가됩니다. 즉, 문자열처럼 자유롭게 조작 할 수 있습니다. 그래서 이것이 잠재적으로 멋진 모습의 스테이플이 될 수 있습니다.

기본 명령은 문자열 시퀀스를 반환합니다. @!" 은 이해할 수없는 것처럼 보이는 스테이플이 될 가능성이 있습니다.

나는 당신이 혼란스러워하는 것 같아요. 내가 말한 요점으로.
작은 따옴표와 큰 따옴표는 $ variable 만 확장하거나 확장하지 않습니다. 문자를 자동으로 이스케이프하지 않습니다. 그것은 또한 저를 제한하여 더 이상 정의적인 성격을 사용할 수 없습니다. 그래서 대신에 지금처럼 제대로 작동합니다. 나는 여전히 &!를 포함해야하는 이유의 전체 요점 인 문자를 이스케이프해야합니다. 명령.

더 나은 해결책이 있다면 나는 모두 귀입니다. 나는 이것이 &를 추가하는 것보다 더 많은 경우에 맞다고 생각합니다!

작은 따옴표와 큰 따옴표는 $ variable 만 확장하거나 확장하지 않습니다. 문자를 자동으로 이스케이프하지 않습니다. 그것은 또한 저를 제한하여 더 이상 정의적인 성격을 사용할 수 없습니다. 그래서 대신에 지금처럼 제대로 작동합니다. 나는 여전히 &!를 포함해야하는 이유의 전체 요점 인 문자를 이스케이프해야합니다. 명령.

어떤 캐릭터를 탈출해야하며 그 이유는 무엇입니까?

@ romero126 이제 무슨 말을하는지 혼란 스럽습니다. powershell 에 here 문자열이 있다는 것을 알고 있습니까?

나는 이전에 여기에서 powershells의 구문이 성가신 문자열이라고 생각할 수 있다고 생각했지만 (적어도 때로는 처음과 끝 부분에 줄 바꿈이 있어야한다는 점에서 짜증이납니다 ...) 지금은 무엇인지 잘 모르겠습니다. 당신은 분명히 말할 수 있습니까?

@TSlivede , 여기 문자열이 구문 적으로 다소 번거 롭다는 데 동의했습니다.

개선을 제안하는 기존 제안 # 2337이 있으며 닫는 구분 기호를 들여 쓰는 데 초점을 맞추고 있지만 @lzybkr 은 https : // github 에서 Rust와 유사한 _single-line _ (-also) 변형을 제안합니다

# `ins` is `Invoke-NativeShell`
ins @' python -c 'print("hi")' | cat -n '@

필요에 따라 _multiple_ ' 와 @ 를 결합하여 이스케이프 처리를 피할 수 있습니다 (예 : @'' can use @' here ''@ .

즉, 이것은 PowerShell 문자열 리터럴에 대한 일반적인 개선 사항이며 모든 곳에서 사용할 수 있으며 Invoke-NativeShell 에서도 이점을 얻을 수 있습니다.

# 2337이 주로 다른 것에 초점을 맞추고 있다는 점을 감안할 때 # 13204에서 초점을 맞춘 제안을 작성했으며 거기서 대화를 계속할 것을 제안합니다.

탈출의 필요성을 피할 수 있습니다.

이 스레드에서 이것을 몇 번 봤습니다.

새 모드를 시작하기 위해 토크 나이저에 대한 모든 인디케이터에는 이스케이프 메커니즘이 필요합니다. 해당 모드를 떠나는 토크 나이저에 대한 인디케이터를 해당 문자의 문자 형식과 구별해야하기 때문입니다.

오늘날 가장 자연스러운 형태는 작은 따옴표로 묶인 문자열입니다.

• ' : 작은 따옴표 토큰 화 시작
• ' : 작은 따옴표 토큰 화 종료
• '' : 작은 따옴표로 묶인 문자열 내에 리터럴 작은 따옴표를 작성합니다.

이에도 불구하고 탈출에 대해 이야기하는 이유는 다음과 같습니다.

• --% 연산자는 모드를 종료하는 너무 많은 방법을 정의하고 ( | , && , || , ; , 줄 바꿈) 문자열을 허용합니다. 그 안에 ( ' 문자 제거)
• Herestrings 및 co는 배열이 아닌 하나의 문자열 인수로 해석됩니다.

실행 가능한 호출에 인수를 전달하려는 것은 실제로 배열 구문에 대해 이야기하고 있음을 의미합니다.

• 어레이를 시작하는 방법 (완전히 모드 시작)
• 배열을 분리하는 방법 (단일 인수를 새 실행 파일에 전달)
• 어레이 종료 방법 (완전 모드 종료)

(이것은 * nix의 기본 개념입니다. exec 는 배열을 예상하기 때문입니다. Windows에서는 배열을 가져 와서 특정 문자열 구문으로 직렬화하고 CommandLineToArgvW 통해 전달해야한다고 생각합니다.

즉, 두 개의 이스케이프가 필요합니다.

• 배열 구분자 리터럴
• 배열 끝 리터럴

예를 들면 다음과 같습니다.

• --% 명령이 새 축어 구문이되기 전
• 구문을 어떻게 끝낼까요? 개행 및 ; 아마도?
• 논쟁을 어떻게 분리합니까? 아마도?

질문은 다음과 같습니다.

• ; 또는 개행 문자를 어떻게 전달합니까?
• 리터럴을 어떻게 전달합니까?

기본 명령 줄은 배열이 아닙니다. 문자열 또는 AST입니다. PowerShell은 네이티브 셸의 AST에 대해 아무것도 모르기 때문에 문자열 만 남습니다.

기본 명령 줄은 배열이 아닙니다. 문자열 또는 AST입니다.

이 주장에 대한 근거를 제공하지 않았습니다.

다음은 PowerShell이 ​​명령에 대한 AST를 빌드하는 위치입니다 (명령이 어떤 종류의 명령인지 확인할 때 런타임까지 알 수 없기 때문에 모든 종류의).

https://github.com/PowerShell/PowerShell/blob/f82f74d89811e91613a7450e536d652c5d8f784e/src/System.Management.Automation/engine/parser/Parser.cs#L6391 -L6634

명령 요소 (매개 변수 및 인수 포함)가 배열에 추가됩니다.

다음과 같이 PowerShell에서 작동하는 것을 볼 수 있습니다.

> { ping 192.168.0.1 }.Ast.EndBlock.Statements[0].PipelineElements[0].CommandElements

StringConstantType : BareWord
Value              : ping
StaticType         : System.String
Extent             : ping
Parent             : ping 192.168.0.1

StringConstantType : BareWord
Value              : 192.168.0.1
StaticType         : System.String
Extent             : 192.168.0.1
Parent             : ping 192.168.0.1

이 배열은 여기에서 표현식으로 컴파일됩니다.

https://github.com/PowerShell/PowerShell/blob/f82f74d89811e91613a7450e536d652c5d8f784e/src/System.Management.Automation/engine/parser/Compiler.cs#L4127 -L4160

그런 다음 여기에서 파이프 라인 호출로 전달됩니다 ( Expression.NewArrayInit(typeof(CommandParameterInternal[]), pipelineExprs) 는 인수가 전달되는 위치입니다).

https://github.com/PowerShell/PowerShell/blob/f82f74d89811e91613a7450e536d652c5d8f784e/src/System.Management.Automation/engine/parser/Compiler.cs#L3798 -L3805

런타임에 컴파일 된 표현식이 실행되면 이 메서드 호출이 되며, 사용할 명령 프로세서를 결정하는 다음 호출로 전달됩니다.

https://github.com/PowerShell/PowerShell/blob/f82f74d89811e91613a7450e536d652c5d8f784e/src/System.Management.Automation/engine/runtime/Operations/MiscOps.cs#L29 -L312

결국 파이프 라인이 호출되면 해당 인수 배열은 NativeCommandParameterBinder 사용하여 기본 명령에 바인딩됩니다.

https://github.com/PowerShell/PowerShell/blob/f82f74d89811e91613a7450e536d652c5d8f784e/src/System.Management.Automation/engine/NativeCommandParameterBinder.cs#L69 -L137

각 인수에 어떤 종류의 문자열이 사용되었는지와 같은 AST 메타 데이터를 포함하는 인수 배열을 가져 와서 NativeCommandProcessor 에서 인수 호출을위한 새 문자열을 만듭니다.

https://github.com/PowerShell/PowerShell/blob/f82f74d89811e91613a7450e536d652c5d8f784e/src/System.Management.Automation/engine/NativeCommandProcessor.cs#L1094 -L1166

이는 현재 프로세스 호출에 사용하는 .NET API가 배열을 전달하고 .NET이 호출을 다시 빌드 할 수 있도록하는 .NET Core의 새로운 버전이 아니라 이전 "단일 문자열의 모든 인수"버전이기 때문에 수행됩니다. 플랫폼 특정 방식으로 필요에 따라.

하지만이 API를 사용하는 것은 구현 세부 사항입니다. 예를 들어 다음과 같이 * nix에서 직접 fork / exec 호출 할 수 있습니다.

https://github.com/PowerShell/PowerShell/blob/f82f74d89811e91613a7450e536d652c5d8f784e/src/powershell/Program.cs#L268 -L330

여기서 exec 는 배열을 사용합니다. syscall에 인수를 전달하는 가장 간단하고 직접적인 방법이며 이는 궁극적으로 축 어적 인수 구문의 목표이기 때문입니다.

@rjmholt :

_ 기능적으로 _ 모든 요구 사항은 이미 기존 문자열 리터럴 형식으로 처리됩니다. _ 네이티브 명령 줄을 단일 문자열로 전달하는 경우 _ 새로운 Invoke-NativeShell / ins cmdlet을 통해 강력하게 권장합니다.

여기서 시작점은 배열이 아니라 _ ​​단일 문자열 _입니다. _ 전체 명령 줄 _-대상 셸에 의해 구문 분석 됨 _- 그리고이를 PowerShell에 반영하는 것이 가장 합리적입니다. --% 와 같은 다른 쉘의 구문을 PowerShell에

Invoke-NativeShell 가해야 할 일은 전체 네이티브 셸 명령 줄이 포함 된 단일 문자열을 CLI를 통해 네이티브 셸에 전달하는 것입니다.

• Unix 에서 이것은 다음을 의미합니다. exec 전달 된 인수 _array_의 두 번째 요소로 문자열을있는 그대로 전달하고 _as whole_을 전달합니다 ( -c 가 첫 번째 인수 배열 요소이고 /bin/sh 실행 파일); 간단한 예를 사용하여 .NET 용어로 표현됩니다. 여기서 printf "'%s'" foo | cat -n 는 전달할 명령 줄을 포함하는 단일 문자열의 축 어적 내용입니다 ( .Arguments 아니라 .ArgumentList 사용에 유의하십시오 .Arguments ; ' 의 두 배는이 예제의 아티팩트입니다.)

  • $psi = [Diagnostics.ProcessStartInfo]::new('/bin/sh'); $psi.ArgumentList.Add('-c'); $psi.ArgumentList.Add('printf "''%s''" foo | cat -n'); [Diagnostics.Process]::start($psi).WaitForExit()

• Windows에서,이 수단은 : 수용 cmd 의 단점을 채우기 lpCommandLine 의 인수 CreateProcess 함께 (이하 lpApplicationName 의 값으로 가정 cmd.exe 를 가리키는 환경 변수 ComSpec ) : "/c " + cmdLine , 여기서 cmdLine 는 전체 명령 줄 문자열 그대로입니다. 간단한 예와 함께 .NET 용어로 표현됩니다. 여기서 echo a^&b & ver 는 통과 할 명령 줄이 포함 된 단일 문자열의 축 어적 내용입니다.

  • $psi = [Diagnostics.ProcessStartInfo]::new($env:ComSpec); $psi.Arguments = '/c ' + 'echo a^&b & ver'; [Diagnostics.Process]::start($psi).WaitForExit()
    
    
    
    • @ yecril71pl , 이것은 명령 프롬프트 또는 배치 파일 의미 체계를 사용할지 여부에 대한 질문에 대한 답변을 의미합니다. os.system() 사용하는 Python과 같은 다른 스크립팅 언어에서도 사용되는 전자입니다. (아마도 안타깝게도) 의미는 % 문자를 이스케이프 할 수없고 for 루프 변수는 단일 % (예 : %i 사용해야한다는 것입니다. %%i %i 대신 %%i ); 루프 본문 명령 앞에 @ 를 붙여서 에코되지 않도록해야합니다 (예 : for %i in (*.txt) do <strong i="56">@echo</strong> %i ).
    
    

이 프로세스는 _ 최종 사용자에게 _ 투명합니다 _, 그래서 그들이 집중해야 할 것은 _PowerShell's_ string-literal 구문 요구 사항을 충족시키기 만하면 네이티브 셸 명령 줄 _verbatim_을 전달하는 것입니다.

ins @'<newline>...<newline>'@ 형식을 사용하면 이미 네이티브 셸 명령 줄을 그대로 _ 사용할 수 있습니다. 기존의 다양한 문자열 리터럴 형식을 사용할 수있는 방법은 위 의 _interpolating_의 가용성으로 인해 여기를 참조하세요. 문자열 형식 ( @"<newline>...<newline>"@ )-명령 줄에서 _PowerShell_ 변수 및 식을 사용할 수있는 기능이 포함됩니다 (이렇게 할 수없는 것은 --% 의 주요 단점 중 하나입니다).

내 이전 의견이 제안한 것은 _이 제안과는 분리 된 _ 새로운 일반 형태의 원시 문자열 리터럴 _입니다 (그리고 구문 분석 논리는 잘 정의되어 있습니다). 그러나 언급했듯이 Invoke-NativeShell 통화는 _ 더 편리합니다 _.

이미 할 수있는 것 대신 ( Invoke-NativeShell / ins 명령 가정) :

# ALREADY WORKS: Literal here-string
ins @'
python -c 'print("hi")' | cat -n
'@

제안 된 새로운 단일 행 원시 리터럴을 사용하면 다음과 같이 단순화 할 수 있습니다.

# PROPOSED, more convenient syntax: new raw literal.
ins @' python -c 'print("hi")' | cat -n '@

이 새로운 원시 문자열 리터럴 구문의 세부 사항에 대해 토론이 필요하면 여기가 아니라 # 13204에서 수행하도록하겠습니다.

그래서 원래 의도를 이해하기 위해 제안을 다시 읽으면 실제로 /bin/sh -c '<command>' + cmd 버전에 대한 더 나은 구문과 각 대상 셸에 대한 특수 문자열 이스케이프 논리를 요청하는 것입니다. 나는 특별한 구문과 파서 및 네이티브 명령 프로세서로 작업해야하는 초기 개념을 기반으로했습니다. .NET의 ProcessStartInfo.Arguments 속성 은 따옴표 전달 측면에서 올바르게 사용하기 가

그러나 실제로 Arguments 문자열은 그대로 전달됩니다 . 따라서 우리가해야 할 일은 이러한 문자열을 직접 전달하는 것입니다.

이 경우 새로운 구문이 전혀 필요하지 않다고 생각합니다 (토큰 화 논리를 복잡하게하고 사람들을 혼란스럽게하는 것 같습니다). 대신 이것은 단지 새로운 명령 인 ins 입니다. .NET에는 여기 에 우리가 강제로 다시 구현해야하는 몇 가지 논리가 있지만 어쨌든 조금 더 똑똑해야하므로 괜찮습니다.

@rjmholt 의 의견에 대한 일부 의견 https://github.com/PowerShell/PowerShell/issues/13068#issuecomment -660231641

새 모드를 시작하기 위해 토크 나이저에 대한 모든 인디케이터에는 이스케이프 메커니즘이 필요합니다. 해당 모드를 떠나는 토크 나이저에 대한 인디케이터를 해당 문자의 문자 형식과 구별해야하기 때문입니다.

나는 동의하며 여기에 인라인 문자열 구문이 탈출의 필요성을 완전히 피할 수 있다고 생각하지 않습니다.

-% 연산자는 모드 (|, &&, ||,;, 개행)를 종료하는 너무 많은 방법을 정의하고 그 안에 문자열을 허용합니다 ( '문자 제거).

--% 에 대해 말할 때 기존 --% 스위치를 언급하십니까? 그렇다면 지금 --% 가 콜 오퍼레이터로 제안되었으므로 귀하의 의견에서이를 명확히하는 것이 좋습니다.

실행 가능한 호출에 인수를 전달하려는 것은 실제로 배열 구문에 대해 이야기하고 있음을 의미합니다.

제안은 기본 쉘 (sh 또는 cmd를) 호출하고 호출 연산자 후 문자 그대로 모든 것을 전달하는 것입니다 --% 처럼 sh -c ... . 따라서 대상 실행 파일에 인수를 전달하는 것은 powershell이 ​​아닙니다. 이 경우 _ 배열 구문 _이 필요하지 않다고 생각합니다. 맞죠?

구문을 어떻게 끝낼까요? 개행 및; 아마도?
논쟁을 어떻게 분리합니까? '공간'일까요?

축 어적 구문 분석은 개행으로 끝납니다. 인수의 일부로 새 줄을 전달하려면 bash에서 직접 수행하는 것과 마찬가지로 \n 를 사용하십시오.

기본 명령 줄은 배열이 아닙니다. 문자열 또는 AST입니다.

이 주장에 대한 근거를 제공하지 않았습니다.

다음은 PowerShell이 ​​명령에 대한 AST를 빌드하는 위치입니다 (명령이 어떤 종류의 명령인지 확인할 때 런타임까지 알 수 없기 때문에 모든 종류의).

이 제안이 구현되면 PowerShell이 ​​AST를 전혀 빌드하지 않는 특수 구조가 도입됩니다.

기뻐요, @rjmholt.

.NET에는 여기에 대한 몇 가지 논리가 있으며이를 다시 구현해야합니다.

이전 주석의 명령이 보여 주듯이 실제로는 아무것도 다시 구현할 필요가 없다고 생각합니다. Windows에서는 WinAPI에 대한 전체 명령 줄 문자열 통과에 .Arguments 를 사용합니다. Unix에서는 .ArgumentList 를 사용하여 exec 와 직접 사용되는 _array_ 인수를 생성합니다.

이 제안이 구현되면 PowerShell이 ​​AST를 전혀 빌드하지 않는 특수 구조가 도입됩니다.

이 목적을 위해 설계된 다른 AST 유형을 빌드합니다. AST의 일부가 아닌 경우 기본적으로 주석과 동일하며 아무 일도 일어나지 않습니다.

_ 기능적으로 _ 모든 요구 사항은 이미 기존 문자열 리터럴 형식으로 처리됩니다. _ 네이티브 명령 줄을 단일 문자열로 전달하는 경우 _ 새로운 Invoke-NativeShell / ins cmdlet을 통해 강력하게 권장합니다.

개인적으로 Invoke-NativeShell cmdlet 아이디어가 마음에 듭니다. 어떤면에서는 호출 연산자 --% 보다 낫습니다. 내가이 아이디어에 대해 들었던 주요 관심사는 --% + Ctrl + v 보다 타이핑이 더 많고 here-string을 보간하는 것과 구별하는 것이 사용자에게 또 다른 부담이라는 것입니다 (_ 개인적으로 ins 라고 생각합니다) --% _)보다 입력하기가 훨씬 쉽습니다.

내가이 아이디어에 대해 들었던 주요 관심사는 --% + Ctrl + v보다 타이핑이 더 많고 here-string과 here-string을 보간하는 것을 구별하는 것이 사용자에게 또 다른 부담이라는 것입니다 (_ 개인적으로 ins --% _)보다 입력하기가 훨씬 쉽습니다.

PSRL이 도움이 될 수 있습니다. 붙여 넣은 경로를 둘러싸는 키 처리기에 대한 문제와 유사하게 PSRL은 CommandAst 읽고 ins 읽고 붙여 넣은 문자열을 제대로 이스케이프 할 수 있습니다.

이 목적을 위해 설계된 다른 AST 유형을 빌드합니다. AST의 일부가 아닌 경우 기본적으로 주석과 동일하며 아무 일도 일어나지 않습니다.

물론, 나무는 사소 할 것입니다. 실행될 명령의 의미를 반영하지 않습니다.

시작 프로세스 cmd.exe 리디렉션 stdin / stdio 및 문자 그대로 문자열을 사용하여 bash와 동일한 NativeCommand를 호출 할 수 있습니다.

다행 이네요, @ daxian-dbw.
@SeeminglyScience 아이디어를

리터럴 here-string과 here-string을 보간하는 것은 사용자에게 또 다른 부담입니다.

--% 와 달리 @"<newline>...<newline>"@ 사용하면 _PowerShell_ 변수 및 표현식의 값을 기본 명령 줄에 직접 통합 할 수 있기 때문에 _plus_라고 생각합니다.

물론 사용자가 작은 따옴표 (verbatim)와 큰 따옴표 (보간) 문자열의 차이점과 $ 선택적 ` 이스케이프에 대해 알고 있다고 가정하지만 중요하다고 생각합니다. (고급) 옵션이 있습니다.

잘라 내기 및 붙여 넣기 사용자를 돕기 위해 제안 된 PSReadLine 기능은 기본적으로 @'<newline>...<newline>'@ (verbatim)으로 설정되어야합니다.

궁극적으로 우리는 사용자가 PowerShell의 고유 한 구문 요구 사항을 알고 이해할 필요가없는 사고 방식을 장려하고 싶지 않습니다. 대신 _ 그들이 가져 오는 힘을 고려하여 이해를 촉진하고자합니다.

하지만 사용자가 PowerShell의 _own_ 구문 (정의상 _cross-platform_)을 사용하도록 장려하려면 예상대로 작동해야합니다 .
이를 위해서는 # 1995를 수정해야합니다 . 이상적으로는 직접적으로 변경을 허용하거나 옵션이 아닌 경우 최소 의식 _opt-in_을 통해 수정해야합니다.

요약:

• --% (여기에서 제안 된 새로운 연산자 형식)와 같은 것, 정의상 _platform-specific_ 기능은 # 1995 수정을 대체 할 수 없습니다 .

• Invoke-NativeShell ( ins )는 제안 된 --% 연산자의 모든 제한을 피하고 @joeyaiello가 언급 한 "트랩 도어"솔루션을 제공합니다. 작성된 명령 줄을 실행하는 빠른 방법 PowerShell의 구문에 적용 할 필요없이 네이티브 셸의 경우

• --% 은 원래 _argument_ 형식으로 만 유지되어야하며 _Windows 전용 _ 기능으로 유지되어야합니다 (기술적으로는 아니지만 _ 효과적으로 _). 즉, 변경할 필요가 없습니다.

  • # 1995가 수정되면 --% 의 유일한 목적은 Windows_에서 _edge 케이스를 수용하는 것입니다 : 필요한 msiexec 와 같은 악성 프로그램에 전달 된 명령 줄의 명시 적 인용을 제어 할 수 있습니다. 매우 구체적인 형태의 인수 내 인용.

PS v7.x에서 제가 정말로 원하는 다른 기능 중 하나는이 RFC 에서 논의 된 것처럼 set -e 와 같이 내 스크립트를 중지하는 오류 코드와 함께 기본 명령을 종료하는 기능입니다. 그에 대한 해결책이 같은 경우 Invoke-NativeCommand , 그 리스팅와 혼동 것 Invoke-NativeShell ?

내가 네이티브 기능 호출을 원하는만큼 msbuild, cl, cmake, Conan, npm 등을 호출 할 때 빌드 및 테스트 스크립트가 오류가 발생하고 이러한 기본 명령이 종료되기를 원하기 때문에 영화를 조금 앞으로 재생하려고합니다. 항상 $ LASTEXITCODE를 확인하는 것을 기억할 필요없이 0이 아닌 종료 코드. 구현이 $PSNativeCommandInErrorActionPreference 같은 다른 환경 설정 변수를 통해 이루어 졌다면 이것이 네이티브 쉘의 호출에 영향을 미칠 것이라고 생각합니다-네이티브 "명령"과 모든 것입니까?

내가이 아이디어에 대해 들었던 주요 관심사는 --% + Ctrl + v보다 타이핑이 더 많고 here-string과 here-string을 보간하는 것을 구별하는 것이 사용자에게 또 다른 부담이라는 것입니다 (_ 개인적으로 ins --% _)보다 입력하기가 훨씬 쉽습니다.

PSRL이 도움이 될 수 있습니다. 붙여 넣은 경로를 둘러싸는 키 처리기에 대한 문제와 유사하게 PSRL은 CommandAst 읽고 ins 읽고 붙여 넣은 문자열을 제대로 이스케이프 할 수 있습니다.

하지만 어떨까요?

$c = gcm ins
& $c ...

PSRL은 거기에서 무슨 일이 일어나고 있는지 인식하는 데 어려움을 겪을 것입니다. stateful이어야하고 invoke-nativeshell에 대한 별칭을 확인한 다음 commandinfo를 호출 할 것인지 파악한 다음 args를 제거해야합니까? 가짜 명령을 특수 케이스로 사용한다는 생각이 정말 싫습니다.

리터럴 here-string과 here-string을 보간하는 것은 사용자에게 또 다른 부담입니다.

--% 와 달리 @"<newline>...<newline>"@ 사용하면 _PowerShell_ 변수 및 표현식의 값을 기본 명령 줄에 직접 통합 할 수 있기 때문에 _plus_라고 생각합니다.

@ mklement0을 팔로우하지 않습니다. 왜 --% 에게 이것을 가르치지 못합니까? 나는 이미 이것을 유스 케이스로 제공했습니다.

가짜 명령을 특수 케이스로 사용한다는 생각이 정말 싫습니다.

여기에는 가짜 명령이 없으며 진정한 cmdlet 인 Invoke-NativeShell ins 별칭으로 지정됩니다.

gcm ins ( Get-Command ins )는 ins 별칭에 대한 정보를 [System.Management.Automation.AliasInfo] 인스턴스 형식으로 제공하며 나중에 & 전달할 수 있습니다 & 입니다.

따라서 예제는 의도 한대로 정확하게 작동합니다. gcm ( Get-Command ) 우회를 사용하는 경우 적절한 문자열 리터럴 구문 _yourself_를 입력해야합니다. @SeeminglyScience의 제안이 구현 된 경우 PSRL _could_가 제공하는 _ 옵션 편의 명령 스캐 폴딩 _ :

$c = gcm ins
& $c @'
python -c 'print("hi")' | cat -n
'@

또는 # 13204에서 제안한 새로운 원시 문자열 리터럴 구문이 구현 된 경우 :

$c = gcm ins
& $c @' python -c 'print("hi")' | cat -n '@

물론 PowerShell의 문자열 리터럴 구문에 익숙하다면 일반 작은 따옴표 문자열도 사용할 수 있습니다. 전체 '...' 문자열에 포함 된 ' 를 두 배로 늘리면됩니다.

$c = gcm ins
& $c 'python -c ''print("hi")'' | cat -n'

왜 --% 에게 이것을 가르치지 못합니까?

• --% 에는 닫는 구분 기호가 없어서 Powershell 파이프 라인에서 사용할 수 없습니다. 이는 허용되지 않는 제한입니다 ( (...) 엔클로저는 모든 출력의 선행 수집을 의미하므로 옵션이 _not_입니다. _streaming_ 처리가 아닌 메모리의 라인).

• Unix에서 --% 은 _both_ 지원 (이스케이프 처리되지 않음) $ 를 PowerShell 메타 문자로 _and_ POSIX- 셸 메타 문자로 지원할 수 없습니다.

다시 말하지만, _ 다른 셸의 구문 _을 PowerShell에 _no_ 정당화 할 수 있지만 이점이 없습니다. 네이티브 셸 명령 줄을 _ 문자열 _로 ins 하면 모든 개념적 문제가 사라집니다.

Invoke-NativeShell은 PowerShell이 ​​기본 셸이 아님을 의미합니다. 그 가정은 항상 정확하고 항상 그래야 하는가?

@oising 유스 케이스는 누군가가 README 또는 다른 것에서 기본 명령을 복사하여 붙여 넣는 것입니다. ins SPACE CTRL + v 를 입력하는 것보다 더 복잡한 작업을 수행하는 경우 평소처럼 자신의 문자열을 빌드하고 이스케이프합니다.

뿡 빵뀨

하지만 사용자가 PowerShell의 _own_ 구문 (정의상 _cross-platform_)을 사용하도록 장려하려면 예상대로 작동해야합니다 .
이를 위해서는 # 1995를 수정해야합니다 . 이상적으로는 직접적으로 변경을 허용하거나 옵션이 아닌 경우 최소 의식 _opt-in_을 통해 수정해야합니다.

이것은 ins / --% 에 대한 토론과는 별개입니다. 동의하지 않는 경우 해당 문제가 새 명령 / 구문에 영향을 미치는 이유를 명확히 할 수 있습니까?

@SeeminglyScience , 예, 그것은 별개이지만이 스레드에서는 명확하지 않습니다.
# 1995가 여기에 나온 유일한 이유는이 문제를 위해 원래 닫 혔기 때문이며 (다행히 다시 열렸지만) 여기 OP는 여전히이 문제가 해결 될 것이라고 말합니다 ( "이 문제도 해결되어야합니다 :"). .
따라서 ins / --% 은 (는) # 1995 주소가 _not_되며, 이는 긴급하게 자체 수정이 필요하다는 점을 강조하고 싶었습니다.
(PowerShell의 자체 인수 전달이 제대로 작동하는 경우에만 양심적으로 사용자가 PowerShell의 자체 구문을 완전히 배우고 수용 할 것을 권장 할 수 있습니다.

@ SP3269 , 우리가 도달하면 그 다리를 건널 수 있습니다 😁.

하지만 진지하게 :

"네이티브"를 "호스트 플랫폼 [패밀리] 용으로 특별히 작성 됨"으로 생각하면 PowerShell이 ​​주어진 플랫폼에서 기본 시스템 셸이되어야하더라도 이름은 여전히 ​​적합 할 것입니다 (원하는 바가 있지만 생각하지 않습니다). 적어도 가까운 미래에는 현실적이지 않습니다.)

대안 :

• Invoke-[System]DefaultShell 가 가장 정확한 이름이지만 (PowerShell이 ​​시스템의 기본 셸이되는 경우 더 이상 적용되지 않지만) PowerShell 세계에서 "네이티브"가 더 일반적으로 사용되는 용어 인 것 같습니다.

• Invoke-LegacyShell 은 Windows에서 약간의 타당성을 가지고 있지만 Unix 사용자는이 용어를 너무 친절하게 받아들이지 않을 것입니다.

나는 여기에서 모든 사람의 동기, 아이디어 및 문제를 추적하려고 시도하고있는 완전한 혼란을 풀기 시작했다고 생각합니다. 우리는 ( @ mklement0 과 나는 적어도) 이것을 동일한 개념적 문제에 대한 두 가지 다른 견해에 대한 두 가지 다른 해결책으로보고있는 것 같습니다. 내가 제안한 것은 _parser_에 대한 힌트로 --% 를 사용하여 호출 & 연산자와 함께 파싱되는 방식을 변경하는 것입니다 (반드시 --% 독립형을 사용하지 않음). 반면에 Michael은 ins 를 powershell의 자체 내부 네이티브 명령 브로커 및 인수 파서를 대체하는 드롭 인 cmdlet으로보고있는 것으로 보이며 대신 strings / here를 사용하여 powershell의 파서를 변경하려고하지 않습니다. -의도 된 매개 변수를 캡처하기위한 문자열 ( --% 과 함께 사용할 수도 있음)

-%에는 닫는 구분 기호가 없어 Powershell 파이프 라인에서 사용할 수 없습니다.

이 점은 전혀 이해하지 못합니다. ins / invoke-nativecommand보다 닫는 구분 기호가 더 이상 부족하지 않습니다. LHS에서 구분하거나 공급해야하는 경우 here-strings를 사용하십시오. 그렇지 않으면 단일 명령문으로 간주됩니다.

어떤 방법을 선택하든 명령 줄을 전달하기 위해 네이티브 셸을 선택해야하는 것 같습니다. Windows에서는 환경 변수 COMSPEC (기본값은 %systemroot%\system32\cmd.exe ), Linux에서는 SHELL (기본값은 /bin/bash )를 사용하는 것이 좋습니다 %systemroot%\system32\cmd.exe SHELL이 사용하지 않는 경우 존재하는 경우 /bin/sh 대상으로해야합니다 (대부분의 경우 bash에 대한 심볼릭 링크).

-%에는 닫는 구분 기호가 없어 Powershell 파이프 라인에서 사용할 수 없습니다.

이 점은 전혀 이해하지 못합니다. ins / invoke-nativecommand보다 닫는 구분 기호가 더 이상 부족하지 않습니다. LHS에서 구분하거나 공급해야하는 경우 here-strings를 사용하십시오. 그렇지 않으면 단일 명령문으로 간주됩니다.

기본적으로 cmd --% /c someapp | someOtherApp 같은 것을 호출 할 수없고 cmd가 파이프 라인을 처리하도록 할 수 없습니다. PowerShell은 여전히 ​​파이프 라인 (그리고 Unix 사용자에게 유용 할 && 및 || && 과 같은 몇 가지 다른 것)을 기본 명령에 전달하는 대신 PowerShell 토큰으로 해석합니다. 인수 문자열.

Linux의 SHELL (기본값은 /bin/bash )

아니요 : Unix 계열 플랫폼의 _system_ 셸은 _invariably_ /bin/sh 입니다.
이것은 주어진 _user's_ 대화 형 셸 ( $env:SHELL 반영됨-그러나 안타깝게도 현재 _PowerShell_이 사용자의 셸인 경우 # 12150 참조)과는 다릅니다. 이는 (a) 구성 가능하고 (b) 자주 사용됩니다. _defaults to_ /bin/bash ,하지만 macOS가 최근에 새로운 사용자를위한 기본 대화 형 셸로 /bin/zsh 로 전환 한 것으로 입증 되었 듯이 그것은 주어진 것이 아닙니다.

Windows에서 환경 변수 COMSPEC 를 사용하는 것이 좋습니다.

좋은 점은 Windows에서 시스템 셸 (명령 인터프리터)을 참조하는 더 좋은 방법입니다. 그에 따라 위 의 샘플 명령을 업데이트했습니다.

PS v7.x에서 제가 정말로 원하는 다른 기능 중 하나는이 RFC 에서 논의 된 것처럼 set -e 와 같이 내 스크립트를 중지하는 오류 코드와 함께 기본 명령을 종료하는 기능입니다. 그에 대한 해결책이 같은 경우 Invoke-NativeCommand , 그 리스팅와 혼동 것 Invoke-NativeShell ?

내가 네이티브 기능 호출을 원하는만큼 msbuild, cl, cmake, Conan, npm 등을 호출 할 때 빌드 및 테스트 스크립트가 오류가 발생하고 이러한 기본 명령이 종료되기를 원하기 때문에 영화를 조금 앞으로 재생하려고합니다. 항상 $ LASTEXITCODE를 확인하는 것을 기억할 필요없이 0이 아닌 종료 코드. 구현이 $PSNativeCommandInErrorActionPreference 같은 다른 환경 설정 변수를 통해 이루어 졌다면 이것이 네이티브 쉘의 호출에 영향을 미칠 것이라고 생각합니다-네이티브 "명령"과 모든 것입니까?

이를 Start-NativeExecution build 모듈에 Start-NativeExecution 이 있습니다.

나는 그것을 보았다. 나중에 0이 아닌 종료 코드를 효과적으로 처리하려면 Start-NativeExecution 와 Invoke-NativeShell 정확히 어떻게 결합해야합니까? PR # 3523과 같은 것이이 통화 기본 기능과 함께 작동하기를 정말 바랍니다. 두 사람이 함께 작동하기를 원하기 때문입니다. 호출 네이티브가 cmdlet (Invoke-NativeShell 대-%)으로 구현되는 경우 -ErrorAction Stop 구현하여 0이 아닌 종료 코드에서 발생 (종료 오류) 할 수 있다고 가정합니다.

-%에는 닫는 구분 기호가 없어 Powershell 파이프 라인에서 사용할 수 없습니다.

이 점은 전혀 이해하지 못합니다. ins / invoke-nativecommand보다 닫는 구분 기호가 더 이상 부족하지 않습니다. LHS에서 구분하거나 공급해야하는 경우 here-strings를 사용하십시오. 그렇지 않으면 단일 명령문으로 간주됩니다.

기본적으로 cmd --% /c someapp | someOtherApp 같은 것을 호출 할 수없고 cmd가 파이프 라인을 처리하도록 할 수 없습니다. PowerShell은 여전히 ​​파이프 라인 (그리고 Unix 사용자에게 유용 할 && 및 || && 과 같은 몇 가지 다른 것)을 기본 명령에 전달하는 대신 PowerShell 토큰으로 해석합니다. 인수 문자열.

예, 현재 동작 @ vexx32를 이해합니다. 그러나 우리는 --% 의 현재 행동에 대해 이야기하고 있지 않습니다 (적어도 저는 아닙니다). 우리는 그것을 향상시키는 것에 대해 이야기하고 있습니다. 우리가 여기서 서로 이야기하고 있다는 느낌이 드는 이유는 무엇입니까? :)

위에서 말했듯이, --% 와 함께 작동하도록 & 을 향상시킬 수 있으므로 이것이 가능합니다 . 또한 암시 적 네이티브 exec 대 인수가있는 셸의 명시 적 호출에 대해 명확히해야한다고 생각합니다. 이것은 노련한 Windows 사용자에게도 다른 실행 파일을 "실행"하려면 어떻게 든 cmd.exe (쉘)가 필요하다는 지속적인 혼란의 원인입니다. linux / osx에도 동일하게 적용됩니다.

예, _current_ 동작 @ vexx32를 이해합니다. 그러나 우리는 --% 의 _current_ 행동에 대해 이야기하고 있지 않습니다 (적어도 저는 아닙니다)-우리는 그것을 향상시키는 것에 대해 이야기하고 있습니다. 우리가 여기서 서로 이야기하고 있다는 느낌이 드는 이유는 무엇입니까? :)

따라서 --% 조정에 대한 현재 피치는 명령 이름이 일반적으로있는 경우 오른쪽에있는 모든 항목이있는 그대로 (새 줄까지) 구문 분석 --% 및 기본 명령 프로세서가 현재 가지고있는 것과 동일한 문제가 있기 때문입니다.

나는 그것을 보았다. 나중에 0이 아닌 종료 코드를 효과적으로 처리하려면 Start-NativeExecution 와 Invoke-NativeShell 정확히 어떻게 결합해야합니까? PR # 3523과 같은 것이이 통화 기본 기능과 함께 작동하기를 정말 바랍니다. 두 사람이 함께 작동하기를 원하기 때문입니다. 호출 네이티브가 cmdlet (Invoke-NativeShell 대-%)으로 구현되는 경우 -ErrorAction Stop 구현하여 0이 아닌 종료 코드에서 발생 (종료 오류) 할 수 있다고 가정합니다.

현재 Start-NativeExecution { Invoke-NativeShell <strong i="10">@whatever</strong> } 입니다.

이 점은 전혀 이해하지 못합니다. ins / invoke-nativecommand보다 닫는 구분 기호가 더 이상 부족하지 않습니다. LHS에서 구분하거나 공급해야하는 경우 here-strings를 사용하십시오. 그렇지 않으면 단일 명령문으로 간주됩니다.

Invoke-NativeShell 는 일반 명령이기 때문에 닫기 구분 기호를 _need_하지 않지만 --% 의 공포는 그렇지 않습니다.

Linux의 SHELL (기본값은 /bin/bash )

아니요 : Unix 계열 플랫폼의 _system_ 셸은 _invariably_ /bin/sh 입니다.

나는 그 일이 실행 가능한 스크립트 파일을 만들고 실행하는 것과 동일해야한다고 생각한다. 이것은 올바른 쉘을 선택하는 작업을 운영 체제에 위임하고 우리는 신경 쓰지 말아야한다. #! 시작하는 경우도 포함됩니다.

Invoke-NativeShell 의 기본 개념은 기본 셸의 _CLI_에 편리한 래퍼를 제공하는 것입니다.

• Unix에서는 이것으로 충분하며 보조 스크립트 파일을 생성하면 추가 오버 헤드가 발생할뿐만 아니라 $0 (스크립트 파일 경로)에 임의의 값이보고되는 반면 CLI를 통한 호출에는 예상대로 /bin/sh 가 포함됩니다 sh -c 'echo $0' foo )와 함께 코드 인수를 따라 명시 적으로 설정할 수도 있습니다.

  • (제외로 : shebang 줄 #!/bin/sh 로 쉘 스크립트를 생성한다는 것은 /bin/sh 직접 호출하는 것처럼 명시 적으로 전체 경로로 시스템 쉘을 대상으로 지정하는 것을 의미합니다).

• Windows에서 배치 파일 _would_를 통한 실행은 % 이스케이프 문제를 피할 수 있으므로 이점을 제공합니다 (하지만 $env:ComSpec 예상 할 수있는 시스템 셸 찾기 작업을 위임하는 것은 아님). 그리고 위에서 언급 for 동작.

후자를 예의로 다루기 위해 (사용자가 자신의 보조 배치 파일을 작성할 필요가 없도록) 개념적 명확성을 위해 다음을 제공 할 수 있습니다.
-AsBatchFile _opt-in_으로 전환합니다.

즉 대중의 대다수 있다는 합의가있는 경우 말했다 cmd 사용 명령 줄 컷 앤 페이스트 (마음에 _batch - file_ 의미로 기록 된이 %%i 보다는 %i 루프 변수로, 축어 % as %% ), 아마도 항상 aux를 사용하여 이스케이프하는 기능. 배치 파일 _on Windows_ (Unix에서 CLI를 고수하면서)가 더 나은 솔루션입니다. 저는 이것에 대해 강하게 느끼지 않지만 특히 다른 스크립팅 언어와 다른 동작을 나타내는 것을 의미하므로 명확하게 문서화해야합니다.

뿡뿡

나에게 링크하는 네이티브 오류 통합 RFC 는 # 1995처럼 긴급하게 해결할 가치가 있습니다.

둘 다 PowerShell에서 (개념적으로 가능한 한 많이) 외부 프로그램 (네이티브 유틸리티)을 일류 시민으로 만드는 데 필요한 단계를 나타냅니다.

일류 시민이된다는 것은 다음을 의미합니다. cmdlet을 통해 _가 아니라 _direct_ 호출 ( & 은 상황에 따라 _syntactic_ 이유로 만 필요함).
즉, Invoke-NativeCommand cmdlet 또는 Start-NativeExecution cmdlet이 없어야합니다.

(제외로 : Start-NativeExecution build 모듈의 많은 함수가 Start 신호 _asynchronous_ 작업 인 반면 Start-NativeExecution 이름이 잘못되었습니다. https://github.com/MicrosoftDocs/PowerShell-Docs/issues/4474에서 Start-Sleep ).

따라서 Invoke-NativeShell 에는 특별한 고려 사항이 필요하지 않습니다. PowerShell은 이미 수행 한 것처럼 네이티브 셸 실행 프로세스 ( cmd / sh 보고 한 종료 코드를 기반으로 $LASTEXITCODE 를 설정합니다. sh )가 호출되었습니다.

그런 다음 RFC에서 제안 된 메커니즘이 직접 호출 된 실행 파일에 대해 작동하는 것처럼 작동합니다 (예 : $PSNativeCommandErrorAction = 'Stop' 가 설정된 경우 $LASTEXITCODE 가 0이 아니면 스크립트 종료 오류가 발생합니다. )

(빠른 제쳐두고-이 토론은 여기에 속하지 않습니다 : _per-call_ 메커니즘에 관해서 :
/bin/ls nosuch || $(throw 'ls failed) 와 마찬가지로 /bin/ls nosuch || $(exit $LASTEXITCODE) (POSIX 쉘의 /bin/ls nosuch || exit ). # 10967은 왜 우리가 $(...) (문법에 큰 변화없이)를 피할 수 없는지 설명합니다. 마찬가지로 $LASTEXITCODE 명시 적으로 참조해야하는 경우는 피할 수 없습니다.)

(제외로 : shebang 줄 #!/bin/sh 로 셸 스크립트를 만드는 것은 /bin/sh 직접 호출하는 것처럼 명시 적으로 전체 경로로 시스템 셸을 대상으로 지정하는 것을 의미합니다.)

그것은 내가 말하고 싶은 것이 아닙니다. 운영 체제에이 기능이 내장되어 있기 때문에 PowerShell이 ​​기본 셸이 무엇인지 알 필요가 없다고 말하고 싶었습니다. Linux는 #! 시작하지 않거나 다음으로 시작하는 경우 실행 가능한 스크립트를 실행하는 방법을 알고 있습니다. #!/usr/bin/env python 와 같은 다른 것, Windows는 .CMD 스크립트를 호출하는 방법을 알고 있으므로 IMHO도 %COMSPEC% 'n'항목을 들여다 보지 않아야합니다. Windows는 다른 스크립트도 실행할 수 있지만 스크립트 파일의 확장자를 기반으로하므로이 경우에는 분명히 적용되지 않습니다.

다시 말하지만, Invoke-NativeShell 의 명령은 기본 셸의 _CLI_를 호출해야하며, 보조 스크립트 파일 (부작용 포함)을 백그라운드에서 생성하지 않아야합니다 ( 위에서 논의한 다른 이유 제외).

시스템 셸을 강력하게 결정하는 것과 관련하여 여기서 해결해야 할 문제는 없습니다. Windows에서 $env:ComSpec 를 참조하는 것처럼 Unix에서 /bin/sh 를 하드 코딩하는 것이 완벽하게 적절합니다.

아니요, 시스템 호출 수준의 Unix 플랫폼은 실행 가능한 일반 텍스트 파일을 _ shebang 줄없이 _ 실행하는 방법을 _ 알지 못합니다 _; _can_ 이러한 파일을 호출 할 수 있다는 것은 POSIX와 유사한 쉘의 편리한 기능입니다. exec 를 시도한 다음 _for them_으로 작성된 파일을 해석하도록 _fall back_; 즉, 실행중인 POSIX와 유사한 쉘이 파일 실행을 종료하는 반면 PowerShell은이 예의 폴백을 구현하지 않기 때문에 단순히 _fails_입니다 ( Program 'foo' failed to run: Exec format error 얻습니다).

말할 필요도없이 이러한 스크립트를 만드는 것은 좋지 않습니다.

아니요, 시스템 호출 수준의 Unix 플랫폼은 실행 가능한 일반 텍스트 파일을 _ shebang 줄없이 _ 실행하는 방법을 _ 알지 못합니다 _; 여전히 _can_ 이러한 파일을 호출 할 수 있다는 것은 POSIX와 유사한 쉘의 편리한 기능입니다. exec 를 시도한 다음 _ 대체 _ 해당 파일을 _for them_으로 해석합니다. 즉, 실행되는 POSIX와 유사한 쉘이 파일 실행을 종료하는 반면 PowerShell은이 예의 폴백을 구현하지 않기 때문에 단순히 _fails_입니다 ( Program 'foo' failed to run: Exec format error 얻습니다).

csh 는 POSIX와 유사하지 않으며 베어 스크립트 exec 에서 실패하지 않습니다. sh 호출합니다. perl 마찬가지입니다.

이것이 내 요점을 만드는 것이 분명하기를 바랍니다. 무엇을 할 것인지 결정하는 것은 _ 각 쉘에 달려 있으며, 다른 쉘 / 스크립팅 언어는 다른 일을합니다. PowerShell은 현재 실패합니다. 선택을해야하고 그 선택을 /bin/sh 원했다면 다시 원점으로 돌아 왔습니다. /bin/sh 를 가정해야합니다.

이것이 내 요점을 만드는 것이 분명하기를 바랍니다. 무엇을 할 것인지 결정하는 것은 _ 각 쉘에 달려 있으며, 다른 쉘 / 스크립팅 언어는 다른 일을합니다. PowerShell은 현재 실패합니다. 선택을해야하고 그 선택을 /bin/sh 원했다면 다시 원점으로 돌아 왔습니다. /bin/sh 를 가정해야합니다.

exec 의 perl 은 (는) 직접 시스템 호출이며 perl 는 어떤 식으로도 수정하지 않습니다. 특히 인터프리터를 _ 선택 _하지 않습니다.

물론 사용자가 작은 따옴표 (verbatim)와 큰 따옴표 (보간) 문자열의 차이점과 $ 선택적 ` 이스케이프에 대해 알고 있다고 가정하지만 중요하다고 생각합니다. (고급) 옵션이 있습니다.

나뿐 일 수도 있지만 -f 하나에 " 천

뿡 빵뀨

perl의 exec는 직접 시스템 호출이며, perl은 어떤 식으로도 수정하지 않습니다. 특히 통역사를 선택하지 않습니다.

#! 줄이없는 스크립트에서 작동하는 경우에는 사실이 아닙니다. Linux의 exec syscall은 #! 없이는 작동하지 않습니다. 쉽게 테스트 할 수 있습니다.

user@Programming-PC:/tmp/exec_test$ ls
test.c  testscript
user@Programming-PC:/tmp/exec_test$ cat test.c
#include <unistd.h>
#include <stdio.h>

int main(int argc, char **argv) {
  char *binaryPath = "./testscript";

  execl(binaryPath, binaryPath, NULL);

  perror("Error");

  return 0;
}
user@Programming-PC:/tmp/exec_test$ gcc test.c -o testexecutable
user@Programming-PC:/tmp/exec_test$ chmod +x testscript 
user@Programming-PC:/tmp/exec_test$ cat testscript 
echo test from script
user@Programming-PC:/tmp/exec_test$ #works from shell:
user@Programming-PC:/tmp/exec_test$ ./testscript 
test from script
user@Programming-PC:/tmp/exec_test$ #doesn't work via exec syscall:
user@Programming-PC:/tmp/exec_test$ ./testexecutable 
Error: Exec format error
user@Programming-PC:/tmp/exec_test$ vim testscript 
user@Programming-PC:/tmp/exec_test$ cat testscript 
#!/bin/sh
echo test from script
user@Programming-PC:/tmp/exec_test$ #exec syscall works with #! line:
user@Programming-PC:/tmp/exec_test$ ./testexecutable 
test from script
user@Programming-PC:/tmp/exec_test$ uname -a
Linux Programming-PC 4.4.0-176-generic #206-Ubuntu SMP Fri Feb 28 05:02:04 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
user@Programming-PC:/tmp/exec_test$ 

편집 : 방금 발견했습니다. 라이브러리 함수 execlp 를 사용하면 man 페이지에 따라 :

파일의 헤더가 인식되지 않는 경우 (시도한 execve (2)가 ENOEXEC 오류로 실패),이 함수는 파일 경로를 첫 번째 인수로 사용하여 셸 (/ bin / sh)을 실행합니다. (이 시도가 실패하면 더 이상 검색이 수행되지 않습니다.)

그러나 이것은 "linux"의 기능이 아니라 gnu c 라이브러리의 기능입니다. 맨 페이지에 따르면 명시 적으로 / bin / sh를 사용하고 사용자 정의 가능한 셸을 사용하지 않습니다. ( posix/execvpe.c ( new_argv[0] = (char *) _PATH_BSHELL; ) 및 sysdeps / unix / sysv / linux / paths.h (또는 sysdeps / generic / paths.h 소스에 하드 코딩되어 있음 -어떤 헤더가 중고 ...) ( #define _PATH_BSHELL "/bin/sh" ))

그러나 이것은 "linux"의 기능이 아니라 gnu c 라이브러리의 기능입니다. 맨 페이지에 따르면 명시 적으로 / bin / sh를 사용하고 사용자 정의 가능한 셸을 사용하지 않습니다. ( posix/execvpe.c ( new_argv[0] = (char *) _PATH_BSHELL; ) 및 sysdeps / unix / sysv / linux / paths.h (또는 sysdeps / generic / paths.h 소스에 하드 코딩되어 있음 -어떤 헤더가 중고 ...) ( #define _PATH_BSHELL "/bin/sh" ))

sysdeps/**/linux 에서 왔기 때문에 Linux 제품입니다. 또한 일반적인 것일 수도 있지만 재정의 할 수 있습니다. 분명히 로컬이 아니라 OS별로입니다.

예, _current_ 동작 @ vexx32를 이해합니다. 그러나 우리는 --% 의 _current_ 행동에 대해 이야기하고 있지 않습니다 (적어도 저는 아닙니다)-우리는 그것을 향상시키는 것에 대해 이야기하고 있습니다. 우리가 여기서 서로 이야기하고 있다는 느낌이 드는 이유는 무엇입니까? :)

따라서 --% 조정에 대한 현재 피치는 명령 이름이 일반적으로있는 경우 오른쪽에있는 모든 항목이 _as is_ (새 줄까지) 구문 분석되고 bash / cmd로 직접 전송된다는 것입니다. here-strings와 같은 PowerShell 구문은 여지가 없으며 --% 및 기본 명령 프로세서가 현재 가지고있는 것과 동일한 문제가 있기 때문입니다.

오 맙소사 ... 다들 날 트롤하려는 건가요? 😄 아니요, Patrick-powershell 표현식을 사용하려면 --% 와 함께 here-strings를 사용하십시오. 여러 줄을 원하면 here-strings를 사용하십시오. 변수 대체없이 다중 행을 원하면 작은 따옴표 here-string을 사용할 수 있습니다.

어쨌든,이 게임에는 스킨이없고 충분히 말한 것 같아요. 셸 내에서 다른 셸로 연기하기 위해 cmdlet을 사용하는 것에 대해 여전히 심각한 문제가 있다고 생각합니다. 서투른 것뿐입니다. cmdlet을 사용하여 다른 셸을 실행하여 처음에 보조 셸이 필요없는 기본 명령을 실행하는 경우 특히 서투 릅니다. 모든 것이 나쁜 냄새가 난다.

편집 : 마지막 단어

이 항목의 제목은 "call native operator"입니다. & 호출 연산자가 이미 있고 네이티브 명령 인 --% 인수를 전달하도록 설계된 토큰이 이미있을 때 낭비되는 기회가 있습니다. 지금은 & 와 함께 --% 를 사용하는 것은 인식되지 않으므로이 시나리오를 활성화하고 여기에서 논의되는 문제를 해결하기 위해 특정 동작을 제공하기로 결정한 경우 주요 변경 사항이 도입되지 않습니다.

powershell 표현식을 사용하려면 --% 와 함께 here-strings를 사용하십시오. 여러 줄을 원하면 here-strings를 사용하십시오.

연산자의 요점은 말 그대로 PowerShell 구문을 구문 분석하지 않는다는 것입니다. 여기 문자열 같은 것은 없습니다. 작은 따옴표로 묶인 문자열 상수와 같은 것은 없습니다. "텍스트를 오른쪽으로 보내기"가 아니라 "표현식을 오른쪽으로 평가하고 문자열로 변환하여 값을 보냅니다"입니다.

예를 들어 다음과 같은 경우 :

--% @'
echo my native command
'@

다음과 같이 번역됩니다.

cmd.exe /c "@'"
echo my native command
'@

'@ 는 @를 포함하는 작은 따옴표로 묶인 문자열 상수의 시작일 뿐이므로 파서 오류가 발생합니다.

ins 의 피치와 거의 같도록 구현을 다르게 상상하고있을 수 있지만 위는 --% 에 대해 논의중인 현재 피치입니다.

또한 이것이 기존 기능이 작동하는 방식이라는 점도 주목할 가치가 있습니다. 이 예제는 거의 동일한 방식으로 작동합니다.

cmd /c --% @'
echo my native command
'@

다시 한번 말한다:

현재, & with-%를 사용하는 것은 인식 / 정의되지 않으며 따라서이 시나리오를 활성화하고 여기에서 논의되는 문제를 해결하기 위해 특정 동작을 제공 하기로 결정한 경우 주요 변경 사항이 도입되지 않습니다.

더 명확하게 철자를 설명하겠습니다. & 와 함께 사용할 때 여기 문자열이 --% 뒤에 오도록 허용

Hah 그거 큰 휙-네, 놓 쳤어요, 미안 해요 @oising.

이 아이디어에 대해 --% 가 일부 컨텍스트에서는 구문 분석을 중지하고 다른 컨텍스트에서는 "네이티브 인수 바인딩에서 더 나은 작업을 수행"하는 것이 약간 혼란 스러울 것이라고 생각합니다 (마찬가지로 Invoke-NativeShell 대신 의미하는 경우).

exec , @TSlivede를 더 깊이 파헤쳐 주셔서 감사합니다. 요약해서이 접선을 닫도록하겠습니다. Linux 및 macOS 모두에 적용됩니다.

라는 어떤 시스템 (또는 라이브러리) 기능이 없다 exec 유닉스와 관련된 기능 만 _family_이 exec (대부분 접두사로) 이름이다.

• _system_ 함수 ( man 섹션 2 ), execve 핵심은 _fail_ shebang-less 스크립트를 실행하려고 할 때.

• 시스템 함수에서 _ 빌드하는 _library_ 함수 _ ( man 섹션 3 - man 3 exec ), p ( "경로"에 대해 가정) 시스템 쉘에 대한 패스 백 (예 : execlp )이 있습니다.

  • 이러한 함수의 GNU 라이브러리 구현은 @TSlivede 가 보여준 것처럼 /bin/sh 하드 코딩하는 반면, BSD 기반 은 sh 사용하고 sh 에 의존합니다. $env:PATH (비록 man 페이지에 /bin/sh 있지만).

언급했듯이 _ 직접 실행 _의 경우 주요 POSIX 유사 셸 ( bash , dash , ksh 및 zsh )은 shebang없는 스크립트 실행으로 돌아갑니다. _themselves_, 이는 exec 라이브러리 함수 중 대체 변형을 사용하지 _ 않는다는 것을 의미합니다. 대조적으로 perl 의 자체 exec 함수는 폴백에 의존하는 것이 었습니다. 유사하게, 주요 POSIX 유사 쉘의 exec _builtins_는 bash 제외하고 폴백에 의존합니다.

Unix에서는 백그라운드에서 스크립트 파일을 사용할 필요가 없기 때문에 시스템 셸 경로에 대해 폴백 라이브러리 함수와 동일한 가정을 할 수 있으며 /bin/sh 보다 sh /bin/sh 를 권장 합니다. 보안 및 예측 가능성 :

sh 의 위치를 ​​지정하지 않는 POSIX 사양 에도 불구하고 (즉, 엄밀히 말하면 BSD 라이브러리 함수가 호환됩니다) :

• /bin/sh 은 _ 사실상 _ 표준 위치이기 때문에 가정하는 것이 안전합니다. 왜냐하면 shebang 행이 _full, literal_ 만 지원한다는 점을 감안할 때 전체 경로로 sh 를 참조하는 휴대용 Unix 쉘 _necessitates_를 작성하기 때문입니다. 경로 ( #!/bin/sh ).

• 반대로 $env:PATH sh 를 통해 $env:PATH 조작하여 다른 sh 를 호출 할 수 있기 때문입니다.

동일한 위험 위치에 적용 cmd.exe 통해 $env:ComSpec 그래서 아마도 더 좋은 방법은 호출하는 그런데, GetSystemDirectory APPEND WinAPI를 기능과 \cmd.exe 행 그 결과 ( $env:ComSpec 가 정의되지 않은 경우 어쨌든 대체가 필요합니다).

/bin/sh 은 _ 사실상 _ 표준 위치이기 때문에 가정하는 것이 안전합니다. 왜냐하면 shebang 행이 _full, literal_ 만 지원한다는 점을 감안할 때 전체 경로로 sh 를 참조하는 휴대용 Unix 쉘 _necessitates_를 작성하기 때문입니다. 경로 ( #!/bin/sh ).

일반적으로 #!/usr/bin/env sh 라고 말합니다 (시스템 스크립트 제외).

• 일반적으로 _don't_ : 인터넷 검색 "#! / bin / sh"는 약 3,900,000 개의 일치를 생성하고 "#! / usr / bin / env sh" 는 약 34,100 개의 일치를 생성합니다.

• 일반적으로, 당신은 _shouldn't_ : 당신이 예상, _the_ 시스템 쉘을 대상으로 지정할 /bin/sh 무엇이든지,하지 sh 유틸리티가 처음에 와서 일이 $env:PATH .

sh 라는 실행 파일을 대상으로하는 유일한 이유는 가장 낮은 공통 분모 -assume-POSIX-features-only _system_ 셸, 즉 /bin/sh 를 이식 가능하게 대상으로 지정하기위한 것입니다.

일반적으로 _don't_ : 인터넷 검색 "#! / bin / sh"는 약 3,900,000 개의 일치를 생성하고 "#! / usr / bin / env sh" 는 약 34,100 개의 일치를 생성합니다.

웹 검색을 사용자 스크립트로 제한 할 수있는 방법은 없습니다. 특히 많은 사용자 스크립트가 실행 가능한 것으로 표시되지 않았고 실행 가능하다고해도 execlp 에 의존 할 수 있기 때문에 특히 그렇습니다. 그러나 대부분의 사용자 스크립트가 그렇게 말하더라도 _normal_에 대해 _customary_를 사용해서는 안됩니다. PowerShell에서 실행할 스크립트는 사용자 스크립트입니다. 사용자가 셸을 원할 때 편집증이 아니라면 /bin/sh 아니라 sh 를 호출합니다.

@oising

기본 셸 명령 줄 _ 단일 문자열로 전달 _ (어떤 문자열 (-리터럴) 형식이 가장 쉬운 지) 및 _only_ 단일 문자열로 전달 (유닉스에서 지원되는 명령 줄 인수에 대한 추가 전달 ( 만) 위에서 논의)-동의한다고 가정하면 공통점처럼 들립니다.

명령 줄을 _single string_으로 전달하는 것은 다음에 대한 전제 조건입니다.

• 이러한 호출을 _PowerShell_ 파이프 라인에 통합 할 수 있습니다.
• _PowerShell 변수 및 expression_을 기본 쉘 명령 줄에 통합 할 수 있습니다.

단일 문자열을 전달하는 것은 호출이 수행 할 작업에 대한 _ 직접 개념적 표현 _입니다. 반대로 _individual_ (선택적으로 맨말) 인수를 사용하여 PowerShell에서 직접 다른 셸의 구문을 직접 통합하려는 시도는 기존 --% 이미 구현되어있는 근본적인 제한과 함께 혼란스러운 타협을 초래하는 해결 불가능한 문제를 가져옵니다.

단일 문자열 명령 줄을 전달하기 위해 _operator_ 또는 _cmdlet_을 선택하는 것이 중요하지 않다고 주장 할 수 있지만 (_discoverability_ 질문은 제외) & 사용에 대한 개념적 우려가 있습니다. --% (앞에 & ) :

• & 대한 우려 : 명령 줄이 포함 된-quoted-문자열을 전달해야하는 경우 _expression_ 모드에서 효과적으로 작동하는 반면 & 현재 _argument_ 모드를 의미합니다 (즉 : _individual_ 인수, 필요한 경우에만 인용). 따라서 & 의 참여는 혼란 스럽습니다.

• --% 에 대한 우려는 Windows 전용 출처와 구문 분석 중지 기호 인 --% 의 혼란스러운 의미에 관한 것입니다. --% 가 _argument_ 모드에서 작동하는 구문 분석 중지 기호로 사용된다면 특히 혼란 스러울 것입니다 (예 :
  & /bin/ls --% dir1 dir2 ), & --% _expression_ 모드에서 작동 (예 : & --% '/bin/ls dir1 dir2 >out.txt' )

한 걸음 물러서서 현재 구현 된 파싱 중지 기호 인 --% 살펴 보겠습니다.

궁극적으로 관련되지 않은 두 가지 문제를 해결하려는 시도였습니다 (당시에는 Windows에만 해당).

• (a) 다른 플랫폼에도 적용되는 사용 사례 : cmd.exe / 네이티브 셸용으로 작성된 _command lines_을 그대로 재사용 할 수 있으므로 PowerShell의 구문에 적용 할 필요가 없습니다.

• (b) 항상 Windows 전용 문제 : PowerShell의 일반적인 비하인드 다시 인용이 제공 할 수없는 매우 구체적인 인용 스타일이 필요한 _rogue CLI_ (즉, _single_ 외부 콘솔 응용 프로그램에 대한 호출)를 호출하겠습니다. , 최종적으로 이러한 CLI _verbatim_에 대해 WinAPI로 전달되는 명령 줄을 만들 수있게하여. (문제 설명을 이것으로 제한하기 위해 PowerShell의 재 인용이 일반적으로 제대로 작동한다고 가정합니다. 이는 결코 없었습니다-이것이 # 1995의 주제입니다).

--% 은 (a)와 (b) 모두에 대한 솔루션 시도의 혼란스러운 _conflation_으로 구현되었으며 결국 두 문제를 제대로 해결하지 못했습니다.

• (a)에 대한 해결책으로 광고되었지만 실제로는 _ 에뮬레이션하는 유일한 cmd exe 기능이 %...% -스타일 환경 변수 참조 _의 확장이기 때문에 실제로는 심각한 제한이 있습니다.

  • _single_ cmd 명령 만 지원합니다. | (및
    && 및 || , 당시 구현되지 않았더라도) cmd 대한 패스 부분을 암시 적으로 종료합니다.

  • _single_ & - cmd s 다중 명령 구분 기호-_is_가 통과했지만,이 역시 _not_ 결과로 다중 명령을 지원합니다. 왜냐하면-이후 cmd t 실제로 관련됨- & 가 _verbatim 대상 프로그램에 전달됨 _; 예
    echoArgs.exe --% a & b 반향되지 않는 a 다음 호출 b 그것이 그대로 인수를 전달 a , & 및 b ~ echoArgs .

  • 인용되지 않은 인수에서 cmd 의 이스케이프 문자 ( ^ )는 적용되지 않습니다.

  • 결과적으로 기존 환경 변수를 참조하는 %...% 토큰은 _invariably_ 확장됩니다. ^ 를 통해이를 방지하려는 시도가 제대로 작동하지 않습니다 (예 :
    echoArgs.exe Don't expand %^USERNAME% 는 cmd 확장을 방지하고 _ ^ _를 제거하며 PowerShell에서 echoArgs.exe --% Don't expand %^USERNAME% 로 호출 될 때 ^ 유지합니다.

• (b)에 대한 해결책으로 부족했습니다.

  • (a) 사용과 마찬가지로 _PowerShell_ 변수와 표현식을 명령에 통합하는 기능이 없습니다. 어색하게 먼저 _aux를 정의하는 경우는 예외입니다. 그런 다음 --% 이후 %...% 를 통해 참조하는 environment_ variable_; 예
    $env:FOO='foo'; echoArgs.exe --% %FOO%!

(a)에 대한 적절한 해결책은 여기에 설명 된대로 Invoke-NativeShell / ins 입니다.

(b)에 대한 적절한 해결책은 다음과 같을 것입니다.

• _first_ 인수만큼 특별하게 --% 지원
• 그리고 ins 와 마찬가지로 통과 명령 줄을 구성하는 _ 단일 문자열 _ 뒤에 _ 전체적으로 _, 다시 문자열 보간을 통해 _PowerShell_ 변수 및 표현식을 통합 할 수있는 기능이 있어야합니다 (또는 문자열을 구성하는 다른 방법)
• 예를 들어 msiexec --% "/i installer.msi INSTALLLOCATION=`"$loc`"" , $loc 포함하는 'c:\foo\bar none' 는 그대로 명령 줄 /i installer.msi INSTALLLOCATION="c:\foo\bar none" 가 전달되어 msiexec 의 비표준 요구 사항을 충족합니다. <prop>=<value> 인수에서 <value> 부분 만 큰 따옴표로 묶습니다.

이것이 _ 편리하지는 않지만, Windows에서 전달되는 명령 줄 기반 인수 인 무정부 상태에 대한 강력한 솔루션에 대한 대가입니다.

@ mklement0 환자와 사려 깊은 답변에 감사드립니다 (평소처럼).

그래서 저는 전적으로 동의합니다.

(b)에 대한 적절한 해결책은 다음과 같을 것입니다.

• -%를 첫 번째 인수만큼 특별하게 지원
• 그리고 ins와 마찬가지로 통과 명령 줄을 전체적으로 구성하는 단일 문자열이 뒤에 와야합니다.>-다시 문자열 보간 (또는 다른 방법으로)을 통해 PowerShell 변수 및 식을 통합 할 수있는 기능 문자열 구성)
  
  
  
  • 예 : msiexec-% "/ i installer.msi INSTALLLOCATION = "$loc " ", $ loc에 'c : foobar none'이 포함 된 경우 그대로 명령 줄 / i installer.msi INSTALLLOCATION ="c : foobar msiexec의 비표준 요구 사항을 충족합니다.=인수 만부분은 큰 따옴표로 묶어야합니다.
  
  

이것은 (a)와 (b) 모두에 대한 일반화 된 솔루션으로 설명하려고 시도한 것입니다.하지만 여전히 (a)가 해결해야 할 독립적 인 문제로 존재해야한다는 사실을 알지 못합니다. 내가 정말로 어려움을 겪고있는 것은 (b)가 & 대해 _ 구체적으로 _ 구현된다면, 왜 (a)도 다룰 수 없습니까? 예를 들어 ins ... 는 & cmd --% ... 할 수없는 것에 대해 무엇을 제공합니까? 그리고 그것은 & 가 --% 를 인수로 전달하는 것을 허용하지 않는 것 외에는 큰 변화가 아닐 것입니다. (말도 안되는 일처럼 보입니다.) comspec, shells에 대해 걱정할 필요가없는 보너스 또는 무엇이든. 발신자가 결정하게하십시오.

@ PowerShell / powershell-committee는 이것을 검토했습니다.

• 이것은 실제 사용 피드백을 얻기위한 실험적 기능입니다 . 우리는 여전히 실제 인장에 열려 있습니다. PR 검토에 /bin/sh 대 /bin/env sh 연기
• 사용자가 PowerShell로 명령 줄을 잘라내어 붙여 넣는 "stackoverflow"시나리오를위한 새 연산자로 --% 를 사용하여 앞으로 나아갈 것입니다. )
• Invoke-NativeShell cmdlet은이 제안과 별개이며 PowerShellGallery의 커뮤니티에서 게시 할 수 있습니다. 또한 here-string을 요구하는 것은 here-string으로 래핑 할 것을 미리 알지 못하면 사용자 경험 문제를 해결하지 못합니다.
• 기존 사용자가 해당 동작에 의존 할 수있는 --% 스위치를 크게 변경하고 싶지 않습니다.
• --% 스위치와 같은 스트리밍 동작이 필요한 사용자는 해당 스위치를 계속 사용하고 필요에 따라 특수 문자를 이스케이프해야합니다.
• 사용자가 --% (또는 모든 솔루션)에 대해 알아야 할 검색 문제가 여전히 있습니다.
• 우리는 현재 사용자 의도를 예측하기 위해 붙여 넣은 콘텐츠를 here-string으로 수정하기 위해 PSReadLine을 변경하지 않습니다.
• 여기 문자열과 여기 문자열이 아닌 (확장) 시나리오를 허용하는 여러 솔루션을 찾고 있지 않습니다. 예 : & --% 대 --%

나는 또한 @ SteveL-MSFT와 나는 이것을 여는 것과 동시에 # 1995를 닫았음에도 불구하고 실제로 이것을 그 문제에 대한 확실한 해결책으로 전달하려는 의도가 아니었다 고 덧붙이고 싶습니다.

이 특정 기능의 이점이 # 1995의 영향보다 훨씬 더 중요하다고 생각합니다. 사람들이 잘라 내고 붙여넣고 싶어하는 비 PS 계몽 도구에 대한 많은 StackOverflow 예제와 문서 예제가 있다고 생각합니다 (자신 포함).

추가적으로 PowerShell의 자체 언어 내에서 적절한 이스케이프를 제공하려는 욕구가 있지만 사람들이 대량으로 # 1995를 누르는 것을 보지는 못합니다 (하지만 여기에서 더 자세히 설명하겠습니다).

• --% 을 (를) 새로운 연산자로 사용하여 앞으로 나아갈 것입니다.

드래그해서 미안합니다. 추가 논의를 원치 않습니다.하지만 어떤 종류의 운영자입니까? (주로 구문에 관심이 있습니다.)

$a = --% find . -iname *$pdf -print0 | xargs -0 ls -ltr

누가 파이프를 얻습니까? $ 어떻게 되나요? & , && 및 || 와 유사합니다.

PS 파이프에서 --% 를 사용할 수있는 조건은 무엇입니까?

감사.

드래그해서 미안합니다. 추가 논의를 원치 않습니다.하지만 어떤 종류의 운영자입니까? (주로 구문에 관심이 있습니다.)

AST 현명한 것은 아마도 기술적으로 연산자가 아니지만 자체 AST 유형입니다. 연산자로 구현되면 단항 연산자가됩니다.

$a = --% find . -iname *$pdf -print0 | xargs -0 ls -ltr

누가 파이프를 얻습니까? $ 어떻게 되나요? & , && 및 || 와 유사합니다.

find . -iname *$pdf -print0 | xargs -0 ls -ltr 문자열은있는 그대로 네이티브 셸로 전송됩니다. $a 는 여전히 채워져 있으므로 다음 라인에서이를 무언가로 파이프 할 수 있습니다.

앞으로 진행되는 PS 파이프에서 --% 를 사용할 수있는 조건은 무엇입니까?

~ 첫 번째 명령 요소 슬롯에있는 경우 문의 시작 부분에있을 것입니다. 이것이 새로운 구문의 장점 중 하나입니다. 처음부터 ~ 첫 번째 슬롯에서 ~가 아니라면, 오늘처럼 계속 작동 할 것입니다.

(@ daxian-dbw @ SteveL-MSFT 중 하나라도 잘못되면 수정하십시오 ❤️)

@SeeminglyScience 가 정확히 맞습니다.

첫 번째 명령 요소 슬롯에 있다면 아마도 그렇지 않을 것입니다. 이것이 새로운 구문의 장점 중 하나입니다. 첫 번째 슬롯에 있지 않으면 오늘날처럼 계속 작동합니다.

업스트림 명령의 출력을 --% 의해 호출되는 기본 명령에 전달하는 것은 까다로울 수 있습니다. --% 기본적으로 bash 와 같은 네이티브 셸에 문자열을 그대로 전달하지만 업스트림 명령의 출력은 bash 에 공급 될 수는 없지만 find 와 같은 기본 명령 자체.

스트리밍 동작은 주로 "StackOverflow"시나리오를위한 것이므로이 기능에 대한 고려 사항이 아니라고 생각합니다. 그래서 저는 우리가 _PowerShell_ 파이프 라인에서 작동하지 않을 것임을 분명히하기 위해 --% 를 특별한 문장으로 만드는 것이 낫다고 생각합니다.

아, "커맨드 요소 슬롯"이 잘못된 이유가 있다는 것을 알았습니다. 나는 성명서의 시작 부분을 의미했습니다. 내가 고칠 게, 고마워!

업스트림 명령의 출력은 bash 에만 제공 될 수 없습니다.

_upstream_은 _us_를 의미합니까? 나는 할 수 있다고 생각한다 : 'ls' | bash . 특별히 똑똑한 일은 아니지만 가능합니다.

이에 대해 중이었고 그는 shebang #! 를시길로 제안했습니다. 이 경우 다음을 입력하면됩니다.

#!/bin/sh ls | grep foo
#!sh | grep foo

(두 번째 경우는 sh 가 경로에 있다고 가정합니다). 이 경우 셸을 지정해야하는지 아니면 항상 기본 셸에서 실행하는지 결정해야하므로이 예제에서는 sh 가 두 번 시작됩니다. 그러나 오늘날 shebang 파일이 작동하는 방식으로 인해 이것에 문제가 있습니다. shebang은 주석으로 무시되기 때문에 PowerShell에서 작동합니다. 주석 인 경우 스크립트의 첫 번째 줄을 무시하기로 결정한 경우 대화 형 셸에서 새로운 각 줄 집합이 새 스크립트이고 해당 스크립트가 스크립트 또는 대화 형.

다른 방법은 마크 다운 구문을 빌리는 것입니다.

powershell ```bash ls | grep foo ```

이 예에서는 마크 다운 코드 펜싱 구문을 사용합니다. 이것은 또한 여러 줄 문제를 해결하고 완전히 새로운 개념을 사용합니다. 새로운 사용자를위한 초기 검색 문제가 여전히 존재한다는 점을 감안할 때 후행 트리플 백틱이 필요하다는 점에서 이것이 훨씬 더 나쁘다고 생각하지 않습니다.

이 경우 잠재적으로 작동 할 수 있습니다.

powershell $a = ```bash ls | grep foo ``` | select-string bar

@ SteveL-MSFT Markdown Syntax는 많은 의미가 있습니다. 지정할 수있는 경우. 파이썬이나 아마도 확장과 같은 다른 유형?

shebang #! 기존 댓글을 방해합니다.

그것은 파싱을 처리하고 사용자가 실제로 _use_하는 것 모두 나에게 엄청나게 복잡해 보입니다.

그리고 예, 우리는 사람들을 주석으로 표시되지 않는 주석이어야하는 줄과 혼동 할 필요가 없습니다. #Requires 은 (는) 이미 이상하게 생각하고 있습니다. shebang에 대한 전체 내용은 기껏해야 Windows 사용자와 Linux 사용자를 혼란스럽게 할 것입니다.

저는 개인적으로이 기능을 shebang과 혼합하지 않는 것을 선호합니다. 제 생각에는 혼란 스럽습니다.
또한 마크 다운 코드 블록 구문을 사용하기 시작하면 사람들이 PowerShell에서 직접 임의의 언어 코드 실행을 요청하는 것은 시간 문제 일뿐입니다. 나는 우리가 그렇게 가고 싶지 않다고 생각합니다 ...

또한 마크 다운 코드 블록 구문을 사용하기 시작하면 사람들이 PowerShell에서 직접 임의의 언어 코드 실행을 요청하는 것은 시간 문제 일뿐입니다.

나는 그것이 나쁜 생각이라는 것을 알고 있지만 말 그대로 인라인 C # 요청을 멈추지 않을 것입니다.

마크 다운 구문은 포함 된 스크립트가 자식 프로세스에서 실행되기 때문에 임의의 언어 코드를 도입하지 않습니다. 이제 @' 안에 임의의 언어 코드를 넣을 수 있으며 아무 문제가 없습니다.

팀 토론과 Jeffrey와의 토론에서 우리는 PowerShell 스크립트 내에서 다른 언어를 실행하려는 사람들을 반대해서는 안됩니다. @ yecril71pl이 언급했듯이 우리는 다른 언어를 직접 지원하지 않고 해당 코드를 해석하고 실행하기 위해 다른 프로세스에 의존합니다. 여기서 시나리오는 사용자가 Python 또는 bash 스크립트 블록을보고 PowerShell 스크립트 내에서 그대로 사용하기를 원한다는 것입니다. 사람들이 이것을 할 필요가 없습니다. 원하는 경우 다른 스크립트를 PowerShell로 포팅 할 수 있습니다. 이것은 사용자가 작업을 수행하기 위해 PowerShell로 잘라내어 붙여 넣을 수있는 옵션을 제공합니다.

단점은 이제 매우 유사한 작업을 수행하는 두 가지 방법이 있지만 구문이 서로 다르다는 점에서 두 가지를 모두 지원할 수 있다는 점에서 단일 행 제안과 다중 행 제안을 혼합 할 필요가 없습니다.

나는 한 줄짜리 물건을 버리는 것을 선호합니다. 외계인 코드 섬은 눈에 띄어 야합니다. 그렇지 않으면 아무도 무슨 일이 일어나고 있는지 이해하지 못할 것입니다.

@ yecril71pl 나는 주로 발견의 관점에서 볼 때 마크 다운 구문이 더 쉽게 알아볼 수있을 것이라고 생각하지만 마크 다운을 자주 작성했기 때문일 수 있습니다. 또한 많은 예제 스크립트는 각 단일 행이 독립적 인 프로세스가 될 일부 상태가 유지 될 것으로 예상하기 때문에 단일 행이 아니라 여러 행일 것으로 예상합니다.

팀 토론과 Jeffrey와의 토론에서 우리는 PowerShell 스크립트 내에서 다른 언어를 실행하려는 사람들을 반대해서는 안됩니다.

절대적으로 100 %이지만 이것이 언어에 직접 빌드되어야한다는 의미는 아닙니다.

@ yecril71pl이 언급했듯이 우리는 다른 언어를 직접 지원하지 않고 해당 코드를 해석하고 실행하기 위해 다른 프로세스에 의존합니다. 여기서 시나리오는 사용자가 Python 또는 bash 스크립트 블록을보고 PowerShell 스크립트 내에서 그대로 사용하기를 원한다는 것입니다.

이미 here-strings로 할 수 있습니까? 이것이 기존 방법에 비해 어떤 이점을 제공하는지 조금 자세히 설명해 주시겠습니까?

또한 왜 python과 bash에서 멈추나요? C #, CIL, C ++가 아닌 이유는 무엇입니까?

사람들이 이것을 할 필요가 없습니다. 원하는 경우 다른 스크립트를 PowerShell로 포팅 할 수 있습니다. 이것은 사용자가 작업을 수행하기 위해 PowerShell로 잘라내어 붙여 넣을 수있는 옵션을 제공합니다.

나는 그것을 사용하도록 강요받을 것이라고 생각하기 때문에 이것을 반대하지 않습니다. 언어 관점에서 유지 관리가 어렵고 편집자에게는 악몽이며 궁극적으로 여러 언어를 알지 않으면 읽을 수없는 스크립트를 장려하기 때문에 마음에 들지 않습니다.

실제로 이것은 훨씬 더 광범위한 의미를 가진이 스레드의 원래 주제와는 매우 다른 개념입니다. 새로운 문제를 만드는 것이 좋습니다.

이미 here-strings로 할 수 있습니까? 이것이 기존 방법에 비해 어떤 이점을 제공하는지 조금 자세히 설명해 주시겠습니까?

범용 코드 편집기는이를 감지하고 적절하게 장식 할 수 있지만 편집기는 내부 내용을 알지 못하기 때문에 @' 로 수행 할 작업이 없습니다.

또한 왜 python과 bash에서 멈추나요? C #, CIL, C ++가 아닌 이유는 무엇입니까?

스크립팅 언어가 아니기 때문에?

범용 코드 편집기는이를 감지하고 적절하게 장식 할 수 있지만 편집기는 내부 내용을 알지 못하기 때문에 @' 로 수행 할 작업이 없습니다.

편집자는 bash -c @' 에 코드 펜스처럼 쉽게 bash가 포함되어 있다고 말할 수 있습니다. 또한 어려운 부분은 코드 섹션이 어떤 언어인지 결정하는 것이 아니라 언어 서버와 구문 하이 라이터를 저글링하는 것입니다. 상당한 시간과 노력을 투자하지 않고 작동하는 유일한 방법은 본질적으로 여기에있는 것처럼 렌더링하는 것입니다.

스크립팅 언어가 아니기 때문에?

C # 및 C ++에는 모두 스크립트 지향 하위 집합이 있습니다. 그렇지 않더라도 "스크립팅 언어"는 실제 정의가없는 주관적입니다. 포함 대상으로 간주되는 항목과 포함되지 않는 항목에 대한 명확한 경계로서 도움이되지 않습니다.

C # 및 C ++에는 모두 스크립트 지향 하위 집합이 있습니다. 그렇지 않더라도 "스크립팅 언어"는 실제 정의가없는 주관적입니다.

일반적으로 interpet options… script arguments… 호출 할 때 언어는 (독립 실행 형) 스크립팅 언어이며 해당 호출은 임시 항목을 제외하고 인터프리터에게 비공개로 남겨 두는 것 외에는 아무것도 남기지 않습니다. 또한 일반적으로 실행하려면 인터프리터 사본이 필요합니다. 이런 방식으로 실행할 수없는 임베디드 스크립팅 언어가 있습니다.

안녕하세요.

이미 here-strings로 할 수 있습니까? 이것이 기존 방법에 비해 어떤 이점을 제공하는지 조금 자세히 설명해 주시겠습니까?

사람들은 오늘날 here-strings를 사용하거나 올바른 방법을 알아낼 수 있다면 기본 명령에 전달 된 모든 인수를 이스케이프 할 수 있습니다. 여기서의 의도는 잘라 내기 및 붙여 넣기 (Stackoverflow) 시나리오에 대한 새로운 사용자를 위해 더 간단하게 만드는 것입니다.

또한 왜 python과 bash에서 멈추나요? C #, CIL, C ++가 아닌 이유는 무엇입니까?

여기서 지원되는 시나리오는 기본 명령에 전달되는 텍스트 블록입니다. 해당 호출 규칙을 지원하는 경우 모든 언어를 지원할 수 있습니다. 임시 소스 파일을 만들고 컴파일 할 제안이 없습니다.

나는 그것을 사용하도록 강요받을 것이라고 생각하기 때문에 이것을 반대하지 않습니다. 언어 관점에서 유지 관리가 어렵고 편집자에게는 악몽이며 궁극적으로 여러 언어를 알지 않으면 읽을 수없는 스크립트를 장려하기 때문에 마음에 들지 않습니다.

혼합 된 언어 구문 색상을 얻을 것이라는 기대는 없습니다. 다른 언어의 중첩 된 스크립트는 단조로워집니다.

실제로 이것은 훨씬 더 광범위한 의미를 가진이 스레드의 원래 주제와는 매우 다른 개념입니다. 새로운 문제를 만드는 것이 좋습니다.

제안 된 구현은 원래 문제와 다르지만 잘라 내기 및 붙여 넣기 및 "그냥 작동"시나리오 인 문제는 동일합니다.

사람들은 오늘날 here-strings를 사용하거나 올바른 방법을 알아낼 수 있다면 기본 명령에 전달 된 모든 인수를 이스케이프 할 수 있습니다. 여기서의 의도는 잘라 내기 및 붙여 넣기 (Stackoverflow) 시나리오에 대한 새로운 사용자를 위해 더 간단하게 만드는 것입니다.

맞지만 실제로 어떻게 더 쉬울까요? 나는 그것이 주관적이라는 것을 알지만 이것들은 나에게 그렇게 다르지 않은 것 같습니다.

~~~ 파워 쉘
$ a =```bash
찾기 . -iname * $ pdf -print0 | xargs -0 ls -ltr

~~~

vs

```powershell
$a = bash -c @'
   find . -iname *$pdf -print0 | xargs -0 ls -ltr
'@

후자가 일어날 일에서 훨씬 더 명확하다는 점을 제외하면 거의 동일 해 보입니다.

여기서 지원되는 시나리오는 기본 명령에 전달되는 텍스트 블록입니다. 해당 호출 규칙을 지원하는 경우 모든 언어를 지원할 수 있습니다. 임시 소스 파일을 만들고 컴파일 할 제안이 없습니다.

C #에는 임시 소스 파일이 필요하지 않습니다. CIL이 아닐 수도 있습니다 (C ++에 대한 아이디어 없음). 어느 쪽이든 실행 파일 (예 : bash / python / cmd)을 호출하기위한 구문 적 설탕 인 코드 울타리가 나에게 혼란 스럽습니다. 코드 울타리는 언어 지원 imo를 의미

혼합 된 언어 구문 색상을 얻을 것이라는 기대는 없습니다. 다른 언어의 중첩 된 스크립트는 단조로워집니다.

tmLanguage 기반 파서에게는 여전히 악몽이 될 것입니다. 그들은 atm을 기대하는 구문을 간신히 처리 할 수 ​​있습니다. 그 이상으로, 만약 그렇다면 나는 그것이 here-string과 다른 이유를 이해하지 못합니다.

제안 된 구현은 원래 문제와 다르지만 잘라 내기 및 붙여 넣기 및 "그냥 작동"시나리오 인 문제는 동일합니다.

공정하지만 이전에 제안 된 솔루션을 논의하는 데 이미 145 개의 의견이 있습니다. 특히이 스레드가 이미 결론에 도달 했으므로 새로운 전용 스레드에 훨씬 더 많이 참여할 수 있습니다.

C #에는 임시 소스 파일이 필요하지 않습니다. CIL이 아닐 수도 있습니다 (C ++에 대한 아이디어 없음). 어느 쪽이든 실행 파일 (예 : bash / python / cmd)을 호출하기위한 구문 적 설탕 인 코드 울타리가 나에게 혼란 스럽습니다. 코드 울타리는 언어 지원 imo를 의미합니다.

나는 이것에 대한 @SeeminglyScience 의 의견을 반영하고 싶습니다. Microsoft.CodeAnalysis.CSharp.Scripting 라이브러리로 컴파일하지 않고도 C # 스크립트 를

PowerShell의 코드 펜싱 구문은 이론적으로 다음을 허용하는 네이티브 명령을 호출하기위한 것이라고 말할 수 있습니다.

    ```c:\mypath\MyArbitraryExe
        args to my arbitrary executable
    ```

그러나 @SeeminglyScience가 언급했듯이 언어 지원을 의미하는 markdown과 사용자의 확립 된 이해와

이론적으로 이것을 허용하는

인수가 아닌 내부에 스크립트를 넣고 스크립트는 입력 스트림과 동일합니다. 또한 이것이 SO 지원을 제공하려는 경우 전체 경로가 허용되지 않아야합니다.

인수가 아닌 내부에 스크립트를 넣고 스크립트는 입력 스트림과 동일합니다.

스크립트는 bash / cmd / python의 인수입니다.

또한 이것이 SO 지원을 제공하려는 경우 전체 경로가 허용되지 않아야합니다.

그런 다음이 예제로 전환하십시오.

~ powershell$ a = ipconfig /all ~

또는 먼저 임의의 exe를 경로에 추가하십시오.

인수가 아닌 내부에 스크립트를 넣고 스크립트는 입력 스트림과 동일합니다.

스크립트는 bash / cmd / python의 인수입니다.

그들 중 어느 것도 위치 인수로 스크립트를 전달할 수 없습니다. CMD 에서는 배치 파일도 허용하지 않습니다.

또한 이것이 SO 지원을 제공하려는 경우 전체 경로가 허용되지 않아야합니다.

그런 다음이 예제로 전환하십시오.

$ a =```ipconfig
/모두

작동하지 않습니다.

이 마크 다운 아이디어가 작동하기 위해 우리는 매우 임의적 인 기준으로 엄청나게 많은 특수 사례를 만들 것 같습니다.

또한 이것이 Markdown에서도 지원되는 주된 이유는 구문 강조 때문입니다. 이와 같은 것을 언어에 추가하면 지속적인 요청이 될 것입니다.

이것은 효과적인 해결책이 아닙니다.

이에 대해 중이었고 그는 shebang #! 를시길로 제안했습니다.

2 센트를 더하기 위해 해결책이 발표 된 후이 토론을 다시 시작하는 것은 실수라고 생각합니다. 그리고 개인적으로 나는 shebang과 markdown 구문을 모두 싫어합니다 (둘 다 주요 변경 사항입니다).

누군가가 명백히 더 좋은 것을 가지고 올 경우 나는 논의를 다시 시작 상관하지 않습니다. 실제로 기능이 출시 된 후보다 지금 하는 것이 좋습니다. 나는 단지 #! 또는 markdown 접근법이 "un-PowerShell-adulterated"명령 줄 문자열을 네이티브 exe에 제공하는 더 나은 솔루션이라고 생각하지 않습니다. 익숙해지기 위해 시도 해봐야 할 수도 있지만 초기 반응은 ... 음, 어.

_ 우리 (및 PowerShell)가 기본 실행 파일을 실행한다는 것을 알고 있다면 왜 "기본 연산자 호출"이 필요합니까? _

PowerShell이 ​​입력 문자열을 구문 분석하고 CommandAst를 가져 오면 PowerShell은 명령을 검색합니다.
명령이 기본 명령 인 경우 PowerShell은 ast를 NativeCommandProcessor로 변환합니다.
Ast 범위 (즉, 입력 문자열)를 다시 구문 분석하여 기본 실행 파일 이름 / 경로 및 나머지 문자열을 OS 규칙에 따라 인수 또는 인수로 가져 오는 경우에 새로운 (실험용 NativeCommandProcessor)를 구현할 수 있습니다.

사용자가 쉘에서 복사-붙여 넣기를 원한다면 "cmd"또는"bash"-편집없이 작동합니다.
사용자가 기본 명령 줄을 복사하여 붙여 넣기를 원하는 경우g++ timer.cpp @conanbuildinfo.args -o timer --std=c++11 처럼 작동합니다.

사용자가 쉘에서 복사-붙여 넣기를 원하는 경우

이에 대한 Get-/Set-Clipboard 이 있습니다.

Ast 범위 (즉 입력 문자열)를 다시 구문 분석하여 기본 실행 파일 이름 / 경로 및 나머지 문자열을 OS 규칙에 따라 인수 또는 인수로 가져 오는 경우.

내 생각은 다음 중 하나를 수행하는 것입니다.

• AST 명령을 비효율적으로 구문 분석하고 나중에 범위를 문자열로 다시 구문 분석하고 원래 AST를 버리십시오. 또는
• AST를 가져와 (현재 NativeCommandProcessor가 수행하는 방식) 문자열로 다시 재편성하려고 시도하지만 그렇게하면 모든 것이 손실됩니다.

따라서 대신 처음부터 문자열을 보존해야합니다. 이제 PowerShell에는 이미 세 가지 종류의 문자열 토큰이 있다고 생각하지만이 토론의 주요 요청은 사물을 이스케이프하고 싶지 않은 것 같습니다. 모든 문자열은 종결자를 이스케이프 할 수 있어야하지만 여기서 논의 된 솔루션은 종결 자로 개행 문자를 사용하고 개행 문자를 이스케이프 할 수없는 것 같습니다 (항상 세미콜론이 있음).

나는 줄 바꿈 전용 터미네이터에 완전히 집착하지는 않았지만, 아무것도 탈출하고 싶지 않은 유일한 해결책 인 것 같습니다. 기본적으로 "네이티브 콜 연산자"는 오늘날의 라인 주석과 비슷하게 토큰 화됩니다. 연산자에서 라인 끝까지 "네이티브 쉘"로 전달되는 문자열입니다.

그래서:

--% ps -o pid,args -C bash | awk '/running_script/ { print $1 }'

다음과 같이 토큰 화됩니다.

--% ps -o pid,args -C bash | awk '/running_script/ { print $1 }'
|-||-----------------------------------------------------------|
 |                                  \
Native call operator        Invocation to be passed to native shell

(문자열이 --% 바로 뒤에 시작하므로 --% 바로 뒤에 공백도 기본 쉘로 보냅니다.)

그런 다음이 토큰은 다음과 같이 매우 간단한 AST로 래핑됩니다.

// We need to carefully work out what AST this inherits from
// This syntax has almost no interoperability with PowerShell by design,
// so can't implement fields like redirections or backgrounding faithfully.
// But in order to participate in pipelines and similar, would need to extend a more concrete class
public class NativeCallInvocationAst : StatementAst
{
    public string NativeInvocation { get; }
}

그런 다음 컴파일되어 파이프로 전송 된 후 새로운 기본 명령 프로세서를 사용하여 문자열을 기본 셸에 대한 인수로 직접 보냅니다.

이 모든 것이 구현 가능한 것처럼 보이지만 마음 속에 몇 가지 질문이 있습니다.

• 기본 셸을 구성 할 수 있습니까? 그렇지 않다면 어떻게 정당화 할 수 있습니까? 그렇다면 구문의 일부로 명시 적이어야합니까 (구문을 복잡하게 함), 아니면 기본 설정 변수로 구현해야합니까 (검색 및 관리가 더 어려워 짐)?
• 그러한 구현이 발견 가능하고 사람들을 혼란스럽게하지 않을까요? 사용자는 여기에서 PowerShell이 ​​얼마나 적은 작업을 수행하는지 또는 | 또는 & 또는 문자열을 사용할 때 어떤 일이 발생하는지 이해할 수 있습니까?
• 여기에서 한 줄 축어 문자열로 처리 할 시나리오는 몇 개입니까? 많은 사람들이 다중 라인 호출을 원한다는 것을 알아 내기 위해 이것을 구현할까요? 이러한 제약 조건을 추가 할만큼 작은 따옴표를 이스케이프하는 것과 같은 작업을 피해야합니까?
• 이것은 완전히 새로운 언어 구문에 대한 매우 구체적인 시나리오처럼 보입니다. 새로운 축어 문자열 구문을 만드는 경우 왜이를 네이티브 호출 개념에 직접 결합합니까? 새로운 호출 메커니즘을 생성하는 경우 왜이를 다른 쉘의 개념에 직접 결합합니까? 좋은 구문과 좋은 언어 구조는 구문 적 및 기능적으로 구성되며 언어 자체에 너무 많이 적용하지 않으려 고합니다 (사용자가 프로그램으로 조합 할 수있는 요소의 플랫폼을 제공하는 대신) — 제안 된 기본 호출 구문이 기준을 충족합니까? 새로운 기본 구문을 프로그램으로 구성하려면? 이 문제를 간단한 방법으로 해결하면서도 다른 문제를 해결하기 위해 구성 할 수 있도록 구성 요소를 분리 된 상태로 유지할 수있는 더 나은 대안이 있습니까?
• 다른 쉘이나 다른 언어가 이것을 구현합니까 아니면 이미 가지고 있습니까? 구문 수준에서 또는 다른 수준에서? 그렇다면 어떻게?

여기 내 생각은 당신도이 일을

@rjmholt CommandAst에는 입력 문자열이있는 Extent 속성이 있습니다. 재분석은 Windows에서 첫 번째 공백으로 분할하거나 Unix에서 공백으로 분할하는 것처럼 간단합니다. 그래서 나는 우리가 현에서 아무것도 잃지 않고 좋은 성능을 얻을 것으로 기대합니다.

그러나 이것이 구현되면 테스트 할 일련의 사용 사례가 필요하다고 생각합니다. 다음을 "제안"하겠습니다.

• 사용 사례 1 : 인용 / 이스케이프 규칙에 대해 알지 못해도 단일 exe 리터럴 (보간 없음) 호출이 작동하기를 원합니다. 예 : g++ timer.cpp @conanbuildinfo.args -o timer --std=c++11 . 이에 대한 현재 해결 방법은 인용 할 내용을 파악하는 것입니다. 예 : g++ timer.cpp '@conanbuildinfo.args' -o timer --std=c++11 더 복잡한 예에는 여러 줄에 걸쳐있는 명령 줄이 포함될 수 있습니다.

tar -cvpzf /share/Recovery/Snapshots/$(hostname)_$(date +%Y%m%d).tar.gz \
    --exclude=/proc \
    --exclude=/lost+found 

현재 해결 방법 ( \ 대한 백틱 교체) 예 :

tar -cvpzf /share/Recovery/Snapshots/$(hostname)_$(date +%Y%m%d).tar.gz `
    --exclude=/proc `
    --exclude=/lost+found

• 사용 사례 1a : PS 보간을 사용한 단일 exe 호출이 작동하기를 원합니다. 예 : g++ $CppFile @conanbuildinfo.args -o timer --std=c++11 . 이에 대한 현재 해결 방법은 인용 할 내용 (단일 또는 이중)과 이스케이프 대상을 파악하는 것입니다. 예 : g++ $CppFile '@conanbuildinfo.args' -o timer --std=c++11 더 복잡한 예에는 여러 줄에 걸친 명령 줄이 포함될 수 있습니다.

tar -cvpzf "/share/Recovery/Snapshots/${ComputerName}_`$(date +%Y%m%d).tar.gz" \
    --exclude=/proc \
    --exclude=/lost+found 

현재 해결 방법은 첫 번째 인수를 큰 따옴표로 묶고 \ 대한 백틱을 바꾸고`$ (date + ...)의 시작 부분에서 $ 를 이스케이프합니다.

• 사용 사례 2 : ps -o pid,args -C bash | awk '/running_script/ { print $1 }' 및 wsl ls $foo && echo $PWD 와 같은 다른 셸에서 리터럴 파이프 라인 명령 을 실행하고 싶습니다 . _ 이전 사례와 별도의 사용 사례가 필요한지 확실하지 않습니다. 현재 해결 방법은 bash 명령을 인용하는 것입니다 (예 : bash -c 'ps -o pid,args -C bash | awk ''/-bash/ { print $1 }''' . 이 사용 사례에는 여러 줄 문자열도 포함될 수 있습니다. 예 :

ps -o pid,args -C bash | \
awk '/running_script/ { print $1 }'

• 사용 사례 2a : PS 보간을 사용

• 사용 사례 3 : 작업을 계속하려면 npm run $scriptName 가 필요합니다 (예 : 변수 보간) . (이는 암시적일 수 있으며 명시 할 필요가 없습니다).

interpolating 문자열 (예 : g++ $CppFile @conanbuildinfo.args -o timer --std=c++11 대한 유스 케이스가 있어야하는지 여부에 대한 질문이 있습니다. 아니면 그냥 그것에 대해 펀트하고 현재의 이스케이프 규칙이이를 다루고 있다고 말할까요?

이는 올바른 (또는 전부) 사용 사례가 아닐 수 있지만 사용 사례를 문서화하고이 기능을 논의 할 때 참조 할 수 있으면 도움이 될 것이라고 생각합니다. 그렇지 않으면 기능이 실제로 처리하는 방식에서 길을 잃기 쉽습니다. ) 고객 사용 사례.

또한 두 번째 사용 사례는 "쉘 호출"이 필요한 것 같습니다. 그래도 첫 번째는 확실하지 않습니다. exe가 직접 호출 될 수있는 것 같습니다.

@rkeithhill 이전 게시물에서 완전성을 위해 기존 해결 방법을 추가 할 수 있습니까?

@oising , 나도 사려 깊은 응답에 감사드립니다.

ins ... 는 & cmd --% ... 할 수없는 것에 대해 무엇을 제공합니까?

--% 현재의 _parameter_ (기호) 형식-우리가 유지하고 싶은 행동- cmd /c --% 사용할 수 없습니다. _multi-command_ cmd 지원하지 않기 때문입니다 ^ 도 사용하지 않음), 첫 번째 인용되지 않은 | 는 _PowerShell's_ 파이프 연산자로 해석되고 & 가 그대로 전달됩니다.
--% 는 일반적으로 거의 쓸모없고 sh -c 는 모두 실패합니다. sh 는 명령 줄을 _single_ 인수 (예 : sh -c --% echo hi 는 echo 만 명령으로 실행되기 때문에 빈 줄을 생성합니다.

ins , _ 단일 문자열로 전달하여 통과 명령 줄을 구분해야 함 _ _ 이러한 문제를 해결하고 명시된 바와 같이 문자열 보간을 사용하여 _PowerShell_ 변수 및 표현식 값을 통합 할 수도 있습니다.

그리고 후자는 제안 된 --% _statement_가 _ 막 다른 거리 _ 인 이유를 알려줍니다 .

• 기존 명령 줄을 그대로 _ 그대로 _ 실행하는 것에서 _PowerShell_ 변수 및 표현식 값을 여기에 통합하는 것까지 _ 전환 경로가 없습니다 _.

  • 모호하고 번거로운 유일한 방법은 관심있는 PowerShell 값을 저장하고 참조 할 수있는 _ 보조 환경 변수 _를 정의하는 것입니다 (셸에 적절하게 %...% 또는 $... ). 기본 명령 줄.

• --% 문을 더 큰 PowerShell 파이프 라인에 통합 할 수 없다는 어색함이 있습니다.

  • 이 통합을 기대할 수있는 네이티브 셸을 호출하는 합법적 인 _non_cut-and-paste 이유가 있습니다. 특히, (중간) 파이프 라인을 통해 _raw byte data_를 전달하고 후행 줄 바꿈없이 _strings을 전송하려면 네이티브 파이프를 사용해야합니다. 실제 예제는 이 SO 답변 을 참조하십시오.

• 또한 --% _parameter_의 어색함이 Unix에서 사실상 쓸모가 없어서 이상한 비대칭을 도입합니다. --% _statement_가 Unix에서도 작동한다면 --% _parameter_ ? (예 :
  /bin/echo --% 'hi "noon"' 'hi noon' (예상 hi "noon" )를 산출합니다. echo 가 _two_ 인수를 수신하므로 'hi 및 noon' , 작은 따옴표는 데이터로 유지되고 큰 따옴표는 제거됨).

ins 는 --% 문에 대한 제안 된 대안으로 cmd /c 및 sh -c 주위의 _convenience wrapper_가 이상적이지만 실제로는 _required_입니다.

• 호출하기 때문에 유닉스에서 적어도 _temporarily_, 같은에서만큼 # 1995, 고정되지 sh -c '...' 직접 현재 임베디드와 인수를 전달하지 않습니다 " 제대로을 통해.

• 에 Windows에서 _Invariably_, 명령 라인 통과해야하기 때문에 _as을-IS_ cmd 바이어 lpCommandLine 매개 변수의 CreateProcess 합니다 (있는 --% 매개 변수를 할 수 없다 _one_ 명령으로 제한되기 때문입니다. 또는 "..." 묶인 _ 단일 문자열 _로 명령 줄을 다시 전달하려고하면 # 1995로 인해 제대로 작동하지 않습니다.

_argument_ 전달 문제는 _via stdin _ ( ins 도 지원할 수 있고 지원해야 함)을 실행하는 명령 줄을 제공하여 피할 수 있습니다. 즉, _pipe_ 명령 줄 / 스크립트 텍스트를 쉘 실행 파일에 제공합니다.

• Unix에서는 _stdin_을 통해 sh 로 코드를 전달하는 것이 실행을 위해 _script file_을 전달하는 것과 본질적으로 동일하기 때문에 제대로 작동합니다 ( sh -c '<code>' is ).

PSonUnix> @'
echo '{ "foo": "bar" }' | cat -n
'@ | sh

     1  { "foo": "bar" }

• 아아, Windows에서 cmd 는 이러한 입력을 잘 처리하지 못합니다. 로고를 인쇄하고 실행 전에 각 명령을 프롬프트 문자열과 함께 에코합니다.

PSonWin> 'date /t & ver' | cmd

Microsoft Windows [Version 10.0.18363.836]
(c) 2019 Microsoft Corporation. All rights reserved.

C:\Users\jdoe>date /t & ver
Sun 07/26/2020

Microsoft Windows [Version 10.0.18363.836]

C:\Users\jdoe>

슬프게도 PowerShell 자체도 비슷하게 도움이되지 않는 동작을 보입니다. # 3223 참조

sh 및 모든 주요 POSIX 유사 셸 ( dash , bash , ksh , zsh )과 마찬가지로 대부분의 스크립팅 언어가 올바르게 _do_ python , node , ruby 및 perl 와 같은 stdin-as-script 입력을 지원합니다.

PS> 'print("hi")' | python

hi

_PowerShell_ 변수 및 표현식 값을 통합하기 위해 다시 문자열 보간 / 연결을 사용하는 옵션이 있습니다.

PS> $foo = 'bar'; "print(`"$foo`")" | python

bar

또는 인터프리터의 인수 전달 기능 사용 :

PS> @'
import sys
print(sys.argv[1])
'@ | python - bar

bar

위의 내용이 --% 문도 #! 문도, 마크 다운 코드 블록도 아닌 특수 구문이 전혀 필요 없음을 분명히 보여주기를 바랍니다. 호출 PowerShell 스크립트의 값을 통합하는 기능.

사용할 네이티브 셸의 구성 가능성 : 예측 가능성을 위해 하나를 제공해서는 안된다고 생각합니다. 다른 셸을 대상으로하는 사용자는 명령 줄을 해당 셸의 특정 실행 파일로 파이프하거나 # 1995가 수정되면 인수로 전달할 수 있습니다.

• 논란의 여지가있는 변형은 /bin/bash 를 대상으로하는 것입니다 ((가능성이없는) /bin/sh 대체)-게시 된 명령 줄이 POSIX 필수 기능에만 의존하고 Bash-ism이있는 명령 줄에 의존하기를 바랍니다. (모든 /bin/sh 구현이 지원할 것으로 예상되지 않는 비 POSIX 기능)은 bash 의 보급률을 감안할 때 외부에있을 가능성이 높습니다.

헉헉

이 특정 기능의 이점이 # 1995의 영향보다 훨씬 더 중요하다고 생각합니다.

이 잘라 내기 및 붙여 넣기 기능을 만드는 데 많은 노력을 기울이는 것은 놀랍습니다.-주로 _interactive_의 편의를 위해-(어색하고 기능이 제한적인) 일류 시민 인 반면 PowerShell의 근본적인 무능력 " 문자가 포함 된 인수 및 인수.

하지만 사람들이 한꺼번에 # 1995를 치는 건 못 봤어요

그렇습니다. 제가 이전에 논의한 이유 때문에 _ 더 많이 보게 될 것입니다 _.

다시 말하지만, PowerShell이 ​​현재 수행하는 것처럼 다음을 수행하는 셸에는 심각한 문제가 있습니다 .

# On Unix
PS> /bin/echo '{ "foo": "bar" }'

{ foo: bar }

@rjmholt CommandAst에는 입력 문자열이있는 Extent 속성이 있습니다. 재분석은 Windows에서 첫 번째 공백으로 분할하거나 Unix에서 공백으로 분할하는 것처럼 간단합니다. 그래서 나는 우리가 현에서 아무것도 잃지 않고 좋은 성능을 얻을 것으로 기대합니다.

그래, 나는 거기의 무승부를 이해하고 아마도 해당 시나리오에서 AST의 할당이 끔찍하지 않을 것입니다 (단순한 구문에 대해 불필요한 할당을 생성해서는 안된다고 주장하지만). 하지만해야 할 일은 bash / cmd가 문자열로 인식하고 PowerShell이 ​​문제를 시작하지 않는 입력을 상상하는 것입니다.

현재 PowerShell로 구문 분석하지 않습니다.

--% my_command "\" "

구문 분석하지만 공백으로 분할하면 잘못된 결과가 제공됩니다.

--% my_command "\"    "\"

(문자열에 4 개의 공백을 보내야하지만 PowerShell은 배열로 구분 된 두 개의 문자열을 봅니다)

@rjmholt , 위 의

이전 의견 에서 사용할 기본 셸 실행 파일에 대한 질문을 해결했지만 다음과 같습니다.

다른 쉘이나 다른 언어가 이것을 구현합니까 아니면 이미 가지고 있습니까? 구문 수준에서 또는 다른 수준에서? 그렇다면 어떻게?

_explicit delimiters_를 사용하지 않고 _interpolation_을 허용하지 않고 구문 수준에서이 작업을 수행 한 다른 언어를 알지 못합니다.
예를 들어 perl 에는 쉘 명령을 실행하기위한 `...` 가 있으므로, 예를 들어 Unix의 스크립트에서 다음 명령을 실행할 수 있습니다.
my $foo='/'; print `ls $foo | cat -n`

주요 측면은 명시 적 구분 기호의 사용과 호출자의 값을 통합하는 기능입니다. 둘 다 --% 문에 대한 현재 제안에서 누락되었습니다.

앞서 언급했듯이 우리는 새로운 _operator_ (또는 일종의 구분자 기반, 선택적으로 보간 구문)에 대해이 접근 방식을 _ 사용할 수 있지만 _ 그럴 가치가 없다고 생각합니다.
ins "ls $foo | cat -n" (또는 here-string 변형)은 언어에 추가적인 복잡성을 가하지 않고 가능합니다.

perl 는 (적절한) 구문 수준의 솔루션을 제공합니다. _ 그 자체가 셸은 아니지만 _ 가능한 한 편리하게 셸 호출을하기를 원하기 때문입니다.

대조적으로, 우리는 쉘 (너무)이며, 추가 구문없이 쉘 스타일 호출을 _directly_ 제공합니다 (현재 결함은 있지만-# 1995 참조).
_ 다른 셸의 _ 호출을 가능한 한 쉽게 만들기 위해 특별한 구문을 제공하는 것은 불필요 해 보입니다.

뿡 빵뀨

_ 우리 (및 PowerShell)가 기본 실행 파일을 실행한다는 것을 알고 있다면 왜 "기본 연산자 호출"이 필요합니까? _

PowerShell이 ​​입력 문자열을 구문 분석하고 CommandAst를 가져 오면 PowerShell은 명령을 검색합니다.
명령이 기본 명령 인 경우 PowerShell은 ast를 NativeCommandProcessor로 변환합니다.
Ast 범위 (즉, 입력 문자열)를 다시 구문 분석하여 기본 실행 파일 이름 / 경로 및 나머지 문자열을 OS 규칙에 따라 인수 또는 인수로 가져 오는 경우에 새로운 (실험용 NativeCommandProcessor)를 구현할 수 있습니다.

사용자가 쉘에서 복사-붙여 넣기를 원하면 "cmd"또는 "bash"를 입력해야합니다. 이는 편집없이 작동합니다.
사용자가 복사-붙여 넣기를 원하는 경우 기본 명령 줄은 g++ timer.cpp @conanbuildinfo.args -o timer --std=c++11 처럼 작동합니다.

하지만 우리가 그렇게했다면 기본 명령과 함께 PowerShell 구문을 사용할 수 없게되지 않을까요? sc.exe query $serviceName 처럼 $serviceName 를 리터럴 문자열로 전달할까요?

하지만 우리가 그렇게했다면 기본 명령과 함께 PowerShell 구문을 사용할 수 없게되지 않을까요? sc.exe query $serviceName 처럼 $serviceName 를 리터럴 문자열로 전달할까요?

--% 옵션은 이러한 요구를 해결하기위한 것이 아닙니다.

sc.exe query $serviceName 은 &"<cmd>"

--% 옵션은 이러한 요구 사항을 해결하기위한 것이 아닙니다.

sc.exe query $serviceName 은 &"<cmd>"

예, 저는 그것이 @iSazonov 가 언급하는 것이라고 생각하지 않습니다. 매개 변수 바인딩이 기본 명령에 대해 작동하는 방식에 대한 일반적인 변경을 제안하는 것처럼 읽고 있습니다.

예, 저는 그것이 @iSazonov 가 언급하는 것이라고 생각하지 않습니다. 매개 변수 바인딩이 기본 명령에 대해 작동하는 방식에 대한 일반적인 변경을 제안하는 것처럼 읽고 있습니다.

주님, 그러지 않기를 바랍니다.

주님, 그러지 않기를 바랍니다.

어 때때로 초록을 브레인 스토밍 할 때 명백한 것을 잊기 쉽습니다. 나는 공정하게 우리 모두가 그것을 읽고 얼마나 깨질 지 깨닫지 못하고 즉시 구현을 생각하기 시작했습니다.

또는 나는 명백한 것을 놓치고 있으며 제안되는 것이 전혀 아닙니다 😁

@essentialexch , 다시

sc.exe query $serviceName 은 &"<cmd>"

& "<cmd>" 는 <cmd> 가 단순한 명령 _name 또는 path_로 평가되는 경우에만 작동합니다. _ 인수를 포함하지 않음 _-인수는 개별적으로 개별적으로 전달되어야하며, 그 자체로는 "...." 가 필요하지 않습니다. 확장 될 변수 참조에 대한 인용 (예 :
$exe = 'findstr'; & "where.exe $exe" 는 의도적으로 실패했습니다. & "where.exe" $exe 여야합니다 (여기서 큰 따옴표는 선택 사항입니다. 생략하면 & 도 선택 사항입니다.)

예, 저는 그것이 @iSazonov 가 언급하는 것이라고 생각하지 않습니다. 매개 변수 바인딩이 기본 명령에 대해 작동하는 방식에 대한 일반적인 변경을 제안하는 것처럼 읽고 있습니다.

내 제안 은 가능한 한 간단하게 # 1995를 수정하는 것입니다. 원인 보간이 작동하지 않습니다. 이유는 최종 제안이 아닙니다. 몇 분 안에 수정 사항을 구현할 수있는 방법을 보여줍니다. 그리고 주로 @ mklement0이 지적했듯이 호출 네이티브 연산자가 전혀 필요하지 않다는 것을 보여줍니다.

구문 분석하지만 공백으로 분할하면 잘못된 결과가 제공됩니다.

@rjmholt 예,하지만 당신이 생각을 잡는 것 같아요.
CommandAst의 첫 번째 자식은 기본 명령이 BareWord 인 StringConstantExpressionAst입니다. CommandAst Extent에서 맨 단어를 잘라내어 ast-s 변경없이 매개 변수 목록을 가져올 수 있습니다. 그러나 매개 변수 목록을 유지하기 위해 새 ast를 추가 할 수도 있습니다.
아래에서 논의를 요약하고 싶고 복잡해 보이는 일부 개선 사항을 구현해야한다고 생각하기 때문에 설명을 위해 시간을 할애합니다.하지만 간단하게 구현할 수 있고 __ 이전 호환성을 위해 쉽게 선택 해제 할 수 있습니다 __.

@ SteveL-MSFT의 초기 제안 의도는 주요 변경 사항을 피하는 것이 었습니다.
이 토론이 # 1995 및 # 12975와 같은 모든 _fundamental_ 문제를 해결하지 못하기 때문에 새로운 구문이 필요하지 않다는 것을 보여준 @TSlivede 및 @ mklement0에 동의합니다. 다른 한편으로는 언어에 복잡성을 더하는 반면, 우리는 반대로 네이티브 애플리케이션과의 작업을 _ 단순화 _ 원합니다.

__ 앞으로 나아갈 수있는 유일한 방법은 브레이킹 체인지 이상을 만드는 것입니다 .__ (이후 일부 시나리오에서도 새 연산자 또는 cmdlet이 유용 할 수 있습니다.)

사용 사례와 사용자 기대치의 요약부터 시작해야합니다.
위 의 @rkeithhill 의 멋진 게시물을 참조하십시오.

1. 사용자는 보간을 활성화 / 비활성화하려고합니다.
   PowerShell에는 이미 작은 따옴표와 큰 따옴표가있는 string / here-string이 있습니다.
   우리의 목표는 어떻게 적용 / 조정 / 향상하는지 이해하는 것입니다.

2. 사용자는 실행 파일이나 셸을 실행하려고합니다.

   • 모든 실행 파일-명령은 앱 이름으로 시작하고 인수를 따릅니다.
     
     
     
     • 보간 있음 / 없음
     
     
     • 단일 회선 / 다중 회선
     
     
   • 인수가 _script_이기 때문에 쉘은 아마도 특별한 경우 일 것입니다.
     
     
     
     • 복사-붙여 넣기 시나리오에서 사용자는 보간을 원하지 않고 단일 및 다중 라인을 원합니다.
     
     
     • 스크립트 시나리오에서 사용자는 보간을 활성화 / 비활성화하고 단일 및 다중 라인을 원합니다.
     
     

   생각 :
   따라서 복사-붙여 넣기 시나리오 동작이 기본값이어야한다고 생각합니다.
   줄 종결자는 실행 파일 (bash에서는, PowerShell에서는`)에 따라 다릅니다. 이것은 우리가 다음과 같이 생각하게합니다.
   (1) 쉘은 실행 파일로 명시 적으로 명시되어야합니다.
   (2) 아마도 여러 줄로 된 실행 파일은 셸을 통해 호출해야하거나 특수 구문 분석을 수행해야합니다 (종결자를 제거하고 이스케이프 문제로 돌아가는 인수 목록 작성).
   (3) PSReadline에서 복사-붙여 넣기 시나리오를 해결할 수 있습니다. 버퍼를 올바른 PowerShell 명령으로 변환 할 수 있습니다.

3. 사용자는 한 줄과 여러 줄을 원합니다.

   • 아마도 우리는 이전에 논의 된 일부 시나리오를 다루기 위해 한 줄에 대한 here-strings를 향상시켜야합니다.
   • 2 참조-(2)-항상 여러 줄에 쉘을 사용하거나 특수 구문 분석을 구현하십시오.

@TSlivede 와 @ mklement0 이 이전의 생각과 결론을 업데이트 할 수 있었지만 이제는 브레이킹 체인지 (들)의 수용을 기반으로 할 수 있기 때문에 더 많이 쓰고 싶지 않습니다. 나는 새로운 이슈를 열고 (그리고 모든 이전 이슈를 닫고), 모든 사용 사례를 열거하고 (@ @rkeithhill 's로 시작하여 더 추가) Pester 테스트를 생성 할 것을 요청합니다.이 문제를 해결하는 좋은 단계가 될 것입니다.

Invoke-Shell (Invoke-NativeShell), Test-Arguments (예 : 네이티브 앱이 사용자에게 도움을주고 표시하는 것을 보여주는 echoargs.exe), Convert-Arguments ( 사용자 입력을 오른쪽 이스케이프 인수로 변환).

추신 : 위에서 보여 드렸듯이 한 줄 동작은 런타임에 이전 버전과의 호환성을 위해 쉽게 옵트 아웃 할 수 있습니다.

줄 종결자는 실행 파일 (bash에서는, PowerShell에서는`)에 따라 다릅니다.

\ 은 (는) bash 의 줄 종결자가 아닙니다.

원인 보간이 작동하지 않습니다. 이유는 최종 제안이 아닙니다. 몇 분 안에 수정 사항을 구현할 수있는 방법을 보여줍니다. 그리고 주로 @ mklement0이 지적했듯이 호출 네이티브 연산자가 전혀 필요하지 않다는 것을 보여줍니다.

리포지토리 만 삭제하면 몇 분 안에 모든 버그를 수정할 수있는 것과 같은 방식입니다. 그것은 당신이 제안하는 꽤 엄청난 휴식입니다. 단지 가설이라고하더라도 그것이 어떻게 도움이되는지 모르겠습니다.

단지 가설이라고하더라도 그것이 어떻게 도움이되는지 모르겠습니다.

@SeeminglyScience 우리는 다른 맥락에있는 것 같습니다. 나는 우리가 파서를 깨뜨리지 않고 브레이킹 체인지로 한 줄 네이티브 호출에 대한 수정을 구현할 수 있다고 말한다. 즉, 어떤 새로운 동작을 구현하든 관계없이 즉시 동작을 전환 할 수 있습니다.

즉, 어떤 새로운 동작을 구현하든 관계없이 즉시 동작을 전환 할 수 있습니다.

내가 놓친 것은 명시 적으로 요청하지 않고 (콜 네이티브 연산자와 같이) 즉시 해당 동작을 전환하는 방법입니다.

뿡 빵뀨

_ 우리 (및 PowerShell)가 기본 실행 파일을 실행한다는 것을 알고 있다면 왜 "기본 연산자 호출"이 필요합니까? _

PowerShell이 ​​입력 문자열을 구문 분석하고 CommandAst를 가져 오면 PowerShell은 명령을 검색합니다.
명령이 기본 명령 인 경우 PowerShell은 ast를 NativeCommandProcessor로 변환합니다.
Ast 범위 (즉, 입력 문자열)를 다시 구문 분석하여 기본 실행 파일 이름 / 경로 및 나머지 문자열을 OS 규칙에 따라 인수 또는 인수로 가져 오는 경우에 새로운 (실험용 NativeCommandProcessor)를 구현할 수 있습니다.

사용자가 쉘에서 복사-붙여 넣기를 원하면 "cmd"또는 "bash"를 입력해야합니다. 이는 편집없이 작동합니다.
사용자가 복사-붙여 넣기를 원하는 경우 기본 명령 줄은 g++ timer.cpp @conanbuildinfo.args -o timer --std=c++11 처럼 작동합니다.

그 의미를 확인하고 싶습니다. 외부 실행 파일을 호출 할 때 기본적으로 모든 powershell 구문을 무시할 것을 제안합니까?

구체적으로 말하면 다음과 같습니다. 예를 들어

/bin/echo (1..5)

powershell에서 더 이상 1 2 3 4 5 를 출력하지 않지만 대신 (1..5) 리터럴을 출력해야합니까?

그것이 실제로 당신이 제안하는 것이라면, 내가 말해야 할 것보다 : 그것은 끔찍한 생각이라고 생각합니다.

이는 작업을 단순화하지 않습니다 (외부 실행 파일은 이제 내부 cmdlet과 구문 상 다르게 동작 함). 또한 # 1995 IMHO ...로 아무것도 수행 할 필요가 없습니다.

뿡뿡
위에서 :

• 다른 쉘이나 다른 언어가 이것을 구현합니까 아니면 이미 가지고 있습니까? 구문 수준에서 또는 다른 수준에서? 그렇다면 어떻게?

내 마음에 떠오르는 유일한 것은 ipythons ! operator입니다 .

ipython 출력에서 !ps -'fax' || true 실행 :

  261 pts/0    Sl     0:00          \_ /usr/bin/python /usr/bin/ipython
  311 pts/0    S      0:00              \_ /bin/bash -c ps -'fax' || true
  312 pts/0    R      0:00                  \_ ps -fax

( ps는 인수 주위에 따옴표를 표시하지 않지만 ps -'fax' || true 는 실제로 bash에 대한 단일 인수로 제공됩니다.)

그러나이 기능은 여전히 ​​파이썬 변수를 해당 명령 ( {pyvar} )으로 보간 할 수 있습니다.

그리고 @ mklement0 의 예 와 유사하게 ipython은 이것을 구현합니다.

그 자체가 껍질이 아니기 때문에

ipython이 python 구문 만 허용한다면 셸로서 그다지 유용하지 않을 것이므로이 구문이 명령을 bash로 전달하여 셸로 사용할 수 있도록합니다. 다른 쉘을 호출하기위한 특수 구문을 추가하는 것은 매우 이상한 것, 그래서 다른 한편 주장에 PowerShell은, (# 1995가 해결 될 때까지, 나는 그것이 쉘이라고 말을하지 않습니다) 쉘이 될 수 있습니다.

이와 같은 것이 실제로 구현 된 이유가 무엇이든간에 (희망적이지 않은 경우), "호출 쉘 연산자"로 --% 대신 ! 를 사용하는 것이 좋습니다.

! 는 사람들이 추측 할 수있는 것입니다 (ipython (또는 vim 명령 모드 또는 less 또는 ftp )에서 해당 목적으로 ! 를 알고 있기 때문입니다.) )

반면에 --% 은 입력하기가 더 어렵고 추측하기 어렵고 가장 중요한 것은 다음과 같습니다. --% 의 현재 사용법은 "다른 쉘로 물건을 전달"하는 것과 거의 공통점이 없다고 생각합니다. 행동. 현재 --% 는 cmd 구문의 정확히 하나의 요소 인 변수 대체를 에뮬레이트합니다. 이스케이프 문자 ^ 를 지원하지 않으며 파일로의 리디렉션을 허용하지 않습니다. 현재 --% 에 대해 다소 유용한 유일한 것은 lpCommandLine 그대로 내용을 전달하는 기능입니다. 그러나 제안 된 "call shell operator"가 잘하지 못하는 부분입니다.

제안 된 "call shell operator"와 현재 --% 사이의 또 다른 차이점 (이미 언급 했음) : 하나는 파이프로 끝나고 다른 하나는 그렇지 않습니다. 신규 사용자에게는 매우 혼란 스럽습니다. 반면에 ! 는 지금까지 테스트 한 모든 응용 프로그램 (ipython, vim, less, ed 등)의 쉘에 | 를 전달합니다.

HELP about_Logical_Operators -S

예, ! 자체는 언어의 논리 부정 연산자이기 때문에 문제가됩니다.

BTW 대체 제안 중 하나는 &! -일종의 "콜 네이티브 / 쉘"연산자였습니다.

@TSlivede 가 "이런 일이 어떤 이유로 실제로 구현

• $ 가 _both_의 변수시길로 사용된다는 점을 감안할 때 연산자 / 문 (_ 개별 인수 포함 _)은 I-want-to-use-PowerShell-values-in-the-native-command-line 문제를 명확하게 해결할 수 없습니다. PowerShell 및 POSIX 유사 셸.

• 전체 네이티브 명령 줄 주위에 명시적인 구분 기호가없는 연산자 / 문은 네이티브 명령 줄 끝 문제를 해결할 수 없습니다.

@ PowerShell / powershell-committee는 오늘 이것을 논의했습니다. 이 시점에서 초기 문제 진술에 대한 합의 나 해결 방법에 대한 설계가없는 것처럼 보이므로 안정적인 설계로 7.1에이를 수 있다고 믿지 않습니다.

@ PowerShell / powershell-committee는 오늘 이것을 논의했습니다. 이 시점에서 초기 문제 진술에 대한 합의 나 해결 방법에 대한 설계가없는 것처럼 보이므로 안정적인 설계로 7.1에이를 수 있다고 믿지 않습니다.

댓글 182 개!

이것에 대한 좋은 토론이있었습니다! 이 문제에 대한 새로운 의견을 계속 모니터링하겠습니다. 커뮤니티에서이 문제와 관계없이 PSGallery에 게시 된 Invoke-NativeCommand 유형 cmdlet을 구현하는 것이 좋습니다.

https://github.com/PowerShell/PowerShell/issues/13068#issuecomment -662732627에서 타협했지만 매우 유용한 솔루션이 있었을 때 불행하다고 생각합니다. 나는 당신이 합의를 원한다는 것을 알고 있지만 때로는 타협이 일어날 수있는 최선의 방법입니다. 아니요, 완벽하지는 않지만 한 줄짜리 SO 솔루션이 매우 유용합니다. 적어도이 사람의 의견으로는.

@essentialexch , 우리는 PowerShell 팀 내에서 합의조차 없습니다.

이것이 연기되었으므로 헬퍼 구현은 어떻습니까?

Invoke-Shell (Invoke-NativeShell), Test-Arguments (예 : 네이티브 앱이 사용자에게 도움말을 가져오고 표시하는 것을 보여주는 echoargs.exe), Convert-Arguments (사용자 입력을 오른쪽 이스케이프 인수).

Test-Arguments가 매우 유용 할 수 있다고 생각합니다.

저는 방금 Native , ( Install-Module Native -Scope CurrentUser ) 모듈을 게시했습니다.이 모듈은 위 의 @rkeithhill 의 주석에서

개념적 안개를 없애고 싶다면 유스 케이스를 다르게 구성해야한다고 생각합니다.
_ 그 중 어느 것도 구문 분석을 변경할 필요가 없습니다 _.

사용 사례 [네이티브 쉘 호출] :

_ 개별 명령 _ (사용 사례 1) 또는 전체 _ 다중 명령 명령 줄 _ (사용 사례 2) _ 플랫폼 네이티브 셸용으로 작성된 _ (이 문제)을 실행하려고합니다.

• 다른 셸의 구문을 사용하고 있으므로 _it_가 구문 분석을 수행하도록 명령 (줄)을 _ 단일 문자열 _로 대상 셸에 전달합니다. PowerShell의 문자열 보간은 전달 된 문자열에 PowerShell 값을 포함하는 기능을 제공합니다 (사용 사례 2a).
• ins ( Invoke-NativeShell ) 는 이러한 사용 사례를 다룹니다.

# Use case 1: Single executable call with line continuation, on Unix.
@'
tar -cvpzf /share/Recovery/Snapshots/$(hostname)_$(date +%Y%m%d).tar.gz \
    --exclude=/proc \
    --exclude=/lost+found 
'@ | ins

# Use case 2: Entire Bash command line (also with line continuation)
@'
ps -o pid,args | awk \
  '/pwsh/ { print $1 }'
'@ | ins

# Use case 2a: Entire Bash command line (also with line continuation) with string interpolation.
# Note the double-quoted here-string and the need to escape the $ that is for Bash as `$
$fields = 'pid,args'
@"
ps -o $fields | awk \
  '/pwsh/ { print `$1 }'
"@ | ins

# Alternative to use case 2a: pass the PowerShell value *as a pass-through argument*,
# which allows passing the script verbatim.
# Bash sees the pass-through arguments as $1, ... (note that the `awk` $1 is unrelated).
@'
ps -o $1 | awk \
  '/pwsh/ { print $1 }'
'@ | ins - 'pid,args'

here-string 구문은 가장 편리하지는 않지만 (따라서 인라인 변형을 구현하라는 제안-# 13204 참조) 사용하지 않습니다. 축어 명령의 경우 '...' 를 사용할 수 있습니다.이 경우 _doubling_ 포함 된 ' 만 필요합니다.

또한 다음 은 "StackOverflow 연산자"를 대체 하는

PSReadLine 키 핸들러를 $PROFILE 파일에 배치하면 Alt-v 를 사용하여 여기 문자열로 ins 대한 호출을 스캐 폴딩 할 수 있습니다. 현재 클립 보드 텍스트가 붙여 넣어집니다.Enter 는 호출을 제출합니다.

# Scaffolds an ins (Invoke-NativeShell) call with a verbatim here-string
# and pastes the text on the clipboard into the here-string.
Set-PSReadLineKeyHandler 'alt+v' -ScriptBlock {
  [Microsoft.PowerShell.PSConsoleReadLine]::Insert("@'`n`n'@ | ins ")
  foreach ($i in 1..10) { [Microsoft.PowerShell.PSConsoleReadLine]::BackwardChar() }
  # Comment the following statement out if you don't want to paste from the clipboard.
  [Microsoft.PowerShell.PSConsoleReadLine]::Insert((Get-Clipboard))
}

사용 사례 [직접 실행 가능한 호출] :

_ 개별 인수 _ (사용 사례 1a 및 3)와 함께 _PowerShell_의 구문을 사용하여 _ 단일 외부 실행 파일 _을 호출하려고합니다.

• 이것은 모든 셸의 핵심 요구 사항이며 강력하게 작동하는 것이 매우 중요합니다.

  • _its_ 파싱 _as-is_에서 발생하는 모든 인수를 대상 실행 파일로 전달할 수있는 PowerShell에 의존 할 수 있어야합니다. 현재는 그렇지 않습니다 .

• _PowerShell's_ 구문 및 _its_ 인수 모드 메타 문자를 이해해야합니다.

  • ` 는 이스케이프 문자와 줄 연속으로 사용된다는 점에 유의해야합니다.

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

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

# 1995가 수정되기를 기다리는 동안, 함수 ie (for i nvoke (external) e xecutable)은 단순히 직접 호출을 추가

# 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" }'

Native 모듈은 echoArgs.exe , dbea ( Debug-ExecutableArguments ) 명령과 유사합니다. Windows의 샘플 출력 :

# Note the missing first argument, the missing " chars., and the erroneous argument boundaries.
PS> dbea '' 'a&b' '3" of snow' 'Nat "King" Cole' 'c:\temp 1\' 'a \" b'
7 argument(s) received (enclosed in <...> for delineation):

  <a&b>
  <3 of snow Nat>
  <King>
  <Cole c:\temp>
  <1\ a>
  <">
  <b>

Command line (helper executable omitted):

  a&b 3" of snow "Nat "King" Cole" "c:\temp 1\\" "a \" b"

-UseIe ( -ie ) 스위치를 사용하여 dbea 를 통해 ie 를 통해 인수를 전달하도록 지시 할 수 있으며, 이는 문제가 해결되었음을 보여줍니다.

# OK, thanks to -UseIe
PS> dbea -UseIe '' 'a&b' '3" of snow' 'Nat "King" Cole' 'c:\temp 1\' 'a \" b'
6 argument(s) received (enclosed in <...> for delineation):

  <>
  <a&b>
  <3" of snow>
  <Nat "King" Cole>
  <c:\temp 1\>
  <a \" b>

Command line (helper executable omitted):

  "" a&b "3\" of snow" "Nat \"King\" Cole" "c:\temp 1\\" "a \\\" b"

참고 : # 1995가 수정되면 ie 는 더 이상 필요하지 않습니다. 순방향 호환성을 위해 ie 는 수정 사항을 감지하고 자동으로 연기하도록 설계되었습니다. 즉, 수정 사항이 적용되면 ie 은 (는) 대안 적용을 중지하고 효과적으로 직접 / & 호출처럼 작동합니다.

사용 사례 [직접 불량 Windows 실행 가능 호출] :

_Windows 전용 _에서 발생하는 두 가지 주요 문제가 있습니다.

• 가장 널리 사용되는 규칙과 다른 인용 요구 사항이 있는 "불량"실행 파일을 호출하고 있습니다. 예를 들어, msiexec.exe 및 msdeploy.exe 에서는 prop="<value with spaces>" 를 정확하게 인용해야합니다.-_value_ 부분 주위에 인용-비록 "prop=<value with spaces>" -전체 인용 인수-_should_ 동일해야합니다 (후자는 PowerShell-정당하게-뒤에서 수행하는 작업입니다).

• 공백은 포함하지 않지만 & , ^ 또는 | 와 같은 cmd.exe 메타 문자 _를 포함하는 _an 인수를 사용하여 _a 배치 파일 _을 호출합니다. 예 :

  • .\someBatchFile.cmd 'http://example.org/a&b'

  • PowerShell-정당하게- http://example.org/a&b _unquoted_ (포함 된 공백이 없기 때문에)를 전달하지만이 경우 배치 파일 호출이 중단됩니다. cmd.exe -부당하게-배치 파일에 전달 된 인수가 리터럴로 받아들이는 대신 cmd.exe 내부에 적용되는 동일한 구문 분석 규칙입니다.

  • 참고 : 배치 파일을 사용하여 기능을 _ 직접 _ 구현하는 것은 아마 줄어들고 있지만, 배치 파일 az.cmd 로 구현되는 Azure의 az CLI와 같이 _CLI 진입 점 _으로 사용하는 것은 여전히 ​​매우 일반적입니다.

참고 : ie 는 배치 파일과 msiexec.exe 및 msdeploy.exe 대해 이러한 시나리오를 자동으로 처리하므로 _most_ 호출에 대해 추가 노력이 필요하지 않습니다 . 그러나 _all_ "악성"실행 파일을 예상하는 것은 불가능합니다.

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

• cmd.exe 라는 경우 명령 줄의 인수에 자체 해석을 적용한 후 _does_ 지정된대로 인용을 유지하면 Windows에서 ins 호출에 위임 할 수 있습니다.

  • ins '.\someBatchFile.cmd "http://example.org/a&b"'
  • _expandable_ 문자열을 사용하는 경우 다시 명령 문자열에 PowerShell 값을 포함 할 수 있습니다.
    
    
    
    • $url = 'http://example.org/a&b'; ins ".\someBatchFile.cmd `"$url`""
    
    

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

  • .\someBatchFile.cmd --% "http://example.org/a&b"'
  • --% 가 구현되는 방식을 고려할 때 PowerShell 값을 포함하는 유일한 방법은 _aux를 정의하는 것입니다. 환경 변수 _ 및 %...% 구문으로 참조하십시오.
    
    
    
    • $env:url = 'http://example.org/a&b'; .\someBatchFile.cmd --% "%url%"
    
    

오류 처리

보류중인 https://github.com/PowerShell/PowerShell-RFC/pull/88 은 외부 (네이티브) 실행 파일과 더 나은 오류 처리 통합을 제공합니다.

그 동안 Native 모듈 에는 0이 아닌 종료 코드를 스크립트 종료 오류로 처리하는 애드혹 옵트 인을 위한 두 가지 기능이 포함되어

• ins 는 -e / -ErrorOnFailure 스위치를 지원합니다.이 스위치는 네이티브 셸을 호출 한 후 $LASTEXITCODE 가 0이 아닌 경우 오류를 발생시킵니다.

• iee 는 ie 대한 래퍼 함수로, 외부 실행 파일을 호출 한 후 $LASTEXITCODE 이 0이 아니면 오류를 발생시킵니다.

모듈과 함께 제공되는 명령에는 많은 미묘함이 있습니다.
상당히 광범위한 주석 기반 도움말이 충분히 다루기를 바랍니다.

개념적 안개를 없애고 싶다면 유스 케이스를 다르게 구성해야한다고 생각합니다.

큰! 이전에 게시 한 내용은 사람들이 더 나은 사용 사례를 만드는 것에 대해 생각하게하기위한 것입니다.

이전에 제안한 것과 다른 ins ( Invoke-NativeShell )의 몇 가지 중요한 측면을 명확히해야합니다. 목표는 bash 의 편재성을 설명하고 플랫폼간에 일관된 CLI를 제공하는 것이 었습니다.

• Unix 에서는 Bash의 편재성을 고려할 때 /bin/sh /bin/bash 대신 -UseSh ( -sh 와 함께 -UseSh /bin/sh 사용을 선택할 수 있습니다 -sh ) ( /bin/sh 는 /bin/bash 이 (가) 존재하지 않는 경우에 대비책 역할도합니다).

  • 호출 양식과 플랫폼간에 일관된 경험을 제공하기 위해 호출 이름 인 $0 를 설정하는 기능을 숨겼습니다. 즉, 모든 통과 인수는 $1 . 이는 파이프 라인에서 스크립트를 파이프 할 때 인수가 전달되는 방식과 사용자가 예상하는 것과 일치합니다.

# Script as argument
PSonUnix> ins 'echo $# arguments; echo "[$1] [$2]"' one two
2 arguments
[one] [two]

# Script via pipeline; note the "-" to signal that the script is piped.
PSonUnix> 'echo $# arguments; echo "[$1] [$2]"' | ins - one two
2 arguments
[one] [two]

# As an aside: script as argument, with pipeline input *as data*:
PSonUnix> 'one', 'two' | ins 'cat -n'
     1  one
     2  two

• 윈도우 I에 기술적 인 이유로 뒤에서 임시 _batch의 file_를 사용했다,하지만 난 배치 파일 구문의 사용은 (어쨌든 궁극적으로 더 나은 선택이라고 생각 %%i 보다는 %i 에서 for 루프 변수, % 를 %% 로 이스케이프하는 기능).

  • 배치 파일을 사용하면 Unix에서와 같이 통과 인수도 지원할 수 있습니다.

# Script as argument
PSonWin> ins 'echo [%1] [%2]' one two
[one] [two]

# Script via pipeline; note the "-" to signal that the script is piped.
PSonWin> 'echo [%1] [%2]' | ins - one two
[one] [two]