Re: history and val-tags locks.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark D. Baushke wrote: Note that HistoryFile has an argument that would basically be run through strftime, to enable log rotation. Also see the HistorySearch, which would be used as a file glob to locate history files to be read for executions of the `cvs history' command. Hmmm I do not like the BSD glob(3) function and its introduction in CVS would not make sense given we already have POSIX fnmatch() available... It would be better to specify looking for history files in terms of fnmatch() semantics if that is what you intend to use to do the resolution. Hey Mark, Revisiting this since you brought it up, what don't you like about BSD glob(3)? As near as I can tell, the POSIX.2 glob spec implies that it should basically be a wrapper for fnmatch() that opens intervening directories and performs intermediate matches. I ask because I am looking at reimplementing glob at the moment to allow the history search path to include multiple directories. For example, to match a path like: HistoryLogPath=/cvsroot/CVSROOT/history/%Y/%m/%d HistorySearchPath=/cvsroot/CVSROOT/history/*/*/* I need to open /cvsroot/CVSROOT/history, open each directory that matches *, open each directory in those directories that matches *, then open each file in those directories that matches *. IT seems to me that it would be much easier to import the glibc glob() function in GNULIB style, probably by actually first importing it into a GNULIB module, then use that if the local glob() functoin doesn't look useful. Regards, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCek0qLD1OTBfyMaQRAqLcAKDJv4b9hnU8xk8I4OhXmJplvW/ieQCg69KW EfAvZGNU13K1FtFM6n4kb0I= =xyNy -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
getopt and Solaris 10
Apparently Solaris 10 includes a getopt.h and appears to be GNU getopt by all the tests in getopt.m4. Unfortunately, it doesn't support + as the first character of the option string. The original report is here: https://ccvs.cvshome.org/issues/show_bug.cgi?id=248. I'm assuming that GNULIB is still avoiding AC_TRY_RUN since it doesn't work when cross-compiling? I've asked Matthias (the bug reporter, CC'd) if he could find some difference between Solaris 10's getopt and GNU getopt that could be detected at compile time. The alternative would be always using the GNULIB getopt when installed. Regards, Derek ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: [bug-gnulib] getopt and Solaris 10
James Youngman wrote: On Thu, May 05, 2005 at 01:34:24PM -0400, Derek Price wrote: Apparently Solaris 10 includes a getopt.h and appears to be GNU getopt by all the tests in getopt.m4. Unfortunately, it doesn't support + as the first character of the option string. But surely we would now regard that usage as obsolete now? It's been replaced by -- hasn't it? CVS still makes use of it bacause we can parse a line like: cvs -fq -d /cvsroot checkout -P -d newname module and getopt with a + as the first character of the option string kindly stops when it reaches the CVS command checkout. We can then dump everything up to optind: argc -= optind; argv += optind; if (argc 1) usage (usg); and reuse getopt, with a new option string, to parse the arguments to checkout. I don't think users would appreciate having to preceded all CVS commands with a -- argument. cvs -fq -d /cvsroot -- checkout -P -d newname module cvs -fq -d /cvsroot -- update It's a bit redundant. Regards, Derek ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: history and val-tags locks.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Derek Price [EMAIL PROTECTED] writes: Mark D. Baushke wrote: Note that HistoryFile has an argument that would basically be run through strftime, to enable log rotation. Also see the HistorySearch, which would be used as a file glob to locate history files to be read for executions of the `cvs history' command. Hmmm I do not like the BSD glob(3) function and its introduction in CVS would not make sense given we already have POSIX fnmatch() available... It would be better to specify looking for history files in terms of fnmatch() semantics if that is what you intend to use to do the resolution. Hey Mark, Revisiting this since you brought it up, what don't you like about BSD glob(3)? Not all systems provide a glob(3) function. Those that do provide a glob(3) function provide many different variations of implementation because glob existed a long time before the more general fnmatch was written. If you are only planning to use the subset of flags specified by POSIX.2 for glob, then you might be okay with a number of implementations. However, my recollection is that there were a number of implementations that did follow POSIX.2 closely. I think something like these flags are 'standard': GLOB_APPEND, GLOB_DOOFS, GLOB_ERR, GLOB_MARK, GLOB_NOCHECK, GLOB_NOESCAPE, GLOB_NOSORT while some implementations will also provide additional flags like these that are found on OpenBSD and FreeBSD: GLOB_ALTDIRFUNC, GLOB_BRACE, GLOB_MAGCHAR, GLOB_NOMAGIC, GLOB_QUOTE, GLOB_TILDE, GLOB_LIMIT while some GNU implementations add GLOB_ONLYDIR, GLOB_PERIOD some glob() implementations provide those extensions, but have slightly different semantics for them. As for return values, I believe that GLOB_NOSPACE, GLOB_ABORTED and GLOB_NOMATCH are standard, but some implementations may return GLOB_NOSYS to indicate that the function is not supported. In some implementations gl_pathc and gl_offs are not of type size_t as mandated by POSIX.2, but are instead 'int' which was used in many *BSD implementatiosn for years. This can cause interesting problems unless care is taken with how you use glob(). As near as I can tell, the POSIX.2 glob spec implies that it should basically be a wrapper for fnmatch() that opens intervening directories and performs intermediate matches. I ask because I am looking at reimplementing glob at the moment to allow the history search path to include multiple directories. For example, to match a path like: HistoryLogPath=/cvsroot/CVSROOT/history/%Y/%m/%d HistorySearchPath=/cvsroot/CVSROOT/history/*/*/* I need to open /cvsroot/CVSROOT/history, open each directory that matches *, open each directory in those directories that matches *, then open each file in those directories that matches *. IT seems to me that it would be much easier to import the glibc glob() function in GNULIB style, probably by actually first importing it into a GNULIB module, then use that if the local glob() functoin doesn't look useful. I believe that most modern glob() implementations may indeed internally be implemented using fnmatch(), but not all of them are. If you are considering using an internal glob() instead of relying on a library version from the system, then I don't have as much of a problem with it. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCemka3x41pRYZE/gRAnCpAKCcCec+kR6cfo0aGPmk3G6iXnRi7gCgmFLA Fry9D/09sR2uD7pb+mOLlsc= =wiw0 -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: getopt and Solaris 10
Derek Price wrote: Apparently Solaris 10 includes a getopt.h and appears to be GNU getopt by all the tests in getopt.m4. Unfortunately, it doesn't support + as the first character of the option string. The original report is here: https://ccvs.cvshome.org/issues/show_bug.cgi?id=248. Matthias pointed me at the man page for Solaris 10's getopt_long: http://docs.sun.com/app/docs/doc/816-5168/6mbb3hr99?l=ena=view#indexterm-493. Based on that man page, I see two alternatives: 1. Always use getopt_long() in CVS since the Solaris 10 version supports + as the start of the option string even though its getopt() does not. 2. Check for the getopt_clip() function, which should be unique to Solaris, and use the GNULIB getopt.c when it is found. I prefer door #2. Trivial patch attached: 2005-05-05 Derek Price [EMAIL PROTECTED] * m4/getopt.m4 (gl_GETOPT): Use GNULIB getopt on Solaris 10. Matthias, would you mind verifying that this patch fixes CVS on your Solaris 10? Regards, Derek Index: m4/getopt.m4 === RCS file: /cvsroot/gnulib/gnulib/m4/getopt.m4,v retrieving revision 1.8 diff -u -p -r1.8 getopt.m4 --- m4/getopt.m423 Jan 2005 08:06:57 - 1.8 +++ m4/getopt.m45 May 2005 18:51:09 - @@ -32,6 +32,10 @@ AC_DEFUN([gl_GETOPT], dnl and (as of 2004-10-15) mishandles optional option-arguments. AC_CHECK_DECL([optreset], [GETOPT_H=getopt.h], [], [#include getopt.h]) +dnl Solaris 10 getopt doesn't handle `+' as a leading character in an +dnl option string (as of 2005-05-05). +AC_CHECK_FUNCS([getopt_clip], [GETOPT_H=getopt.h]) + if test -n $GETOPT_H; then gl_GETOPT_SUBSTITUTE fi ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: [bug-gnulib] Re: getopt and Solaris 10
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Derek Price wrote: 2005-05-05 Derek Price [EMAIL PROTECTED] * m4/getopt.m4 (gl_GETOPT): Use GNULIB getopt on Solaris 10. Matthias reports that this patch does The Right Thing (tm) on Solaris 10: https://ccvs.cvshome.org/issues/show_bug.cgi?id=248. Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCeoCwLD1OTBfyMaQRAhMHAJ0R2a//oSHXiFaNMjMHTbBP2nGq4gCghqjB plPDozD5LBe5LAyjHA46zQ8= =ChvA -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
