Why use superflous dash (-) to pass option flags to tar?

There are several different patterns for options that have been used historically in UNIX applications. Several old ones, like tar, use a positional scheme:

command options arguments

as for example tar uses

tar *something*f "file operated on" *"paths of files to manipulate"*

In a first attempt to avoid the confusion, tar and a few other programs with the old flags-arguments style allowed delimiting the flags with dashes, but most of us old guys simply ignored that.

Some other commands have a more complicated command line syntax, like dd(1) which uses flags, equal signs, pathnames, arguments and a partridge in a pear tree, all with wild abandon.

In BSD and later versions of unix, this had more or less converged to single-character flags marked with '-', but this began to present a couple of problems:

• the flags could be hard to remember
• sometimes you actually wanted to use a name with '-'
• and especially with GNU tools, there began to be limitations imposed by the number of possible flags. So GNU tools added GNU long options like --output.

Then Sun decided that the extra '-' was redundant and started using long-style flags with single '-'s.

And that's how it came to be the mess it is now.

You can give tar options in the standard unix manner tar -c -f foo -v -B file1 file2 file3 where you need the dash to differentiate between options and parameters or the file names at the end of the command line. Or you can put all the options together in the first argument, in which case the dash is optional.

Then there is ps, where you use the dashes if you're using the SysV-ish options, and leave them out if you're using BSD-ish options, just to make things more confusing.

And lets not even talk about find.

The dash is used in order to disambiguate between an option parameter names and values. I guess it's more of a standard convention.