-----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