4

多くのシェルスクリプトとコマンドは、短いオプションと長いオプションの両方をサポートしています。

$ ls -a
$ ls --all

しかし、私はその理由がわかりません。なぜ短いオプションよりも長いオプションを好むのでしょうか。また、両方をサポートする必要があるのはなぜですか（独自のスクリプトを実装する場合）。

4

3 に答える 3

3

歴史的に成長したと思います。短いオプションは、1文字をチェックするだけでよいため、実装が簡単ですが、可能なオプションの数には制限があります。長いオプションもより説明的です。

両方を自分で実装するという点では、ほとんどのライブラリでは、基本的に追加のコードを使用せずに、両方を同時に簡単に実装できます。長いオプションはより説明的であるため、私は長いオプションを使用する傾向がありますが、それは純粋に好みの問題です。

于 2012-05-27T21:40:18.150 に答える
3

なぜ誰かがロングよりショートを好むのでしょうか?

長いオプションは、何をしているかを明確にし、新しいユーザーに自信を与えるだけでなく、経験の浅いユーザーが何をしているのかを簡単に理解できるようにします。たとえば、おそらく実行しないでしょう:

# DO NOT DO THIS PLEASE PLEASE
rm / --no-preserve-root --force --recursive

しかし、あなたは実行するかもしれません:

# DO NOT DO THIS PLEASE PLEASE
rm -rf / --no-preserve-root

彼らがそれが何を意味するのか正確に理解していない場合。

上記のように、ユーザーが自分のしていることを絶対に望んでいることを確認し、--no-preserve-root悲惨な結果をもたらす可能性のあるコマンドの入力ミスを防ぐためにも使用できます。

なぜ両方をサポートする必要があるのですか?

まぁ、みんなそうだから。それは一種の歴史的なものであり、今では多くのユーザーがそれを期待するようになっています. 図書館getoptはあなたのためにそれをするのが好きなので、それを移植しない正当な理由はわかりません。

おまけ: なぜ誰かがショートよりロングを好むのでしょうか?

私がよく受けるもう 1 つの質問は、なぜ誰かが短いものから長いものを好むのかということです。はい、しかし、より経験豊富な人々はこれに腹を立てます。git commit -a -m 'message'よりも入力する方がはるかに高速ですgit commit --add --message 'message'。一部のライブラリでは、短いコマンドをチェーンすることもできるためcommand --long --another-long、command -la.

于 2012-05-27T21:51:03.617 に答える
1

必要なオプションの数が印刷可能な文字数よりも多い場合は、長いオプションが必要です。それは人間との相互作用についてであり、どちらの方法にも長所と短所があります。

于 2012-05-28T00:28:20.920 に答える