kubectl
例として挙げると、
kubectl run --image nginx ...
そして
kubectl run --image=nginx ...
どちらも動作します。
一般的なコマンドライン プログラムでは、オプション名と値の間に等号が許可/必須であるかどうかに関するルールはありますか?
答え1
一般に、コマンドライン引数がどのように解釈されるかの実装は、完全にプログラマーの裁量に委ねられます。
そうは言っても、多くの場合では、「長い」オプション ( で導入されるものなど--option_name
)の値は=
、オプション名と値の間に を入れて指定します (つまり--option_name=value
)。一方、1 文字のオプションの場合は、 のようにフラグと値をスペースで区切るか-o value
、または のように区切りをまったく使用しないのが一般的です-oValue
。
GNU date ユーティリティのマニュアルページからの例:
-d, --date=STRING display time described by STRING, not 'now'
-f, --file=DATEFILE like --date; once for each line of DATEFILE
ご覧のとおり、値は、「短い」形式 (つまり-d
) を使用する場合はオプション スイッチからスペースで区切られますが、=
「長い」形式 (つまり--date
) を使用する場合は で区切られます。
編集
スティーブン・キットが指摘したように、GNUコーディング標準getopt
では、コマンドライン オプションを解析するためにとの使用を推奨しています getopt_long
。 のマニュアル ページにはgetopt_long
次のように記載されています。
--arg=param
長いオプションは、または の形式のパラメータを取ることができます--arg param
。
したがって、その関数を使用するプログラムは両方の形式を受け入れます。
答え2
一般的なコマンドライン プログラムでは、スイッチと値の間に等号が許可/必須であるかどうかに関するルールはありますか?
いいえ、ありません。オープンソースの世界やコンピューティングの世界には、競合する標準が数多く存在します(必須のxkcd) 誰もがいつでも新しいルールや基準を考案することができます。 POSIX ユーティリティ引数構文
例えば、=
全く言及していないが、例えば男がトップを取る言及されています。実際には、さまざまなコマンドライン プログラムに遭遇する可能性があります。
=
空白の後ろまたは後ろに長いオプション値を取るもの:
$ touch a b c d
$ ls --format=verbose
total 0
-rw-r--r-- 1 ja users 0 Mar 17 14:39 a
-rw-r--r-- 1 ja users 0 Mar 17 14:39 b
-rw-r--r-- 1 ja users 0 Mar 17 14:39 c
-rw-r--r-- 1 ja users 0 Mar 17 14:39 d
$ ls --format verbose
total 0
-rw-r--r-- 1 ja users 0 Mar 17 14:39 a
-rw-r--r-- 1 ja users 0 Mar 17 14:39 b
-rw-r--r-- 1 ja users 0 Mar 17 14:39 c
-rw-r--r-- 1 ja users 0 Mar 17 14:39 d
長いオプション値を取らない=
が、空白を必要とするもの:
$ readelf -a main | grep 'program interpreter'
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
$ patchelf --set-interpreter=fake main
patchelf: getting info about '--set-interpreter=fake': No such file or directory
$ patchelf --set-interpreter fake main
$ readelf -a main | grep 'program interpreter'
[Requesting program interpreter: fake]
後に値を取るが、またはの
=
オプションは取らないもの:-
--
dd if=/dev/urandom of=~/Desktop/test.txt bs=1M count=3
特定のコマンドラインプログラムが特定の方法で入力を受け入れる理由は、作者のビジョン、誰も気にしない、作者がすでに他の誰かが標準を考案したことを知らなかった、プログラムがまったく異なる規則を持つ別のオペレーティングシステムからUnixに移植された、など様々です。まるで。