これを行う正当な理由はありません。実際、起こる唯一の本当の効果は物事を遅くすることです。
これを行う正当な理由があると人々は考えるかもしれません。CMDを使用すると、次のような効果が得られます。これらの効果は、場合によっては一般的に有効です。
- 「
DIR
」のような内部コマンドを有効にします
- PATH変数などの環境変数を設定します
ただし、この場合、これらの利点はいずれも得られません。これら両方のシナリオを見てみましょう。
そのため、場合によっては、「CMD /C
」を使用すると便利な場合があります。たとえば、外部コマンドPSEXEC
(SysInternalsからダウンロード)を使用DIR
して、リモートコンピューターで " DIR
" を実行しようとすると、Windowsは " "コマンドを実行しようとします。サポートされている別の拡張子で終わる「DIR.EXE
」、「DIR.BAT
」、または「DIR
」ファイルがないため、Windowsはそのコマンドの実行に失敗します。(サポートされている拡張機能は、「ECHO %PATHEXT%
」を実行すると確認できます。)
ただし、このシナリオでは、「CMD /C DIR
」を実行しようとすると、Windowsが「CMD
」という名前の実行可能ファイルを検索し、それCMD
を見つけて、DIR
内部の「」コマンドを正常に実行するため、動作します。「CMD
」コマンドの一部。
この場合、powershell
「CMD /C powershell
」と同じくらい簡単に実行できるので、不要な「CMD /C
」のメリットは得られません。「CMD /C
」を入力する追加のステップを通過することで得られる唯一の利点は、コマンドライン「DIR
」または「COPY
」を実行するために例を変更しようとする場合に役立つ例を提供することです。より柔軟な例を持っていることは、一部の人々にとって役に立つかもしれません。人々が自分のしていることを知っているとき、それは本当に必要ありません。
環境変数を設定するという2番目の箇条書きについては、この特定のケースでは積極的に行っていないことでもあります。PATH環境変数を設定することで問題を解決していると考える人もいるかもしれません。ただし、コマンドを直接実行すると(たとえば、[スタート]メニューの[実行]メニューオプションから)、Windowsオペレーティングシステムは追加の場所でコマンドを検索する場合があります。たとえば、Windows XP以降では次を実行できます。
reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths"
実行するコマンドが「App Paths」の下にリストされている場合、Windowsはプログラムがパスになくても検出する場合があります。そのため、Windowsは、CMDが使用するPATHでCMDが見つけるものよりもさらに多くを見つける可能性があります。
可能な利点の1つは、%USERPROFILE%、%LOGONSERVER%、%TEMP%/%TMP%などの環境変数を参照できるようにCMDを実行したい場合ですが、そうしないので、 「CMD /C
」を実行する必要があります。
だから、あなたの特定の場合:それをする正当な理由はありません。あなたが達成している効果は、コンピューターにもっと多くの仕事をさせて、プロセスを遅くし、より多くのメモリを使用することです(それらはすべて現代の機器で無視できる量でしています)。
cmd /c
... の答えはどれも、コマンドが完了した後にウィンドウを開いたままにcmd /k
しておくという点でかなり異なります。おそらく、質問者はデバッグを目的として出力を見ることができるようにそのようにしたのでしょう。