長すぎます。

長すぎます。

誰かがコマンドラインにオプションを解析する標準があると言ったことがあります。それは次のとおりです。

./script.sh [options/flags] [command or file]

shiftフラグを渡すことができ、残りの項目はを介してアクセスできるので、これはシェルスクリプトを解析するときに作業をより簡単にすることを知っていますが、実際に書かれた$@ or $*標準はありますか?

私が見たほとんどのプログラムはこの標準に従いますが、いくつかの例外があります。たとえば、、、、、lsともにls -l /path許可さls /path -lls /path -l /path2ます。

答え1

POSIXの基本定義には「実用的な習慣POSIX 基本ユーティリティの場合。

基準getoptsユーティリティ量getopt()システムインタフェース(「C関数」)は、シェルスクリプトまたはCプログラムからコマンドラインを解析するときの指示(上記のリンクページの下)に従います。特にgetopts(例えば):

オプションの終わりに達すると、getoptsユーティリティは0より大きい値で終了する必要があります。シェル変数はOPTIND最初のオペランドのインデックスに設定する必要があり、"$#" +1オペランドがない場合はその値をname文字に設定する必要があります。 。次のいずれかはオプションの終わりを識別する必要があります。最初の引数--はオプション引数ではありません。オプション引数ではなく、で始まらない引数を見つけると、-エラーが発生します。

これが基本的に言うのは、オプションが最初に来て、その後にオペランド(「コマンドまたはファイル」)が続くことです。

他の方法でこれを行うと、役に立たないか不可能になり、getoptsコマンドgetopt()のオプションとオペランドを指定するPOSIXメソッドに精通しているユーザーに混乱を招く可能性があります。

上記の基準はPOSIXユーティリティにのみ適用されますが、通常はUnixユーティリティの優先順位を設定します。明らかに、非標準のUnixユーティリティはそれに従うことができ、壊れるかもしれません。

たとえば、GNU coreutils は標準ユーティリティを実装しても、次のような操作を許可します。

$ ls Documents/ -l

POSIXLY_CORRECT環境変数が設定されていない場合、同じユーティリティのBSDバージョンは設定されません。

その結果、次はBSDシステムで期待どおりに機能します(つまり、POSIXの動作が予想される場合)。

$ touch -- 'test' '-l'

$ ls -l test -l
-rw-r--r--  1 kk  kk  0 Jan 11 16:44 -l  
-rw-r--r--  1 kk  kk  0 Jan 11 16:44 test

しかし、GNU coreutilsシステムでは、次のようになります。

$ ls -l test -l
-rw-r--r-- 1 kk kk 0 Jan 11 16:44 test

しかし:

$ env POSIXLY_CORRECT=1 ls -l test -l

そして

$ ls -l -- test -l

また、GNUシステムでは「正しい」ことをします。

答え2

長すぎます。

一例

Pythonで使用した3つのオプション解析ライブラリのすべて基本分散パラメータを受け入れ、共通コンテンツの説明を提供します。

  1. 廃止予定のPython標準ライブラリモジュールoptparse許可する:

    OptionParser.enable_interspersed_args()
    

    オプションではなく、最初の項目で解析を停止しないように設定して、スイッチにコマンド引数を挿入できます。これがデフォルトの動作です。

  2. 現在のPython標準ライブラリモジュールargparse拡散パラメータを許可(および許可のみ)します。

  3. click、私が現在好きなライブラリは、次のことを許可します。無効にする分散パラメータ:

    click.Context(allow_interspersed_args=False)
    

    ただし、この可能性はトラブルシューティングの詳細セクションで説明されています。サブコマンドの不明なパラメータ

関連情報