> On Mon, 16 May 2005 11:13:53 +0200
> Igor Sobrado <igor@string1.ciencias.uniovi.es> wrote:
> > I am currently working on a *big* patch for some userland commands.
> > This patch will update a lot of files (about twenty of them) in the
> > source code tree.
> > 
> > How should I submit these patches to simplify applying the changes?
> 
> Without knowing all the details of what you are doing, here is how I
> would probably do this:
> 
> - Start out with a clean, up to date CVS tree.
> - Modify the files you are working on.
> - Build your new application or applications.
> - Test your application.
> - Have your friends test the application.

Indeed, a very nice advice!  Useful not only for submitting fixes
to a lot of files but for single-file patches too.  I will do my
best to submit the best patches.

I see that some utilities in the base system have hardcoded paths
(i.e., the ``usage'' output for those files is something like

  (void)fprintf(stderr, "usage: name [args]\n");

There are some good reasons for replacing these lines with something
like:

  #include <stdlib.h>	/* if it is not yet in the source code */
  [...]
  (void)fprintf(stderr, "usage: %s [args]\n", getprogname());

Reasons include that it is a common practice in BSD commands,
that it will make much easier debugging "experimental versions"
of these commands as developers will know what version of a
command they are invoking, at that it will make code more flexible
without hurting portability.

At same time, I *want* to fix the usage in some commands, as it is
sometimes a bit _outdated_ (the synopsis on the manual pages for some
commands show a lot of options that are not in the ``usage'' output
for these commands, or have brakets that are not closed).

Of course, I want to request some feedback from this mailing list
before submitting the PR.

> - Go to the top level of the CVS tree and run "cvs -q diff -u"
> - Send the output of that command to the appropriate mailing list for
> review.
> - Make sure that you explain what the patches are intended to
> accomplish.

Nice advices too.  Thanks!

I will submit a detailed description of the fixes I propose to the
mailing list as soon as I am sure about the changes (I think that
a detailed discussion of possible changes in the usage output for
some commands that seem outdated or incorrect will be more interesting
that the boring and easy to implement use of getprogname(3) to get
the name of the binary currently being executed.)

I want to make clear the changes I propose before submitting the PR.

Thanks a lot for these useful advices!

Best regards,
Igor.