Re: [Gnu-arch-users] Re: User-defined "macro" commands

[Tom Lord]

    > From: Dustin Sallings <address@hidden>

    > [Stop flaming me.  What's actually wrong with my proposal?]

It seems to me that there are [hoping I haven't skimmed the thread too
superficially] two issues getting mixed up together that really ought
to be separate.

1) What's with all the aliases?
2) How about this mechanism that let's user's add extended commands?


So:

1) What's with all the aliases?

   They serve two purposes:

   a) A way to rename commands in successive releases without abrupt 
      transitions.

      We don't currently use the deprecated command flag this way, but
      we certainly could: when a command is invoked by a deprecated
      name, print a warning on stderr that the name will be going away
      in a future release.

      It's an obnoxious thing for a program to do, of course -- but
      that's the point.   It will do things like flag scripts that
      will break before they actually break.   It's less obnoxious
      than simply breaking scripts abruptly


   b) A way to provide shared short-names and "alternative perspective"
      names.

      For example, "apply-changeset" is a good name for that command
      because it identifies the command as changeset-related and makes
      what the command does quite clear.   "dopatch" is a good alias
      because it is far shorter and because the terms "mkpatch" and 
      "dopatch" are commonly used in the arch community.


  (Neither of those purposes would be well served by an extended
  command mechanism.)
      


2) How about the "extended command" thing?

  Extensions are a fine thing but if we're going to provide a
  mechanism for them, it'd be good to design it with some care.
  The itla discussions are headed slowly in that direction.

  An extension mechanism that just forks and execs a script -- and
  maybe adds a little bit of support in `tla help' -- seems a bit 
  anemic to me.    

  For one thing, the same effect could be accomplished without changes
  to tla by a simple shell script.   I'm therefore skeptical that 
  this should be built-in to tla.   (itla isn't much different -- in 
  effect, it's just a less-simple wrapper script.)

  For another thing, the "fork/exec approach to extensions" doesn't 
  provide much help to extension writers.   Providing such help seems
  to me to be the bigger problem that needs solving than the problem
  of "how do I turn `tla <unrecognized-command>' into a call to an
  extension?

-t