This marks end of parameter (option) list.

In man bash we can read in Shell Builtin Commands section:

Unless otherwise noted, each builtin command documented in this section as accepting options preceded by - accepts -- to signify the end of the options.

The :, true, false, and test builtins do not accept options and do not treat -- specially. The exit, logout, break, continue, let, and shift builtins accept and process arguments beginning with - without requiring --. Other builtins that accept arguments but are not specified as accepting options interpret arguments beginning with - as invalid options and require -- to prevent this interpretation.

Note that echo does not interpret -- to mean the end of options.

POSIX.1-2017

12.2 Utility Syntax Guidelines

Guideline 10:

The first -- argument that is not an option-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.

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02

In commands that use the POSIX getopt() API to parse options, as well as several others, -- marks the end of options.

In:

rm -f -- -f

The first -f is taken as an option to rm, while the second is taken as the name of a file to remove as everything past -- is not taken as an option.

In POSIX-compliant utilities and getopt() implementations, options are not accepted after non-option arguments, so for instance:

grep pattern -f

is required to look for lines matching pattern in the file called -f.

However, the GNU implementation of getopt() and its getopt_long() extension as used by most GNU utilities including GNU grep (but not bash nor any of its builtins even though bash is the GNU shell) doesn’t do that by default unless there’s a POSIXLY_CORRECT variable in the environment.

So, for those, -- is needed even if there are leading non-option arguments:

grep -- pattern -f

An older way to mark end of options was with -. You’ll find that most sh implementations still support - as an end-of-option marker, as well as most of the builtins of ksh or zsh. That is however not common these days.

Some commands are known not to support -- as the end of option marker. Most echo implementations are among those. That’s one of the reasons they can’t be used to output arbitrary data.

⚠️ Important

That -- is needed when non-option arguments start with - (or possibly + for some commands), but also when you can’t guarantee some non-option arguments won’t start with -/+. That includes:

• rm -f -- "$file"
• rm -f -- "${files[@]}"
• rm -f -- *.txt
• rm -f -- $(command-that-generates-a-list-of-files-or-file-patterns)
• cmd | xargs rm -f --

If you can’t guarantee the command supports -- as the end of option marker, for those arguments that are file names, another approach is to prefix the file name with ./:

somegrep pattern ./*.txt

Failing to add those -- can introduce arbitrary command injection vulerabilities, especially if you also forget to quote your expansions. For instance:

sed -e 's/foo/bar/' *.txt

Will run reboot if there’s a file called '-es/.*/reboot/e;#.txt' in the current working directory. Fixed by changing it to sed -e 's/foo/bar/' -- *.txt or sed -e 's/foo/bar/' ./*.txt.

Same for:

rename 's/foo/bar/' *foo*

with some rename variants; beware some (non-vulnerable) rename variants don’t support --.

print $var

In zsh (even though leaving parameter expansions unquoted is relatively safe in that shell), will run reboot if $var contains -va[1$(reboot)]. Fixed with print -- $var or print - $var though you likely want print -r -- $var to also disable the backslash processing.