Re: rm -- -b

[Bob Proulx]

Jim Meyering wrote:
> Peter Hans van den Muijzenberg wrote:
> > Am I to understand that the coreutils all accept an option --, for end
> > of options, but that neither the --help, nor the man, nor the info
> > document this?
> 
> Depends on where you look.
> With the latest pre-6.10 coreutils, I see this example:

This has been in the code for long before 6.x and by looking in the
source (with git whatchanged -p -S'rm -- -foo' src/rm.c) shows that
this was added in May 2000.  So this has been around for a long time
and would also be in quite older fileutils versions 4.x long before
coreutils 6.10.

But the real reason I wanted to say something was to talk about the
paradigm of '--' and options.  This is common behavior to a whole
class of programs that parse options and is therefore useful in
general to know about.  The rigorous place to start is with the
getopt(3) man page where it documents the format of the command line
parsed by it but in summary '--' ends the left to right across the
argument list processing of command line options.

A scan is made left to right across the argument list looking for
options.  Traditional behavior and POSIX require options before
non-option arguments.  As a GNU extension options may appear anywhere
in the argument list.  If a "--" is encountered it is taken as the end
of option processing.  Any arguments that follow will not be parsed as
a option.

Because all of the programs that use getopt follow this convention it
is good one to know for shell programming.  Almost all of the programs
that are used in shell programming such as rm, mv, cp, grep, sed, cat,
etc. all use getopt for option processing and all behave the same way
with respect to option processing.  This is so fundamental that it
almost can't be documented in each program because it would be
replicated in almost every documentation page.  This behavior is what
I expect to see from every program and am disappointed when it is not
the behavior.

Bob