Copyright years (was Re: help/version patches)
- Copyright 1998, 1999, 2000, 2001 Red Hat, Inc. + Copyright 1998-2002 Red Hat, Inc. A quick note about changing Copyright years like this... don't do it! The two are *not* equivalent. See http://www.gnu.org/prep/maintain_8.html on the GNU website for more information, but basically if a new release of Cygwin was tagged in CVS in any of those years, it should appear as a separate year in a comma separated list. Ranges are only allowed if development was carried out in that range of years, but a version was completed for release only in the final year of the range. Regards Chris
Re: Copyright years (was Re: help/version patches)
Chris January [EMAIL PROTECTED] writes: - Copyright 1998, 1999, 2000, 2001 Red Hat, Inc. + Copyright 1998-2002 Red Hat, Inc. A quick note about changing Copyright years like this... don't do it! The two are *not* equivalent. No, but need they be? The silly comma separated list will get out of hand, at some point in the future. Each release should hold the (c) marker that's applicable to that release, why should later releases hold markers that are not applicable anyway? Ranges are only allowed if development was carried out in that range of years, but a version was completed for release only in the final year of the range. If you get hold of, say, a 1999 release (tarball, cvs -D checkout), you'll see the range 1998-1999 which will cover the only interesting thing: (c) over 1999 release. If you look at a 2002 tarball, you'll see 1998-2002 Greetings, Jan. -- Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: Copyright years (was Re: help/version patches)
Chris January [EMAIL PROTECTED] writes: Since when have common sense and the law gone together. Hmm, that's a good point. I think there was some logic to what I said, but that may well be irrelevant. I would point out that the GCC team have recently changed all their copyrights from the incorrect range format to a list of years because this is simply the right thing to do from a legal point of view. (see http://gcc.gnu.org/ml/gcc-patches/2002-01/msg01192.html). Ok, thanks for pointing that out. Jan. -- Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: help/version patches
On Tue, Feb 26, 2002 at 08:59:45PM -0800, Joshua Daniel Franklin wrote: Well, except that that loop does away with the whole point--eating the trailing '$'. Here's another go. I tested it with $Revision$, $Revision:$, $Revision: $ , $Revision: 1.22 $ , and $Revision: 1.2 2 $ (in the unlikely event of a version number with spaces) and it does the right thing on each. There's no need for a loop. There really shouldn't be any need to accommodate the missing colon but it doesn't hurt too much to add a test case. I've checked in a modified version of your patch. I cleaned up some of the non-GNU formatting, added a ChangeLog, and added a print_version function which parses the 'version' array for version info. I appreciate the submission very much but, next time, I would also appreciate a ChangeLog and more attention to formatting issues. cgf
Re: help/version patches
--- Christopher Faylor [EMAIL PROTECTED] wrote: There's no need for a loop. There really shouldn't be any need to accommodate the missing colon but it doesn't hurt too much to add a test case. I've checked in a modified version of your patch. I cleaned up some of the non-GNU formatting, added a ChangeLog, and added a print_version function which parses the 'version' array for version info. I appreciate the submission very much but, next time, I would also appreciate a ChangeLog and more attention to formatting issues. Sorry, I didn't read this first. Ignore my last message. __ Do You Yahoo!? Yahoo! Greetings - Send FREE e-cards for every occasion! http://greetings.yahoo.com
RE: help/version patches
-Original Message-
From: Joshua Daniel Franklin [mailto:[EMAIL PROTECTED]]
It's not - strace is manually entered version info.
Anyway here is a patch for cygcheck that I think does the
right thing. Somebody want to take a look?
+const char *revision=$Revision: 1.22 $;
This is suspect: The revision string can look like $Revision:$ in some circumstances -
see man co again - which is why I had $Revision: $ - note the space after the
second $ sign.
Likewise, the
+ /* Get version number out of the autogenerated revision string */
+ (void *) version = malloc(sizeof(revision));
+ strcpy(version, revision+11);
+ version[strlen(version)-1]= 0;
Could be more robustly done as
+ version = (char *) malloc(sizeof(revision));
+ strcpy(version, revision+11);
+ {
+char *temp=version + strlen (version);
+while (isspace(--temp) temp = version);
+temp[1]='\0';
+ }
Which will munch an arbitrary amount of whitespace.
Rob
RE: help/version patches
--- Robert Collins [EMAIL PROTECTED] wrote:
-Original Message-
From: Joshua Daniel Franklin [mailto:[EMAIL PROTECTED]]
+const char *revision=$Revision: 1.22 $;
This is suspect: The revision string can look like $Revision:$ in some
circumstances - see man co again - which is why I had $Revision: $ - note
the space after the second $ sign.
Hmm. Sounds like if -kk is used, it could be replaced with just $Revision$,
which gives the +11 part problems. Another if...
Likewise, the
+ /* Get version number out of the autogenerated revision string */
+ (void *) version = malloc(sizeof(revision));
+ strcpy(version, revision+11);
+ version[strlen(version)-1]= 0;
Could be more robustly done as
+ version = (char *) malloc(sizeof(revision));
+ strcpy(version, revision+11);
+ {
+char *temp=version + strlen (version);
+while (isspace(--temp) temp = version);
+temp[1]='\0';
+ }
Which will munch an arbitrary amount of whitespace.
Well, except that that loop does away with the whole point--eating the
trailing '$'. Here's another go. I tested it with $Revision$,
$Revision:$, $Revision: $ , $Revision: 1.22 $ , and $Revision: 1.2 2 $
(in the unlikely event of a version number with spaces) and it does the right
thing on each.
__
Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!
http://greetings.yahoo.com
--- cygcheck.cc-origSun Feb 24 13:28:27 2002
+++ cygcheck.cc Tue Feb 26 22:55:33 2002
@@ -1,6 +1,6 @@
/* cygcheck.cc
- Copyright 1998, 1999, 2000, 2001 Red Hat, Inc.
+ Copyright 1998-2002 Red Hat, Inc.
This file is part of Cygwin.
@@ -33,6 +33,8 @@ typedef __int64 longlong;
void dump_setup (int, char **, bool);
+const char *revision=$Revision: 1.22 $ ;
+
const char *known_env_vars[] = {
c_include_path,
compiler_path,
@@ -1216,17 +1218,19 @@ check_keys ()
}
void
-usage ()
+usage (FILE *stream, int status)
{
- fprintf (stderr, Usage: cygcheck [OPTIONS] [program ...]\n);
- fprintf (stderr, -c, --check-setup = check packages installed via setup.exe\n);
- fprintf (stderr, -s, --sysinfo = system information (not with -k)\n);
- fprintf (stderr, -v, --verbose = verbose output (indented) (for -s or
programs)\n);
- fprintf (stderr, -r, --registry= registry search (requires -s)\n);
- fprintf (stderr, -k, --keycheck= perform a keyboard check session (not with
-s)\n);
- fprintf (stderr, -h, --help= give help about the info (not with -c)\n);
- fprintf (stderr, You must at least give either -s or -k or a program name\n);
- exit (1);
+ fprintf (stream, \
+Usage: cygcheck [OPTIONS] [program ...]\n\
+ -c, --check-setup check packages installed via setup.exe\n\
+ -s, --sysinfo system information (not with -k)\n\
+ -v, --verbose verbose output (indented) (for -s or programs)\n\
+ -r, --registry registry search (requires -s)\n\
+ -k, --keycheck perform a keyboard check session (not with -s)\n\
+ -h, --help give help about the info (not with -c)\n\
+ -z, --version output version information and exit\n\
+You must at least give either -s or -k or a program name\n);
+ exit (status);
}
struct option longopts[] = {
@@ -1236,15 +1240,32 @@ struct option longopts[] = {
{verbose, no_argument, NULL, 'v'},
{keycheck, no_argument, NULL, 'k'},
{help, no_argument, NULL, 'h'},
+ {version, no_argument, 0, 'z'},
{0, no_argument, NULL, 0}
};
-char opts[] = srvkhc;
+char opts[] = chkrsvz;
int
main (int argc, char **argv)
{
int i;
+ char *version;
+
+ /* Get version number out of the autogenerated revision string */
+ (void *) version = malloc(sizeof(revision));
+ strcpy(version, revision+9);
+ if (version[0] != ':')
+*version=0;
+ else
+ {
+version = version+2;
+char *temp=version + strlen (version);
+while (isspace((int)*--temp) || *temp=='$' temp = version)
+ temp[1]='\0';
+ }
+
+ version[strlen(version)-1]= 0;
while ((i = getopt_long (argc, argv, opts, longopts, NULL)) != EOF)
switch (i)
@@ -1267,17 +1288,27 @@ main (int argc, char **argv)
case 'h':
givehelp = 1;
break;
+ case 'z':
+printf (cygcheck (cygwin) %s\n, version);
+printf (System Checker\n);
+printf (Copyright 1998-2002 Red Hat, Inc.\n);
+fputs (Compiled __DATE__\n, stdout);
+exit (0);
default:
- usage ();
+ usage (stderr, 1);
/*NOTREACHED*/}
argc -= optind;
argv += optind;
- if (argc == 0 !sysinfo !keycheck !check_setup)
-usage ();
+ if (argc == 0 !sysinfo !keycheck !check_setup) {
+ if (givehelp)
+ usage (stdout, 0);
+ else
+ usage (stderr, 1);
+ }
if ((check_setup || sysinfo) keycheck)
-usage ();
+ usage (stderr, 1);
if (keycheck)
return check_keys ();
Re: help/version patches
Adding version numbers is not a bad idea (although, I can't honestly think of a time when it would have helped to have this information). Adding version numbers in the middle of the program, in the middle of a text string is, IMO, a bad idea. The version number should be at the top of the program in a const char version[] = something; and referenced in the version string. As Robert indicated, using the CVS version number is probably the best way to handle this. setup.exe currently uses the CVS version. Use that as an example. I was trying to avoid doing what setup.exe does. In the Makefile.in there is a grep/sed combo that grabs the version from the Changelog and creates a file to include. This is fine for a lot of files that compile into one (setup.exe) but is it really necessary for 13 utils, most of which take only one file of code? What about a sed script that takes that CVS/Entries file and creates something like versions.c with: const char cygcheck_version[]= 1.23; const char cygpath_version[]= 4.56; which could then be #include'd in each file? Then at least no one would have to edit the version code; it would just make. (BTW, I used cygpath.cc as a reference point for the version code; it is currently in a hard-coded printf.) __ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com
Re: help/version patches
Adding version numbers is not a bad idea (although, I can't honestly think of a time when it would have helped to have this information). Adding version numbers in the middle of the program, in the middle of a text string is, IMO, a bad idea. The version number should be at the top of the program in a const char version[] = something; and referenced in the version string. As Robert indicated, using the CVS version number is probably the best way to handle this. setup.exe currently uses the CVS version. Use that as an example. I was trying to avoid doing what setup.exe does. In the Makefile.in there is a grep/sed combo that grabs the version from the Changelog and creates a file to include. This is fine for a lot of files that compile into one (setup.exe) but is it really necessary for 13 utils, most of which take only one file of code? What about a sed script that takes that CVS/Entries file and creates something like versions.c with: const char cygcheck_version[]= 1.23; const char cygpath_version[]= 4.56; which could then be #include'd in each file? Then at least no one would have to edit the version code; it would just make. (BTW, I used cygpath.cc as a reference point for the version code; it is currently in a hard-coded printf.) __ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com
Re: help/version patches
Adding version numbers is not a bad idea (although, I can't honestly think of a time when it would have helped to have this information). Adding version numbers in the middle of the program, in the middle of a text string is, IMO, a bad idea. The version number should be at the top of the program in a const char version[] = something; and referenced in the version string. As Robert indicated, using the CVS version number is probably the best way to handle this. setup.exe currently uses the CVS version. Use that as an example. I was trying to avoid doing what setup.exe does. In the Makefile.in there is a grep/sed combo that grabs the version from the Changelog and creates a file to include. This is fine for a lot of files that compile into one (setup.exe) but is it really necessary for 13 utils, most of which take only one file of code? What about a sed script that takes that CVS/Entries file and creates something like versions.c with: const char cygcheck_version[]= 1.23; const char cygpath_version[]= 4.56; which could then be #include'd in each file? Then at least no one would have to edit the version code; it would just make. (BTW, I used cygpath.cc as a reference point for the version code; it is currently in a hard-coded printf.) __ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com
Re: help/version patches
Adding version numbers is not a bad idea (although, I can't honestly think of a time when it would have helped to have this information). Adding version numbers in the middle of the program, in the middle of a text string is, IMO, a bad idea. The version number should be at the top of the program in a const char version[] = something; and referenced in the version string. As Robert indicated, using the CVS version number is probably the best way to handle this. setup.exe currently uses the CVS version. Use that as an example. I was trying to avoid doing what setup.exe does. In the Makefile.in there is a grep/sed combo that grabs the version from the Changelog and creates a file to include. This is fine for a lot of files that compile into one (setup.exe) but is it really necessary for 13 utils, most of which take only one file of code? What about a sed script that takes that CVS/Entries file and creates something like versions.c with: const char cygcheck_version[]= 1.23; const char cygpath_version[]= 4.56; which could then be #include'd in each file? Then at least no one would have to edit the version code; it would just make. (BTW, I used cygpath.cc as a reference point for the version code; it is currently in a hard-coded printf.) __ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com
Re: help/version patches
On Mon, Feb 25, 2002 at 01:23:51PM -0500, Christopher Faylor wrote: Well, cygpath is wrong. cygcheck is wrong too, under this scenario, but strace not quite as wrong since it at leasts puts the version in its own string. I believe, it used to do something similar to cygpath but I changed it, intending to, someday, make it use cvs versions. cgf
RE: help/version patches
-Original Message- From: Joshua Daniel Franklin [mailto:[EMAIL PROTECTED]] Sent: Monday, February 25, 2002 4:22 PM To: [EMAIL PROTECTED] Subject: help/version patches I've got patches for each of the utils to add/correct the help and version output options. There are 13 in all. I incremented the version number 0.01 from the ones in CVS/Entries with the exception of cygpath. I also added a line based on one found in strace that imbeds the compile date into the version output: Some confusion here: I was meaning that having something like: const char *revision=$Revision: $ ; in the file allows you to then use: const char *version = revision[11]; to obtain the correct version number. Rob
