> someone raised the question, whether to change the commandline syntax,
> so that it is more like tar(1) or ps(1). I have no POSIX specs so I
> can't decide whether this is a good idea. Recent versions of ps(1) etc
> give you a warning, that the use of - is depreciated.
>
> Example of a new syntax:
>
> $ gpg -v sign 0x12345678
> instead of
> $ gpg -v --sign 0x12345678
>
> The problem with this ist that it is not anymore possible to use
> gpg without an command and an filename - we yould have to add a new
> command like "default" or "process" to work around this.
>
> * One letter commands should also work.
> * Still allow commands with leading dashs.
> * Should abbreviated commands work?
> * I think implementation is quite easy.
>
> Ways to migrate:
>
> - an option to allow for the new syntax (not a good idea)
> - an option to allow for the old syntax
> - simply switch to the new syntax and hope that no scripts or
> programs use only "gpg filename".
>
Of course, "tar" *always* has a "flags" parameter to tell it which
sort of operation it's doing. So forcing it to be a traditional
"flags" parameter with a leading "-" is a bit of overkill.
"ps" can also easily distinguish between process numbers (all digits!)
and a "flags" parameter even if the latter doesn't have a leading
parameter.
But although the default mode of behavious for "gpg" is to decrypt a
file, this differs from the sort of behaviour you get with an explicit
"--decrypt" "flag" command. So we'd need two variants of "decrypt" at
least.
I think one thing that makes life rather difficult is that (at the moment)
some "gpg" "commands" can be used together so it's not possible to say
if "gpg fingerprint list-sigs" would be the "fingerprint" operation
applied to a file "list-sigs" or the combined operation applied to the
standard input - unless it was required that use of the standard input
could not be implied and that an explicit "-" would have to be used to
represent it.
I suppose another option (if you'll pardon the expression) would be to
use "--" to separate "options" and "commands" from "files" in the
parameter list. Of course, this actually acts as the option which
in the migration list below is tagged as "(not a good idea)"! But
it might offer a fairly good three-stage migration plan:
1) Add code to look for the existance of "--" in the parameter list.
a) if it's not there, work exactly as now
b) if it is there, everything *before* the "--" is an "option"
or "command" even if it doesn't have any leading "-"s at all,
everything *after* "--" is a file name
- existing code calling "gpg" will still work. Programs could
be changed to add the "--" token for development/testing
- users could get into the habit of typing "--"
2) When using the "new" scheme, change "options" and "commands" to
distinguish more clearly between the two and enforce the rule
that one and only one "command" is allowed together with any
number of "options". "Commands" could be given without leading
"-" or "--" prefixes. Options would always require the prefix.
- programs should be changed to use the new scheme with the "--"
token and the new "options" and "commands" formats
- users should get into the habit of typing the new "options"
and "commands", the "commands" without leading "--"s
3) Allow the omission of the "--" in the new scheme
- programs could be changed to remove the "--" token
- users could now forget to type the "--" tokens
Although I'd like to see the distinctions between "commands" and "options"
clarified anyway, I have to say I really don't see the need for the other
changes! I don't think the number of programs in UNIX systems that use
"-"-prefixed commands and options followed by file names will change,
although it's worth noting that a number of programs already adopt the
"--" token as meaning "end of commands/options and start of file names"
so that filenames starting with "-"s can be used. So perhaps stage (1)
of my plan is all that's either necessary or advisable.
--
David Pick