geda-developers team mailing list archive

[Peter TB Brett <peter@xxxxxxxxxxxxx>]

On Mon, 12 Dec 2011 17:29:57 -0500, Dan McMahill <dan@xxxxxxxxxxxx> wrote:
> On 12/12/2011 6:30 AM, Dan McMahill wrote:
>> On 12/10/2011 6:37 PM, Peter TB Brett wrote:
>> 
>>>    As a rule, we should be providing manpages for all binaries
installed
>>>    in the $PATH.  Currently, the following lack manpages:
>>>
>> 
>>>    - pads_backannotate
>>>    - pcb_backannotate
>>>    - refdes_renum
>>>    - sw2asc
>> 
>> I'll make man pages for these.
>> 
> 
> Couple of quick questions.
> 
> 1)  Do we have any sort of a man page linter that should be run?

No, sorry.

> 2)  Some of those scripts have -V|--version options that are broken.
> They are broken because they used to work by searching inside of $0
> (ARGV[0]) and looking for an RCS Id.  Of course once we moved from cvs
> to git that stopped "working".  I say "working" because it is not clear
> that this was ever the correct version to report but it was better than
> nothing.  So.... do I nuke that option entirely from the scripts?  I'd
> sort of rather not because it is that much less debug information that
> can go in a bug report.  If I keep it, any good ideas on how to get the
> version information into shell scripts and perl programs?

Ideally, they should output something like:

gEDA 1.7.1 (g9e89e5c)
Copyright (C) 1998-2011 gEDA developers
This is free software, and you are welcome to redistribute it under
certain conditions. For details, see the file `COPYING', which is
included in the gEDA distribution.
There is NO WARRANTY, to the extent permitted by law.

I can't really think of a good way of getting that information into them,
though, other than sed-based substitution. :-(

> 3)  Looking at some of the existing man pages (gnetlist.1 for example),
> I see a string like 1.7.1.20110619 in the header.  Is there a rule for
> what should go here?

Yes; Ales has always put the version of the latest release there, in the
form <dottedversion>.<date>.

Peter

-- 
Peter Brett <peter@xxxxxxxxxxxxx>
Remote Sensing Research Group
Surrey Space Centre