PowerShell-시작 프로세스 및 Cmdline 스위치


79

이 잘 실행할 수 있습니다.

$msbuild = "C:\WINDOWS\Microsoft.NET\Framework\v3.5\MSBuild.exe" 
start-process $msbuild -wait

하지만이 코드 (아래)를 실행하면 오류가 발생합니다.

$msbuild = "C:\WINDOWS\Microsoft.NET\Framework\v3.5\MSBuild.exe /v:q /nologo" 
start-process $msbuild -wait

시작 프로세스를 사용하여 MSBuild에 매개 변수를 전달할 수있는 방법이 있습니까? 나는 시작-프로세스를 사용하지 않는 것에 개방적이다. 내가 그것을 사용한 유일한 이유는 "명령"을 변수로 가져야한다는 것이었다.

한 줄에
C : \ WINDOWS \ Microsoft.NET \ Framework \ v3.5 \ MSBuild.exe / v : q / nologo
가있는 경우 Powershell에서 어떻게 처리됩니까?

대신 eval () 종류의 함수를 사용해야합니까?


start-process에 대한 대안 은 blogs.msdn.com/powershell/archive/2007/01/16/… 을 참조하십시오 .
i_am_jorf

감사합니다 jeffamaphone, 이것은 또한 좋은 참조 정보였습니다.
BuddyJoe

1
Start-Process는 V2의 새로운 기능입니다. 그 게시물의 정보는 매우 좋지만 일부는 V2에서 더 이상 실제로 필요하지 않습니다.
EBGreen

Start-Process 자체가 V2의 새로운 기능입니까? 좀 더 자세히 설명해 주 시겠어요? 테스트를 위해 V1이 설치된 컴퓨터가 없습니다.
BuddyJoe

1
나는 단지 Start-Process 커맨드 렛이 V1에 존재하지 않았다는 것을 의미합니다. V1에서는 Jef가 링크 한 블로그 게시물에 나열된 방법 중 하나를 사용해야했습니다.
EBGreen

답변:


124

인수를 별도의 매개 변수로 분리하고 싶을 것입니다.

$msbuild = "C:\WINDOWS\Microsoft.NET\Framework\v3.5\MSBuild.exe"
$arguments = "/v:q /nologo"
start-process $msbuild $arguments 

15
$args변수 이름이 작동하지 않으므로 예약되어 있습니다. 사용 $arguments또는 그 대신 다른 것
joshcomley

1
제안 대기열이 가득 찬 것처럼 보이지만 독자들에게 -ArgumentList문자열을 찾고 있다는 것을 이해하도록 권하고 싶습니다. 따라서 PowerShell이 ​​잠재적으로 언 롤링하는 방식 때문에 쉼표로 구분 된 문자열 (기술적으로 배열)이있는 다른 답변의 예가 작동 할 수 있지만 배열에서 인수 목록을 전달하려면 미리 문자열로 "압축 해제"하는 것이 가장 좋습니다.
dragon788

3
@ dragon788, get-help start-process-ArgumentList 예상String[]
asynchronos

60

명시 적 매개 변수를 사용하면 다음과 같습니다.

$msbuild = 'C:\WINDOWS\Microsoft.NET\Framework\v3.5\MSBuild.exe'
start-Process -FilePath $msbuild -ArgumentList '/v:q','/nologo'

편집 : 따옴표.


나는 그들없이 괜찮을 것이라고 생각하지만, 나는 그것을 편집 할 수 있도록 확실히 그들과 함께 괜찮을 것
EBGreen

4
사용하기 더 안정적인 것 같다-ArgumentList ('/v:q','/nologo')
피터 테일러

1
Powershell은 너무 장황합니다. git gui &-얼마나 간단합니까 (물론 * nix)! 비교 start-Process git -ArgumentList gui. 도움이되지 않는다는 것을 알고 있습니다. 저는 최근에 Powershell을 가지고 놀았고 멋진 것들을 많이했습니다. 그러나 장황함은 살인자입니다!
HankCa 2017

1
글쎄, 당신이 원하는 경우에만 장황합니다 : start git -args gui도 작동합니다. 나는 이것이 * nix보다 더 장황하다는 것을 알고 있습니다. 요점은 탭 완성 및 별칭을 사용하면 실제 키 입력 수가 상당히 줄어든다는 것입니다. 또한 장황함은 powershell을 전혀 모르는 사람이 PS 명령을 읽고 수행하는 작업을 더 쉽게 이해할 수 있음을 의미한다고 덧붙일 것입니다. 철학의 차이 일뿐입니다.
EBGreen 2017

@HankCa,sajb { git gui }
asynchronos

7

경고

Powershell에서 만든 cmd.exe 창에서 PowerShell을 실행하는 경우 두 번째 인스턴스는 더 이상 작업이 완료 될 때까지 기다리지 않습니다.

cmd>  PowerShell
PS> Start-Process cmd.exe -Wait 

이제 새 cmd 창에서 PowerShell을 다시 실행하고 그 안에서 두 번째 cmd 창을 시작합니다. cmd2> PowerShell

PS> Start-Process cmd.exe -Wait
PS>   

PowerShell의 두 번째 인스턴스는 더 이상 -Wait 요청을 따르지 않으며 모든 백그라운드 프로세스 / 작업은 아직 실행 중이더라도 '완료 됨'상태를 반환합니다!

내 C # Explorer 프로그램을 사용하여 cmd.exe 창을 열고 PS가 해당 창에서 실행될 때 이것을 발견했으며 -Wait 요청도 무시합니다. cmd.exe의 'win32 작업'인 모든 PowerShell이 ​​대기 요청을 처리하지 못하는 것으로 보입니다.

Windows 7 / x64에서 PowerShell 버전 3.0으로이 문제를 겪었습니다.


5

특히 호출 된 응용 프로그램의 출력을 파이프해야 할 때 cmd를 사용하는 것이 대안으로 잘 작동 함을 발견했습니다 (특히 msbuild와 달리 로깅이 내장되지 않은 경우).

cmd /C "$msbuild $args" >> $outputfile


2

OP가 다른 많은 것과 함께 Start-Process cmdlet을 제공하는 PowerShell 커뮤니티 확장을 사용하지 않는 한. 이 경우 Glennular의 솔루션은 pscx \ start-process의 위치 매개 변수와 일치하기 때문에 처리됩니다. -path (position 1) -arguments (positon 2).

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.