0

「プログラミング関連ではない」として閉じられた多くの質問を見てきました (例: https://stackoverflow.com/questions/397854/what-process-accesses-my-hdd )

彼らのいくつかの代替サイト (stackoverflow) をテーマにしたフォーラムがあり、サイトの質問を最小限に抑えることを試みていることも理解しています。また、これは主観的すぎると主張する人もいるかもしれません。まあ、私は最初の答えに狂ったように炎上したので、ここに私の最初の質問があります。一部の規制当局を寄せ付けないように、疑似文脈ベース（危険なスタイル）でフレーム化してみます...

UNIX システムのレベルの議論をプログラミングと同じ領域に #include するのは公平ではないですか? 私が今まで使った中で最も便利な UNIX ツールの 1 つである strace/trus/par は、システム コール情報とレポートに基づいており、ltrace のような他のツールはライブラリに対して同様のことを行うことができます...

システム管理者、「qmail を X にするにはどうすればいいですか?」のようなこのフォーラムではなく、「dnotify に基づいて、私の smtp ウイルス スキャナは十分に高速ではありませんか?」ということには同意します。(回答) 「ねえ、inotify 使って」ってそんなに簡単に判別できるの？後者は、シェルまたは Linux カーネル システム コールのいずれかです。

私は標準についてはあまり詳しくありません (最近読みすぎました)。POSIX の「コマンド言語」にタグを追加して、決定的な情報を特定することに焦点を移します。

システム レベルの対話は、プログラミング インターフェイス (API)/ユーザー インターフェイス (シェル) の二重性 (特に UNIX の場合) のようなものです。

インクイジターのコンテキストが主にインターフェースベースであり、排他的なプログラミング/API応答を解決するのが簡単な採石場（または典型的なもの）である場合、人間と機械を同様に支援するために、ドメインの変更が必要な理由（知識の本体またはURLドメイン; )?

4

4 に答える 4

2

申し訳ありませんが、あなたが UNIX と Windows を区別しようとしているように見えますが、私には理解できません。両方を使用してプログラムする人にとって、カーネル サービスへの呼び出しがライブラリにあるかどうかの違いは重要ではないように思えます。違いは次のとおりです-呼び出しはプログラミングコンテキストで行われますか? たとえば、UNIX の cat コマンドに関する質問はここに属さないことをお勧めしますが、UNIX の read() システム コールに関する質問は、あるレベルで cat を使用する必要があります。

ああ、カーネルとシェルの間に「緊密な統合」はありません。

于 2009-07-05T09:33:03.047 に答える
2

UNIX システムのレベルの議論をプログラミングと同じ領域に #include するのは公平ではないですか? 私が今まで使った中で最も便利な UNIX ツールの 1 つである strace/trus/par は、システム コール情報とレポートに基づいており、ltrace のような他のツールはライブラリに対して同様のことを行うことができます...

デバッグ ツールの議論は、SO、IMO で完全に有効です。デバッグ ツールの質問が閉じられているのを見たことがありません。

したがって、あなたが参照しているクローズドな質問が「プログラムをデバッグするためにファイルにアクセスしているプロセスを見つけるにはどうすればよいか」であった場合、それはクローズされていなかったと思います。しかし、それは「寝室の雰囲気を改善するためにファイルにアクセスしているプロセスをどのように見つけるか」であり、プログラミングとは関係がありませんでした。

システム管理者の質問は別の場所にあります。Bash プログラミングはプログラミング関連ですが、システム ユーティリティはそうではありません。「Word 文書を 3 列でフォーマットする方法」はプログラミングとは関係なく、「VB スクリプトをプログラムして Word 文書をフォーマットする方法」と同じです。

于 2009-07-05T09:50:37.647 に答える
0

今日同じ質問をしたら、それも閉じられると思います。でも「プログラミング関係ない」というよりは、「サーバー障害に属している」ということになります。

あなたの質問が、私のプログラムが触れるファイル、つまり特に開発作業に関連するファイルを追跡したい場合、それは限界でしょう。

于 2009-07-05T10:42:38.210 に答える
0

システム管理者、「qmail を X にするにはどうすればいいですか?」のようなこのフォーラムではなく、「dnotify に基づいて、smtp ウイルス スキャナが十分に高速ではない」ということには同意します。(回答) 「ねえ、inotify 使って」ってそんなに簡単に判別できるの？後者は、シェルまたは Linux カーネル システム コールのいずれかです。

差別する必要はありません。誰かが smtp ウイルス スキャナを作成している場合、それはプログラミング作業であり、その方法に関する質問はプログラミングに関する質問です。次に、それが bash、アセンブリ、C++、または空白で記述されているかどうかは問題ではありません。

一方で、「Unix で実行されているプロセスを確認するにはどうすればよいですか?」と尋ねます。プログラミングの質問ではありません。はい、答えは、基本的にシステムコールのラッパーであるコマンドを使用することです。MS Word の「ファイルを保存」ダイアログも、書き込みファイル システム コールのラッパーです。それはプログラミング関連にはなりません。

問題がわかりません。

UNIX システム関連の質問がプログラミングの質問ではないでしょうか。そうでない場合、プログラミング/スクリプト言語とユーザー インターフェイスの境界はどこにありますか?

境界はここにあります：「質問はプログラミングの文脈で作られていますか？」一部の Unix コマンドの使用方法を尋ねるエンド ユーザーは、プログラミングに関する質問ではありません。しかし、自分のプログラムに Unix で何かをさせる方法を尋ねるプログラマーは、プログラミングに関連しています。

シェル コマンドとシステム コールが基本的に同じであることは問題ではありません。プログラミング コンテキストから呼び出された場合は、プログラミング関連です。そうでなければそうではありません。Windows でも同じように区別できます。「Python プログラムから CreateFile を呼び出すにはどうすればよいですか」と尋ねると、それは明らかにプログラミングに関連しています。しかし、「実行していたプログラムがクラッシュし、CreateFile が失敗したというエラー メッセージが表示されました。これはどういう意味ですか?」プログラミング関連ではありません。

1 つはプログラミング コンテキストから要求され、もう 1 つはたまたまシステム コールの名前が含まれているだけです。

疑問がある場合は、ウィキペディアの「プログラミング」の定義を次に示します。

コンピュータ プログラミング (プログラミングやコーディングと短縮されることが多い) は、コンピュータ プログラムのソース コードを記述、テスト、デバッグ/トラブルシューティング、および保守するプロセスです。

それは私にはかなり明確に思えます。ソースコードを読んだり書いたりしていますか? そうでない場合、それはほとんどプログラミングではありません。プログラミングによって作成されたユーティリティのユーザーであることで十分です。

于 2009-07-05T11:23:15.133 に答える