RE: help/version patches
--- Robert Collins <[EMAIL PROTECTED]> wrote: > 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 I'm not sure I understand. Hard-code the revision in a const char instead of directly in a printf? Is that just so it's near the top of the file and easier to get to? Or is there a way to automate (without a bunch of sed mess in the Makefile) version numbers? It looks like the mingw headers have a lines like "* $Revision: 1.2 $ " in the comments, but I assume that's for a script of some sort to use. __ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com
Re: /proc and /proc/registry
On Tue, Feb 19, 2002 at 07:31:04PM -0500, Christopher Faylor wrote: >On Wed, Feb 20, 2002 at 12:11:26AM -, Chris January wrote: >>> >>>The attached patch (against cygwin-1.3.9-1/winsup/cygwin) adds support >>> >>>for a /proc virtual filesystem and a read-only version of >>> >>>/proc/registry. I've read http://cygwin.com/assign.txt but need to >>> >>>sort out the legalese before doing anything. Partically fufills Cygwin >>> >>>TODO item: >>> >>>2001-11-08/proc filesystemNicos >>> >>I wish I could get people to look at sending in an assigment *before* >>> >>they start doing work. It would save a lot of time, I think. >>> >Can you please verify if you have received the copyright assignment >>> >form or not. >>> >>> I haven't heard anything. I notify cygwin-patches and cygwin-developers >>> when I hear that I've received an assignment from our main office. >>> >>> Just to verify, you had both you and your employer send a release form, >>> right? >> >>I work as a consultant and I am the sole claimant to the copyright. > >That's good news. > >Boy, I hate this part. This waiting for an assignment part is a real roadblock >to development. I apologize for the necessity of having to go through this. We have the assignment! Please resubmit your patch against current CVS sources. I'll investigate in more detail now that I am unemcumbered. Thanks, cgf
Re: Terminal input processing fix
On Fri, Jan 18, 2002 at 10:59:10PM +0100, Christian LESTRADE wrote: > Hello, > > I would like to submit the following bugfix for theses bugs which appear > mainly when using rxvt: > > * Unable to effectively disable c_cc[] input chars processing (like ^C) > using > $ stty intr '^-' > When I type CTRL-SPACE, I enter a NULL char which is interpreted like ^C > > * In raw mode (stty -icanon), the VDISCARD key (^O) should not be > recognized, > but should be passed to the application Hi Christian, your assignment *finally* arrived. So we could go ahead and apply your patch but... actually I would like to ask you to change it. The reason is that the _POSIX_VDISABLE constant is typically defined in some header file in /usr/include. As is the functionality of CC_EQUAL which is called CCEQ, at least in Linux. So what I'd like you to ask is, could you tweak your patch so that these macros are defined in some appropriate header files, e.g. sys/termios.h? I'm looking forward, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Big checkin to allow 64bit file access
Hi, after Chris has tagged Cygwin for the 1.3.10 release, I've now applied the patches to allow 64 bit off_t. Basically it adds the datatypes needed and new function calls with trailing 64 as `lseek64', `stat64', etc. Additionally I renamed lstat to cygwin_lstat to circumvent a problem with lstat being defined in a newlib header using struct stat while cygwin_lstat uses struct __stat32. All internal file access is using 64 bit offsets now, the old 32 bit functions are just calling the 64 bit functions now. All fhandler methods only exist as 64 bit versions now. These exported foo64 functions are not intended to ever be defined as external API! At one point we switch over to using these functions when linking applications but older applications will still use the old 32 bit API. We don't want to have the LARGEFILE64 discussions as with Linux. There's just one define __CYGWIN_USE_BIG_TYPES__ which will be defined always at one point and which will switch to 64 bit file offsets and 32 bit uid_t/gid_t types. I tested this change against theygwin testsuite but that doesn't mean it's error free so expect problems. What's missing before we can switch over to __CYGWIN_USE_BIG_TYPES__: - Change over to 32 bit uid_t and gid_t in internal datastructures. - Add 32bit uid_t and gid_t function calls. - !!! Tweak newlib to have fpos_t equal to __off64_t and add SUSv2 functions as ftello, fseeko, etc. - Add functions like fgetpos64 to Cygwin to allow overriding fgetpos for new applications (actually, all functions using fpos_t). Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
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: Big checkin to allow 64bit file access
Btw., this introduces two new datatypes, defined by SUSv2 but not yet defined in newlib, blkcnt_t and blksize_t, both used in struct stat. I added the definition of these types to cygwin/include/cygwin/types.h not to trouble newlib for now. Corinna
Re: help/version patches
On Mon, Feb 25, 2002 at 10:15:06AM -0800, Joshua Daniel Franklin wrote: >>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"; Most of the utilities in winsup/utils consist of just one file. So, there is no reason to introduce a separate "version" file. You just use the cvs version of the file. For multi-file programs like dumper and cygcheck, it's probably enough just to use the same technique in the source file which contains main() and let the person who checks stuff in remember to force a checkin for the main file. >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.) Well, cygpath is wrong. cygcheck is wrong too, under this scenario, but 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
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 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. Sorry, I forgot to use the word "IMO" in the above. Obviously there are one of many ways to do this. I think the "const char version[]" at the top and cvs id in the version is the best. However, I'm guilty of doing it the "wrong" way myself. cgf
Re: /proc and /proc/registry
> On Tue, Feb 19, 2002 at 07:31:04PM -0500, Christopher Faylor wrote: > >On Wed, Feb 20, 2002 at 12:11:26AM -, Chris January wrote: > >>> >>>The attached patch (against cygwin-1.3.9-1/winsup/cygwin) adds support > >>> >>>for a /proc virtual filesystem and a read-only version of > >>> >>>/proc/registry. I've read http://cygwin.com/assign.txt but need to > >>> >>>sort out the legalese before doing anything. Partically fufills Cygwin > >>> >>>TODO item: > >>> >>>2001-11-08/proc filesystemNicos > >>> >>I wish I could get people to look at sending in an assigment *before* > >>> >>they start doing work. It would save a lot of time, I think. > >>> >Can you please verify if you have received the copyright assignment > >>> >form or not. > >>> > >>> I haven't heard anything. I notify cygwin-patches and cygwin-developers > >>> when I hear that I've received an assignment from our main office. > >>> > >>> Just to verify, you had both you and your employer send a release form, > >>> right? > >> > >>I work as a consultant and I am the sole claimant to the copyright. > > > >That's good news. > > > >Boy, I hate this part. This waiting for an assignment part is a real roadblock > >to development. I apologize for the necessity of having to go through this. > > We have the assignment! > > Please resubmit your patch against current CVS sources. Please find patch against today's CVS attached. > I'll investigate in more detail now that I am unemcumbered. Regards Chris ChangeLog Description: Binary data proc.patch Description: Binary data
Re: /proc and /proc/registry
On Mon, Feb 25, 2002 at 09:07:10PM -, Chris January wrote: >> Please resubmit your patch against current CVS sources. >Please find patch against today's CVS attached. Ok. Preliminary comments. 1) The copyrights still need to be changed. 2) The code formatting still is not correct. 3) You have a lot of calls to normalize_posix_path. Is that really necessary? It seems to be called a lot. If it is really necessary, I'd prefer that it just be called in dtable::build_fhandler and made the standard "unix_path_name". 4) Could you generate the diff using 'cvs diff -up" I haven't applied the patch to test it yet. Anyone else interested in doing this? cgf
Re: help/version patches
=== - Original Message - From: "Joshua Daniel Franklin" <[EMAIL PROTECTED]> > I'm not sure I understand. Hard-code the revision in a const char man co might enlighten you. Rob
Re: help/version patches
> > I'm not sure I understand. Hard-code the revision in a const char
>
> man co might enlighten you.
>
I'm afraid I've never used CVS/RCS before. :(
Am I reading this right? If I just put $Revision$ in the code, once
it's checked in/out that'll be replaced with the correct version number?
I see strace.cc has a line:
static const char *version_string = "@(#)strace V1.0, Copyright (C) 2001 Red
Hat
Inc., " __DATE__ "\n";
That doesn't look autogenerated, but maybe it is.
Anyway here is a patch for cygcheck that I think does the right thing.
Somebody want to take a look?
__
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com
--- cygcheck.cc-origSun Feb 24 13:28:27 2002
+++ cygcheck.cc Mon Feb 25 21:03:02 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,22 @@ 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+11);
+ version[strlen(version)-1]= 0;
while ((i = getopt_long (argc, argv, opts, longopts, NULL)) != EOF)
switch (i)
@@ -1267,17 +1278,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
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
