Unix / Linuxでオプション区切り文字の終わりとして二重ダッシュ(-)が導入されたのはいつですか?


49

歴史的な Unixや4.4BSDのような「最近」のシェル/ユーティリティは、オプションの区切り文字としてダブルダッシュ(または2つの連続したハイフン)の使用をサポートしていないと思います。ではFreeBSDでは、インスタンスのために導入されたノートを参照することができrm manページ2.2.1リリース(1997年)。しかし、これは1つのコマンドの単なるドキュメントです。

最古のを見るとGNUのfileutils のchangelog私は見つけることができる、私はこの参照1を(少し変更されました):

Tue Aug 28 18:05:24 1990  David J. MacKenzie  (djm at albert.ai.mit.edu)

* touch.c (main): Don't interpret first non-option arg as a   <---
  time if `--' is given (POSIX-required kludge).  
* touch.c: Add long-named options.
* Many files: Include <getopt.h> instead of "getopt.h" since
  getopt.h will be in the GNU /usr/include.
* install.c: Declare some functions.
* touch.c, getdate.y, posixtime.y, mktime.c: New files, from bin-src.
* posixtime.y: Move year from before time to after it (but
  before the seconds), for 1003.2 draft 10.

これはLinuxよりも前のものです。既存のファイルのタイムスタンプを指定するのではなく、時間指定と同じ桁数(8桁または10桁の10進数)を含む名前のファイルを作成することをお勧めします。


  • では、Unixシェルのオプション区切り文字の終わりとして二重ダッシュ()を導入したのはposix.1ですか?--
  • touch90年代初期に一部の人々がファイル名に数字を使用したいと考えていたため、これはすべて始まりました。そして、これは10年間、一度に1つのユーティリティで断片的に行われましたか?
  • changelogの活発なコメントとは何ですか?
  • た場合指針10引数-オプションの終了を示す区切り文字として受け入れられるべきである[...])POSIXに導入ユーティリティ構文

1.これとは対照的につまり、すべてのコマンドの使用における長いオプションをグローバルに文書化することは、無関係です。一方、区切り記号への参照は、2005年にエンドユーザーに公開れる前に、2000年のGNU rm.cのようなものにコメントとして表示されることがわかります(diagnose_leading_hyphen関数)。しかし、これはずっと後のことであり、非常に具体的なユースケースに関するものです。


1
BSD4.3RENOには少なくともがgetoptサポートされていました--
ステファンシャゼル14

@StéphaneChazelasまた、getoptが区切り文字を処理できる唯一のapiではないことについてコメントしました。それは、これが実際に使用される前に提供され、機能していたということですか?? これは私の向こうにあるのではないかと思います。ありがとうございました!

2
おそらく、いくつかのランダムなプログラムでアドホックベースで使用getoptされていましたが、1980年代初頭に書かれたときに初めて文書化されたと思います。誰かがUniforum '85からgetoptの論文を入手できるなら、それはいくらかの歴史を与えるかもしれません。
マークPlotnick 14

2
@MarkPlotnick、実際にはSysIII(1980)にあるgetoptがサポートしています--
ステファンシャゼル14

回答:


38

私の知る限りの使用--と同様に、エンド・オブ・オプション・マーカー開始shおよびgetoptIIIのUnixシステムでの(1980)。

Bourne Shellファミリーのこの歴史によると、Bourne Shell はバージョン7 Unix(1979)で初めて登場しました。しかし、引数からオプション分離する方法がありませんでした。したがって、元のBourneシェルでは次のことができます。set

  • set -e -エラー終了モードをオンにする
  • set arg1 arg2 ...-位置パラメータを設定し$1=arg1$2=arg2

しかし:set arg1 -e arg2あなたを与えるだろう$1=arg1$2=arg2と、出口でのエラーをオンにします。おっと。

System III Unix(1980)は、このバグを修正して導入しましたgetoptgetoptmanページによると:

NAME
   getopt - parse command options

SYNOPSIS
   set -- `getopt optstring $∗`

DESCRIPTION
   Getopt is used to break up options in command lines for easy parsing by
   shell procedures, and to check  for  legal  options.   Optstring  is  a
   string  of  recognized  option letters (see getopt(3C)); if a letter is
   followed by a colon, the option is expected to have an  argument  which
   may or may not be separated from it by white space.  The special option
   -- is used to delimit the end of the options.  Getopt will place --  in
   the  arguments  at  the  end  of  the  options, or recognize it if used
   explicitly.  The shell arguments ($1 $2 . . .) are reset so  that  each
   option  is  preceded  by a - and in its own shell argument; each option
   argument is also in its own shell argument.

私が知る限り、それが最初に現れる場所です。

そこから、他のコマンドが採用されているようです--曖昧解析する決意引数に条約(などとの例としてをtouchし、rm野生全体で1980年代の、standardless日あなたは上記の引用します)。

これらの断片的な採用の一部はPOSIX.1(1988)で体系化されており、「POSIXに必要なクラッジ」に関するchangelogのコメントはここから来ています。

しかし、POSIX.2(1992)になって初めて、ユーティリティ構文ガイドラインが採用されました。これには、有名なガイドライン10が含まれています。

Guideline 10:    The argument "--" should be accepted as a delimiter
                 indicating the end of options.  Any following
                 arguments should be treated as operands, even if they
                 begin with the '-' character.  The "--" argument
                 should not be used as an option or as an operand.

そして、それが「手品」であることから普遍的な勧告へと変わるところです。


お時間をいただきありがとうございます!そのような抽象化されたユーティリティ/機能が必要な理由がわからないため、「研究」ではgetoptをほとんど無視していました。今、私はこれがsysvではできなかったように空白などに対処するためにある時点で再取得(getopts)されたことを読みましたgetopt。私はそれについてもっと読みます!再度、感謝します!

5
コマンドラインオプションを解析するための標準ユーティリティがなぜ役立つのか理解できない場合は、コマンドラインオプション用のシェルパーサーを書いていないのでしょうか?それは一種の痛みです!もちろん、他のツールがこれをやってくれたらいいのですが... 「シェルスクリプト」の概念全体は、まだかなり新しいものでした。そのため、標準のコマンドラインパーサーのアイデアはまだかなり斬新でした!
wwoods 14
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.