Re: glob on Windows systems

[John W. Eaton]

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