Re: dispatch program

[Thien-Thi Nguyen]

() Paul Eggert <address@hidden>
() Thu, 03 Nov 2011 13:24:00 -0700

   A new name might be simpler to implement, but it's more
   complicated for users, and we should think of users first.

   Why not just stick with "rcs"?  If done right, it won't
   affect practical existing uses of the "rcs" command,
   as the old and new syntaxes won't collide.

Actually, i think a new name is simpler; as a user, i don't want to log
into a system and have to type ‘rcs --version’ or a random RCS command
(and have it fail) to distinguish between old-style and new-style RCS
option handling.  Much less hassle: "If the system has grcs, it is
new-style; if not, old-style".

   Once this is done, we could have something like this:

     rcs ci     == ci
     rcs co     == co
     rcs clean  == rcsclean
     rcs diff   == rcsdiff
     rcs merge  == rcsmerge
     rcs log    == rlog
     rcs init   == rcs -i (the "old" rcs)
     rcs admin  == rcs without -i (the "old" rcs)

The mapping is a separate issue.  If you build from the repo, you can
see the current set (including aliases) w/ command: ‘grcs --commands’.
See also: <http://git.savannah.gnu.org/cgit/rcs.git/commit/?id=bacb82a23>.

   One more thing: the "new" rcs should use GNU getopt,
   and not have options that have optional arguments, as
   the argument-parsing gorp of the "old" rcs is one of
   its greatest annoyances, and we might as well fix this
   problem now if we're changing the API anyway.

OK, i'll keep this in mind.