I don't think the shell/utilities in historical Unix nor in something as "recent" as 4.4BSD supported using a double-dash(or two consecutive hyphens) as an end of options delimiter. With FreeBSD, you can see for instance a note introduced in the rm
manpages with the 2.2.1 release(1997). But this is just the documentation for one command.
Looking at the oldest GNU fileutils changelog I can find, I see this1(slightly altered):
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.
This predates Linux. It's clearly to account for the fact that you might want to create a file with a name containing the same number of digits as a time specification(eight or ten-digit decimal number) – rather than specifying a timestamp for an existing file…
- So is it posix.1 which introduced the double-dash (
--
) as an end
of options delimiter in Unix shells? - Did this all start because some people wanted to use digits in
filenames withtouch
in the early '90s and then this went on in a piecemeal fashion one utility at a time for a decade?? - What is the spirited comment in the changelog about?
- When was Guideline 10(The argument — should be accepted as a delimiter indicating the end of options.[…]) introduced to the POSIX Utility Syntax?
1. As opposed to this i.e. documenting the long options in all commands usage globally, which is unrelated. On the other hand, you can see reference to the delimiter appear in something like GNU rm.c in 2000 as a comment, before being exposed to the end user in 2005(the diagnose_leading_hyphen function). But this is all much later and is about a very specific use case.
Best Answer
As far as I can tell, the use of
--
as end-of-options-marker starts withsh
andgetopt
in System III Unix (1980).According to this history of the Bourne Shell family, the Bourne Shell first appeared in Version 7 Unix (1979). But it didn't have a way for
set
to separate options from arguments. So the original Bourne shell could do:set -e
- turn on exit-on-error modeset arg1 arg2 ...
- sets the positional parameters$1=arg1
,$2=arg2
, etc.But:
set arg1 -e arg2
would give you$1=arg1
,$2=arg2
, and turn on exit-on-error. Whoops.System III Unix (1980) fixed that bug and introduced
getopt
. According togetopt
's man page:As far as I can tell, that's the first place it appears.
From there, it seems that other commands adopted the
--
convention to resolve argument parsing ambiguities (such as the examples withtouch
andrm
you cite above) throughout the wild, standardless days of the 1980s.Some of these piecemeal adoptions were codified in POSIX.1 (1988), which is where the changelog comment about the "POSIX-required kludge" comes from.
But it wasn't until POSIX.2 (1992) that the Utility Syntax Guidelines were adopted, which contain the famous Guideline 10:
And that's where it goes from being a "kludge" to a universal recommendation.