On 9-Jan-2010, Bruno Haible wrote:
| Hi John,
|
| John W. Eaton wrote:
| > Looking at lib/glob.c in the gnulib sources, there is some
| > Windows-specific code, so it looks like it is intended to work on
| > Windows systems
|
| > Is glob.c expected to work on Windows systems?
|
| At least it passes its unit test on mingw.
|
| > but there are some things that don't look quite
| > right. For example, it does not seem to uniformly use backslash as a
| > directory separator
|
| Probably this is because backslash is used as an escape character, if
| GLOB_NOESCAPE is not specified among the flags.
|
| > Should it accept \, /, or both as the directory separator? I suppose if
| > it allows \ as the directory separator, then GLOB_NOESCAPE would
| > always have to be set.
|
| You say it.
I think my Windows users would be happy to live without GLOB_NOESCAPE
if they could use \ as the directory separator in the character
strings they send to glob and if they could also expect to get
character strings back from glob that use \ as the directory
separator.
But OK, it looks like it would be somewhat painful to "fix" this in
the glob function itself. I suppose instead the best thing is to
write a wrapper to use on Windows systems that first transforms all \
characters to /, calls glob, then converts them back in the resulting
strings...
| > and if WINDOWS32 is defined, it looks for
| > HOMEDRIVE and HOMEPATH instead of calling some Windows API function
|
| That's the old Windows95 way of doing it, but it works also on Windows XP.
| On Windows XP, you can also do getenv("USERPROFILE").
|
| > (maybe GetUserProfileDirectory?).
|
| This would work as well. But why call a function that requires linking
| with userenv.dll [1], when you can get the same information with getenv?
OK.
Thanks,
jwe
