0

コマンド ライン パーサーを作成していて、オプションのバンドルをサポートしたいと考えています。ただし、発生する可能性のあるあいまいさと競合を処理する方法がわかりません。次の 3 つのケースを考えてみましょう。

1.

-I accepts a string

"-Iinclude" -> Would be parsed as "-I include"

2.

-I accepts a string
-n accepts an integer

"-Iincluden10" -> Would be parsed as "-I include -n 10" because the 'cluden10' after the first occurrence of 'n' cannot be parsed as an integer.

3.

-I accepts a string
-n accepts an integer
-c accepts a string

"-Iin10clude" -> ??? What now ???

最後の文字列を処理するにはどうすればよいですか? 解析には複数の方法がありますが、あいまいさについてユーザーに通知するエラーをスローするだけですか、それとも最も生成量の多い文字列を解析することを選択するか、つまり「-I i -n 10 -c lude」として選択しますか?

詳細な規則をオンラインで見つけることができませんでしたが、個人的には、これをあいまいなエラーとしてフラグを立てます。

4

1 に答える 1

2

私の知る限り、コマンド ライン パラメータの解析に関する標準はなく、クロスプラットフォームのコンセンサスさえありません。したがって、私たちにできる最善のことは、常識と最小の驚きの原則に訴えることです。

Posix 標準では、コマンドライン パラメータを解析するためのガイドラインがいくつか提案されています。これらは単なるガイドラインです。リンクされたセクションが示すように、一部の標準シェル ユーティリティは準拠していません。また、Gnu ユーティリティはすべて Posix ガイドラインに準拠することが期待されていますが、通常、「長い」パラメータの使用など、いくつかの点で逸脱しています。

いずれにせよ、グループ化についてPosixが言うことは次のとおりです。

オプション引数のない 1 つ以上のオプションの後に、オプション引数を取る最大 1 つのオプションが続く場合、1 つの「-」区切り文字の後ろにグループ化されている場合に受け入れられる必要があります。

Posix オプションはすべて 1 文字のオプションであることに注意してください。また、オプション グループの最後のオプションのみが、引数を受け入れる可能性のあるオプションとして許可されるというガイドラインが明確であることにも注意してください。

getopt_longGnu スタイルの長いオプションに関しては、ユーティリティの動作以外の標準を知りません。このユーティリティは、上記のグループ化されたオプション構文を含む、単一文字オプションの Posix スタイルを実装します。これにより、引数を取る単一文字のオプションの直後に引数を続けるか、引数を次の単語として持つ (おそらく単数の) オプション グループの最後に置くことができます。

長いオプションの場合、オプションが引数を受け入れるかどうかに関係なく、グループ化は許可されません。オプションが引数を受け入れる場合、2 つのスタイルが許可されます。オプションの直後に が続き、=その後に引数が続くか、または引数が次の単語になります。

Gnu スタイルでは、長いオプションは 2 つのダッシュ ( ) で指定する必要があるため、長いオプションを 1 文字のオプションと混同することはできません--。

対照的に、多くの TCL/Tk ベースのユーティリティ (およびその他のコマンド ライン パーサー) では、単一-の .

これらすべてのスタイルで、オプションは 2 つのばらばらなセットに分けられます: 引数を取るものと持たないものです。

あなたが提案しているように見えるように、スタイルのランダムな組み合わせはありますが、これらのシステムはどれもあいまいではありません. 正式な明確化ルールを使用しても、あいまいさは危険です。特に、コマンド ラインを元に戻すことができないコンソール アプリケーションでは危険です。さらに、使用可能なオプションのセットが将来拡張された場合、コンテキストの曖昧さの解消は意味を (黙ってでも) 変更する可能性があり、スクリプトで予測しにくいエラーの原因となります。

したがって、Gnu などの単純な既存の慣行に固執することをお勧めします。また、準拠していない誤ったコマンド ラインを無理に解釈しようとしないことをお勧めします。

于 2013-06-22T23:27:02.950 に答える