Goのフラグパッケージにデフォルト値を設定しないことは可能ですか?たとえば、flagパッケージでは、次の行を書き出すことができます。
_filename := flag.String("file", "test.csv", "Filename to cope with")
_
上記のコードでは、必ずしもデフォルト値(この場合は_test.csv
_)を設定する必要はなく、代わりに常にユーザーに独自のファイル名を指定させます。指定されていない場合は、エラーが発生し、プログラムを終了します。
私が思いついた方法の1つは、flag.Parse()
を実行した後に最初にfilename
の値をチェックし、その値が_test.csv
_の場合、プログラムを終了させることです。適切なエラーメッセージ。ただし、回避できる場合はそのような冗長なコードを記述したくありません。回避できない場合でも、この問題に対処するためのより良い方法をここで聞きたいと思います。
ちなみに、Pythonのargparse
モジュールでこの種の操作を行うことができます-できれば、同様のことを実装したいだけです...
また、フラグパッケージに短い引数と長い引数の両方(つまり、_-f
_と_-file
_の両方の引数)を実装できますか?
ありがとう。
それぞれのタイプのゼロ値に等しいときに「存在しない」ことを意味するような方法でフラグ値を設計するのは慣用的だと思います。例えば:
optFile := flag.String("file", "", "Source file")
flag.Parse()
fn := *optFile
if fn == "" {
fn = "/dev/stdin"
}
f, err := os.Open(fn)
...
2番目の質問:IINM、フラグパッケージ設計によるは-flag
と--flag
を区別しません。 IOW、フラグに-f
と--file
の両方を設定し、f
とfile
の両方の前に-
または--
の任意のバージョンを書き込むことができます。ただし、別の定義済みフラグ-g
を考慮すると、フラグパッケージはnot-gf foo
を-g -f foo
と同等であると認識します。
デフォルト値を設定できないフラグがある場合、値REQUIRED
などを使用することがよくあります。私はこれが--help
読みやすい。
焼き付けられなかった理由については、それが十分に重要であると考えられていなかったのではないかと思います。デフォルトはすべてのニーズに合うわけではありません。しかし --help
フラグも同様です。すべてのニーズに対応できるわけではありませんが、ほとんどの場合は十分です。
必要なフラグが悪い考えだと言っているわけではありません。あなたが十分に情熱を持っているなら、flagutil
パッケージは素晴らしいかもしれません。現在のflag
apiをラップし、Parse
が欠落しているフラグを説明するエラーを返すようにし、RequiredInt
やRequiredIntVar
などを追加します。便利/人気があり、公式のflag
パッケージとマージできます。