glob on Windows systems
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, 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, and if WINDOWS32 is defined, it looks for HOMEDRIVE and HOMEPATH instead of calling some Windows API function (maybe GetUserProfileDirectory?). Is glob.c expected to work on Windows systems? 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. Is there a better way for it to get the home directory info? jwe
Re: glob on Windows systems
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.
> 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?
Bruno
[1] http://msdn.microsoft.com/en-us/library/bb762280(VS.85).aspx
Re: glob on Windows systems
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
