명령 줄 스위치가 실행 파일 경로에서 파싱되었습니다.

Question

Windows 프로그램이 명령 줄 스위치를 해당 실행 파일 경로에서 파싱하는 이유는 무엇입니까? (후자는 일반적으로 argv[0]으로 알려진 것.) 예를 들어

, xcopy : 나는 내 자신의 프로그램에

C:\Temp\foo>c:/windows/system32/xcopy.exe /f /r /i /d /y * ..\bar\ 
Invalid number of parameters 

C:\Temp\foo>c:\windows\system32\xcopy.exe /f /r /i /d /y * ..\bar\ 
C:\Temp\foo\blah -> C:\Temp\bar\blah 
1 File(s) copied 

따라야 할 어떤 행동?

공백없이 명령 줄 스위치를 입력해야하는 사용자가 많습니다 (예 : program /? 대신).이를 지원해야합니까, 아니면 그냥 오류를보고 즉시 종료해야합니까?

알고 있어야 할 다른주의 사항은 무엇입니까? ("debug \ program.exe"가있는 경우에도 "debug/program.exe"가 PATH에서 debug.exe를 실행한다고해서 아래의 Anon.의 주석 외에도)

Answer 1

대신 어떤 프로그램이든지 GetCommandLine()을 사용하게 될 것으로 기대합니다. argv[]을 사용하여 명령 줄 인수에 액세스하고 Windows의 사용자 모드 경로에 / 및 \의 대체 성을 설명하지 못했습니다.

Answer 2

나는 실제로 이렇게 도스 쉘 생각 :

나의 이해는 DOS 명령 줄 옵션에 대한 슬래시 (/) (즉, "DIR/S"), 도 전에를 사용하는 선택이다 DOS는 하위 디렉터리을 지원합니다. 나중에 하위 디렉토리를 도입하자마자 경로 구분 기호로 슬래시를 사용할 수 없다는 것을 알게되었으므로 (대신 UNIX에서는 표준으로 사용됨) 대신 백 슬래시를 사용해야했습니다.

또한 DOS는 명령 이름과 첫 번째 매개 변수 사이에 공백이 필요하지 않습니다. (즉, "CD"는 "CD"와 동일합니다.)

위의 이유로 인해 "잘못"명령 줄을 구문 분석하는 프로그램이 아닌 것 같습니다. DOS 쉘은 실행 파일/명령 이름으로 "C :"를 사용하고 나머지는 명령 줄 인수로 사용합니다. (물론, 꽤 테스트할만한 앱이이를 검증 할 수 있었지만, 지금은 컴파일러에서 멀리 떨어져 있습니다.)

Answer 3

나는 몇 가지 제안을했습니다. 이는 매개 변수와 스위치를 처리하기 위해 만든 클래스의 결과입니다.

• 경로에 사용되는 구분 기호와 스위치/매개 변수에 사용되는 구분 기호를 확인하려면 인수 배열을 확인하십시오.

• 필자는 스위치와 매개 변수를 하나씩 슬래시를 사용하고 다른 하나는 하이픈으로 개인적으로 구분합니다.

• 예상되는 매개 변수 나 스위치와 일치하지 않는 스위치가 전달 된 경우 여러 개의 스위치가 하나의 슬래시로 전달되었는지 확인합니다. 이 오류로 인해 사용자가 잘못 입력 한 경우 사용자에게 더 많은 문제가 발생하게됩니다. 예를 들어, 내가/d/e/l -or-/del SomeThing을 찾고 사용자가/d/e 스위치를 전달할 의도로/del을 입력했다면

• 개체에서 스위치를 std :: container에 넣고 다른 매개 변수와 매개 변수 값을 다른 std :: container에 씁니다. 그러면 소비자 응용 프로그램에서 처리 할 수있게되어 적합하다고 판단됩니다.