回答:
あなたはあなた自身の質問に正しく答えました、それがまさにドットがパスにない理由です：
幼稚なウイルスや正直な間違いから保護するため。
もちろん、これは非常に不十分で役に立たないアンチウイルス対策であり、自分でパスにドットを追加することを妨げるものは何もありません。
-rfは、ディレクトリ内の孤立したファイルからではなく、これから保護されていることです（rm *面白くなります）;
-rfそもそもなぜファイルに名前を付けたのですか？;）
申し訳ありませんが、選択した回答へのコメントの形でこれをお願いしたいのですが、スーパーユーザーに関する担当者はまだいません。
セキュリティの答えは理にかなっていますが、「。」を付けると 最後にPATHで、シェルは実行可能ファイルを検索するとき、現在のディレクトリを最後に見て、セキュリティリスクを減らすべきではありませんか？$ PATHを順番に検索した場合、。/ lsを見つける前に/ bin / lsを見つけます。
したがって、「。」を付けるのはどれほど安全ではないのでしょうか。$ PATH環境変数の最後に？
私が提案するように動作します。テスト方法は次のとおりです。
まず、「。」を追加します PATH環境変数のENDに。
次に、〜/ dir1 / dir2 / test_which.rbなどのディレクトリに次のファイルを配置します。
#!/your/path/to/ruby
puts "this file is from the current directory"
そして、このファイルを/usr/bin/test_which.rbに配置します
#!/your/path/to/ruby
puts "this file is at /usr/bin/test_which.rb"
実行可能になるように、ファイルを必ずchmod + xしてください。
ここで、ディレクトリを〜/ dir1 / dir2に変更してtest_which.rbを実行すると、出力が表示されます
this file is at /usr/bin/test_which.rb実際、どこからでも "which test_which.rb"を実行すると、レポートされるはずです。
/usr/bin/test_which.rb次のように入力することにより、現在のディレクトリでファイルを実行できます。
./test_which.rbdcか、slまたはsduoシェルで、かつ「コマンドが見つかりません」ということで救われました。今まで。
ls（カラー出力など）をエイリアスしl、タイプミスを完全に排除しています。
「。」を持つセキュリティリスク以上のもの PATHでは、コマンドの実行が意図したとおりに動作することを確認することはほとんど不可能です。ランダムな名前の何千ものファイルを含む巨大なディレクトリで「zip」のようなコマンドを実行することを考えてください。それらの1つが実際に 'zip'という名前である可能性は無視できず、非常に理解しにくいエラーにつながります（実際にはファイルは実行可能である必要がありますが、これは発生する可能性があります）。
特に、これはユーザーのPATH変数を保持するスクリプトを作成する場合に当てはまります。適切に記述されたスクリプトは、すべてのコーナーケース（スペースを含むファイル名や「-」で始まるファイル名など）に対処する必要があります。しかし、システムコマンドの代わりに現在のディレクトリのファイルが実行されるのを防ぐことは実用的ではありません...
lsとそう/usr/bin/lsで./lsないことを知っていることが好きです。また.、パスの最後に追加する方法を知っている場合は、おそらく自分が何をしているのかを知っているというハードルがあります。根がなければならない決して持っていない.パスに、多くのシステムであっても、もはやでルートログをさせてください。