[解決済み] コマンドライン出力の抑制

質問

以下のような簡単なバッチファイルがあります。

エコーオフ

タスクキル /im "test.exe" /f > nul

ポーズ

"test.exe"が起動していないと、このメッセージが表示されます。

ERROR: プロセス "test.exe" が見つかりませんでした。

出力を NUL にリダイレクトしたのに、なぜこのエラーメッセージが表示されるのですか?

どうすればこの出力を抑止できますか？

どのように解決するのですか？

エラーメッセージはしばしば stderr ではなく stdout .

呼び出しをこれに変更します。

taskkill /im "test.exe" /f >nul 2>&1

で、すべてがよくなる。

これがうまくいくのは stdout はファイル記述子1であり stderr はファイルディスクリプタ2です。(0は stdin です)。その 2>&1 は出力ファイル記述子 2 を新しい値 1 からコピーしますが、これはちょうど null デバイスにリダイレクトされたところです。

この構文は多くの Unix シェルから（緩やかに）借用したものですが、シェルの構文と CMD.EXE の間には微妙な違いがあるため、注意が必要です。

更新しました。 という名前の"file"の特殊性をOPが理解していることは知っています。 NUL というファイルの特殊性を理解していることは知っていますが、コメントした人は理解していなかったので、その点についてもう少し詳しく脱線します。

MSDOS の初期のリリースまでさかのぼると、特定のファイル名がファイル システム カーネルによって先取りされ、デバイスを参照するために使用されていました。これらの名前の最も古いリストには NUL , PRN , CON , AUX と COM1 を通して COM4 . NUL はヌルデバイスです。これは常に読み取りまたは書き込みのために開くことができ、任意の量を書き込むことができ、読み取りは常に成功しますが、データは返されません。その他に、パラレルプリンタポート、コンソール、最大4つのシリアルポートがあります。MSDOS 5の時点では、さらにいくつかの予約名がありましたが、基本的な規約は非常によく確立されています。

Windows が作成されたとき、MSDOS カーネルの上にかなり薄いアプリケーション切り替えレイヤーとしてスタートし、したがって同じファイル名の制約がありました。Windows NT がそれ自体で真のオペレーティング システムとして作成されたとき、次のような名前が使用されました。 NUL と COM1 が機能するとあまりにも広く仮定されていたため、それらの削除を許可しました。しかし、新しいデバイスが常に、実際のファイルに対してその名前を使用する将来のユーザーをブロックするような名前を取得するという考えは、明らかに不合理です。

Windows NT とそれに続くすべてのバージョン (2K、XP、7、そして現在は 8) では、より精巧な NT 名前空間 を使用し、カーネル コードから、慎重に構築された移植性の低いユーザー空間コードまでをカバーします。この名前空間では、デバイス ドライバは \Device フォルダーを通して見ることができます。要求される後方互換性をサポートするために、デバイスドライバは \DosDevices フォルダを使用した特別なメカニズムがあり、任意のファイルシステムフォルダで予約されたファイル名のリストを実装しています。ユーザー コードは、通常の Win32 API の下の API レイヤーを使用してこの内部名前空間を参照することができます。 WinObj で、Microsoft の SysInternals グループから提供されています。

Windows におけるファイル (およびデバイス) の正式な名前を取り巻くルールの完全な説明については、こちらを参照してください。 MSDN のこのページ は、有益であると同時に困難なものです。このルールは ロット のような簡単な質問に答えることは実際不可能です。