Mailing List Archive

>>>>> "wk" == Werner Koch <wk@isil.d.shuttle.de> writes:

wk> Hi, someone raised the question, whether to change the
wk> commandline syntax, so that it is more like tar(1) or ps(1). I
wk> have no POSIX specs so I can't decide whether this is a good
wk> idea. Recent versions of ps(1) etc give you a warning, that the
wk> use of - is depreciated.

wk> Example of a new syntax:

wk> $ gpg -v sign 0x12345678 instead of $ gpg -v --sign 0x12345678

[snip]

wk> Comments?

I for one dislike this approach. It does take some getting used, (the
--cmd), but it is the correct way. tar(1) is the way it is for
historic reasons, and ps(1), well it just plain different on most
systems, (hp/us != solaris != irix != aix != osf/1, and the linux
version tries to be all things to all folks).

So since these are bad role models, stick with the GNU with POSIX
overtones command syntax. I think that those that want special syntax
can write wrappers to suite there needs. This is what most GPG
intergration devlopers do anyway to get GPG to look like PGP ot be
callable from there MUA etc.

pAnthony

> 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

David Pick <D.M.Pick@qmw.ac.uk> writes:

> 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"

gpg already knows of this option (and command) stopper option.


--
Werner Koch at guug.de www.gnupg.org keyid 621CC013

On Wed, 7 Apr 1999, Werner Koch wrote:
> 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.

I think that it's unnecessary to create a distinction between "options"
and "commands". My observation of how I think about options and commands
when I'm running a program, is that I just think of what things I want to
tell the program. I don't mentally split it into "what to do"
(commands) and "how to modify it" (options).

My general inclination, then, is to specify all the options or commands
with a dash. I type "tar -xzvf" even though I know the dash is
unnecessary. I type "ps -fax", and curse at the "warning, - is
deprecated" message. It seems to me that making the dash optional, or
worse, deprecated with message, just creates something extra for the user
to have to remember. There's no reason obvious to me why it should be
necessary. The dash *feels* more consistent with the rest of the
command-line syntax on my system, even though I'm aware that there's a
distinction I'm ignoring between "commands" and "options", and programs
that require a command versus programs that don't.

A fundamental principle of user-interface design is the principle of least
surprise; things should behave more or less the way the user expects them
to behave. What I expect, because of my experience with other Unix
programs, is to type "-" in front of anything that isn't a filename, and
"--" in front of commands or options that are longer than a single letter.
Making the slash optional is a feature I'll ignore; *complaining* about
the slash is a feature I'll find annoying and probably hack out of my
copy, because the feeling I get (regardless of what some standard may
say) is that it's the program doing something unusual in that case, not me.

Someone else mentioned the use of "--" to mark "the remaining arguments
are only files". I'm not sure how necessary that is for gpg, but it is
useful with some other programs. One final note is that most programs
seem to accept filenames and options/commands in any order unless
overridden with "--", and that's what seems most intuitive to me. gpg
doesn't do that; it wants options/commands first and then files. But
that's a relatively minor point. tar wants its command first too, so
maybe we should stick with that if tar is being used as a model.

Matthew Skala Ansuz BBS (250) 472-3169 http://www.islandnet.com/~mskala/

GOD HATES SPAM

At 3:13 PM 4/7/99, Werner Koch wrote:
>Hi,
>
>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.

>Comments?

Unix ignoramus here:

I'll be damned if I could ever figure out why the hell ps was bitching at
me for doing things the way that has worked since 1960 something...

I don't see any benefit to losing the dashes. Only grief in terms of
backwards and forwards compatibility, and more hassle for scripts that want
to just spit the file at gpg directly.

-- "TANSTAAFL" Rich lynch@cognitivearts.com webmaster@ and www. all of:
R&B/jazz/blues/rock - jademaze.com music industry org - chatmusic.com
acoustic/funk/world-beat - astrakelly.com sculptures - olivierledoux.com
my own nascent company - l-i-e.com cool coffeehouse - uncommonground.com

On Wed, 7 Apr 1999 12:45:58 -0500, Richard Lynch wrote:
>At 3:13 PM 4/7/99, Werner Koch wrote:
>>Hi,
>>
>>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.
>
>>Comments?
>
>Unix ignoramus here:
>
>I'll be damned if I could ever figure out why the hell ps was bitching at
>me for doing things the way that has worked since 1960 something...

This is because the ps author wants to support both BSD and SysV
option syntax. BSD ps users traditionally gave options without a dash
in front, SysV with.

If you get procps 2.0.0, you'll discover that it no longer gives that
warning message, but `ps -ef' does something different from `ps ef'.

>I don't see any benefit to losing the dashes. Only grief in terms of
>backwards and forwards compatibility, and more hassle for scripts that want
>to just spit the file at gpg directly.

Agree here.

zw

On Apr 7, 9:58am, ANM wrote:
> >>>>> "wk" == Werner Koch <wk@isil.d.shuttle.de> writes:
>
> wk> Hi, someone raised the question, whether to change the
> wk> commandline syntax, so that it is more like tar(1) or ps(1). I
> wk> have no POSIX specs so I can't decide whether this is a good
> wk> idea. Recent versions of ps(1) etc give you a warning, that the
> wk> use of - is depreciated.
>
> wk> Example of a new syntax:
>
> wk> $ gpg -v sign 0x12345678 instead of $ gpg -v --sign 0x12345678
>
> [snip]
>
> wk> Comments?
>
> I for one dislike this approach. It does take some getting used, (the
> --cmd), but it is the correct way. tar(1) is the way it is for
> historic reasons, and ps(1), well it just plain different on most
> systems, (hp/us != solaris != irix != aix != osf/1, and the linux
> version tries to be all things to all folks).


I agree that ps and tar are bad models. The only reason that "-" is
deprecated on GNU ps, as the man page says, is so in the future they
can distinguish between System V style options and BSD style options.
Besides, you're not proposing removing the hyphens on the short
options, you're proposing removing the double-hyphen on the long options.

A better example perhaps is cvs, which has options and "commands". Gpg
also makes that distinction, but commands all use the syntax of options.
It may make sense to remove the double-dash on just the long form of
commands.

- Dave Dykstra

>>>>> "Dave" == Dave Dykstra <dwd@lucent.com> writes:

[snip]

Dave> I agree that ps and tar are bad models. The only reason that
Dave> "-" is deprecated on GNU ps, as the man page says, is so in the
Dave> future they can distinguish between System V style options and
Dave> BSD style options. Besides, you're not proposing removing the
Dave> hyphens on the short options, you're proposing removing the
Dave> double-hyphen on the long options.

Dave> A better example perhaps is cvs, which has options and
Dave> "commands". Gpg also makes that distinction, but commands all
Dave> use the syntax of options. It may make sense to remove the
Dave> double-dash on just the long form of commands.

Concidering what Dave is saying here, I agree that if the intent is to
differentiate between commands and options then a non GNUish -- lead is
not required, as you say Dave, in CVS. But here one needs to note the
distinctions between general options and command options which may
make things a tad confusing, (eg: cvs -z3 update -P).... Maybe they
are already confusing... what the heck?

Anthony

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

* Werner Koch <wk@isil.d.shuttle.de> on Wed, 07 Apr 1999
| 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.

'Recent versions' of ps are replaced with versions that do not bitch about
long-standing defacto standards. Bad enough that BSD and System V have
utterly different syntax, I don't need my tools being stupid on me like
that.

In other words, if you are going to accept POSIXly correct command line
syntax, make it in addition to the defacto standard and make it silent,
like GNU tar. And deprecate the non-POSIX style in the documentation.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v0.9.5 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE3C/9Igl+vIlSVSNkRAuczAJ4q6DEspLOx6QYLyELeQ5r7gpYrVgCgqAlT
u28jjxhLVl3RpMVD39ht9as=
=cTZN
-----END PGP SIGNATURE-----

--
Rat <ratinox@peorth.gweep.net> \ When not in use, Happy Fun Ball should be
Minion of Nathan - Nathan says Hi! \ returned to its special container and
PGP Key: at a key server near you! \ kept under refrigeration.