0

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/?の代わりにprogram /?)、これをサポートする必要がありますか、それともエラーを報告してすぐに終了する必要がありますか?

他に知っておくべき注意事項は何ですか? (以下の Anon. のコメントに加えて、「debug\program.exe」が存在する場合でも、「debug/program」は PATH から debug.exe を実行します。)

4

3 に答える 3

2

実際にはDOSシェルがこれを行っていると思います：

私の理解では、DOSがサブディレクトリをサポートする前から、DOSはコマンドライン オプション (つまり、"DIR /s") にスラッシュ (/) を使用することを選択していました。その後、サブディレクトリを導入した時点で、(UNIX の標準のように) パスの区切り記号としてスラッシュを使用できないことに気付き、代わりにバックスラッシュを使用する必要がありました。

また、DOS ではコマンド名と最初のパラメーターの間にスペースが必要ないことも要因の 1 つです。(つまり、「CD\」は「CD \」と同じです。)

上記の理由から、私の推測では、コマンド ラインを「誤って」解析しているのはプログラムではなく、代わりに「C:」を実行可能ファイル/コマンド名として使用し、残りを次のように使用しているDOS シェルです。コマンドライン引数。(もちろん、かなりのテスト アプリでこれを確認できますが、現時点ではコンパイラから離れています。)

于 2010-02-26T01:02:47.617 に答える
0

役立つかもしれないいくつかの提案があります。これらは、パラメーターとスイッチを処理するためだけに作成 (および使用) したクラスの結果です。

  • 引数配列をチェックして、パスに使用されている区切り文字と、スイッチ/パラメーターに使用されている区切り文字を確認します。

  • 私は個人的に、スイッチとパラメータを区別するために、一方にスラッシュを、他方にハイフンを使用しています。

  • 予想されるパラメーターまたはスイッチのいずれにも一致しないスイッチが渡された場合、複数のスイッチが 1 つのスラッシュだけで渡されたかどうかを確認します。これは、ユーザーが何かを間違って入力した場合に、ユーザーにさらに多くの問題を引き起こしました。たとえば、/d /e /l -or- /del SomeThing を探していて、ユーザーが de および l スイッチを渡すつもりで /del を入力したとします。

  • オブジェクトでは、スイッチを std:: コンテナーに詰め込み、パラメーターとパラメーター値を別の std:: コンテナーに入れます。これらは、コンシューマー アプリケーションが適切と判断したときに処理できるようになります。

于 2010-02-26T05:24:09.663 に答える
0

これを行うプログラムは、コマンド ライン引数にアクセスするGetCommandLine()代わりにを使用し、Windows のユーザー モード パスの代替可能性をargv[]考慮に入れていないと思います。/\

于 2010-02-26T01:01:06.770 に答える