Re: Feature Branch Windows Build Broken - lib/glob.c & WINDOWS32
Conrad T. Pino wrote:
>I suggest using %USERPROFILE% only as the next fall back for cases where any
>of %HOMEDRIVE%%HOMEPATH% are missing.
>
>
I suggest some more research may be in order here first. Make sure that
setting %USERPROFILE% isn't the perscribed method for overriding
%HOMEDRIVE%%HOMEPATH% when you want to use a network login or somesuch.
If this is the case then %USERPROFILE% would need to have priority...
>We've documented:
>
> %HOME%
>
>
It might be worth reconsidering %HOME% for a general, i.e. GNULIB or
GLIBC glob, implementation. See below.
>If all of %HOME%, %HOMEDRIVE%%HOMEPATH%, %USERPROFILE% are missing then we
>are indeed down to very improbable cases. I introduced %ALLUSERSPROFILE%
>only as another fallback that's a better alternative to hard coded values.
>
>
Again, I'm not sure I agree here. If you expected ~soandso/*.c to
search soandso's home directory for C sources, would you be happier if
your program told you, "No such user `soandso'", or happily returned
with a list of C sources that came from who-knows-where. I think most
users would prefer the easier to spot error message in the problem
case. I think a big part of the task here is simply going to be getting
the order-of-precedence for potential home directory values straight on
Windows.
>There is no environment variable to locate the "Default User" profile.
>I consider that only because the current "glob.c" hard coded value is a
>now obsolete reference to that profile.
>
>The registry is the only way to locate the "Default User" profile and
>the default root directory for creating local profiles.
>
>I'm not proposing we use these and enumerated them as alternatives to
>consider. Earlier in this message I committed to preparing as "list of
>possibilities" and will includes these for discussion purposes.
>
>
Can you justify that using a "Default User" directory is the correct
thing to do when the logged in or requested user's directory cannot be
found? I suspect this may be another case where an error message is
better, but perhaps you have a use case on Windows I am unfamilar with?
>1. You proposed modifying "pwd.c" but when I searched for HOME, HOMEDRIVE
>& HOMEPATH references I found this in "windows-NT/filesubr.c":
>
> char *
> get_homedir ()
> {
> static char *pathbuf;
> char *hd, *hp;
>
> if (pathbuf != NULL)
> return pathbuf;
> else if ((hd = getenv ("HOME")))
> return hd;
> else if ((hd = getenv ("HOMEDRIVE")) && (hp = getenv ("HOMEPATH")))
> {
> pathbuf = xmalloc (strlen (hd) + strlen (hp) + 5);
> strcpy (pathbuf, hd);
> strcat (pathbuf, hp);
>
> return pathbuf;
> }
> else
> return NULL;
> }
>
>which looks like the natural place to make the modifications.
>
>
I disagree. pwd.c is implementing several standard UNIX/POSIX APIs for
locating information about a logged in or other user. As such, they
seem like the likliest candidates for acceptance into GNULIB. Such a
module could be plugged directly into a UNIX app on Windows and
potentially allow it to compile and work there.
Also, since %HOME% is non-standard on Windows, perhaps it is best to
leave %HOME% in the CVS get_homedir function, and implement whatever
seems to make standard sense on Windows in the pwd.c stuff. When we
submit it to GNULIB/GLIBC, we can mention that we made this choice in
case there is disagreement.
>2. In the "get_homedir" implementation shown above, disposal of the "xmalloc"
>provided "pathbuf" is moot since it's allocated once and process termination
>cleans up all messes. Do you agree?
>
>
Yes.
>3. The "windows-NT/pwd.c" implementation is broken because it does NOT call
>the "get_homedir" function. Do you agree?
>
>
No. Again, pwd.c should implement the UNIX/POSIX APIs. get_homedir can
wrap CVS functionality we think it is unlikely others will wish to
share, like consulting %HOME%.
>4. Should we back port these changes to stable branch?
>
>
I don't think so. You are welcome to explore the code paths and try to
determine where the pwd.c stubs may have been disabling functionality on
Windows such that fixing pwd.c should be considered a bug fix, but I am
inclined to call all of this new functionality.
It is probably worth noting that even in glob.c, these windows-NT/pwd.c
fixes wouldn't fix much in CVS. The glob is being used to find files in
the repository and for the new HistorySearchPath config option. Only in
the second case could processing `~' occur and I'm not sure it is
particularly useful. Of course, that's not to say that GNULIB and GLIBC
might not value the contribution.
Cheers,
Derek
___
Bug-cvs mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: Feature Branch Windows Build Broken - lib/glob.c & WINDOWS32
Hi Derek, > From: Derek Price > > >I propose we do both, I'll edit and test, you coach: > > Sure. Great. I plan to stretch this out and finish in about a week. > >I will improve "pwd.c" also so long as cutting and pasting is acceptable > >between "pwd.c" and "glob.c" is acceptable. > > Hrm? Cutting and pasting in which direction. You can try and get the > pwd.c module into GNULIB it might work. I just ran across the GNULIB > execute module which seems to have some Windows specific code. The > macros stuff is already in GNULIB, so if you could abstract some of the > Windows specific stuff out into those macros, I think it can only simplify. We have the greatest freedom in "pwd.c" which is where I'll start. Once we are happy with what we've done for ourselves then we can decide what should be pasted back into "glob.c" for submission to GLib and GNULib teams. > I'm not sure why earlier CVS developers missed the %USERPROFILE% value > then, unless it was missing in earlier versions of NT, but if you say > so... Anyhow, if we leave %HOMEDRIVE%%HOMEPATH% as a fallback value, it > shouldn't be a big deal to add the new handling. I suggest using %USERPROFILE% only as the next fall back for cases where any of %HOMEDRIVE%%HOMEPATH% are missing. We've documented: %HOME% %HOMEDRIVE%%HOMEPATH% and anything we do now should have lower priority. > Why even process ALLUSERSPROFILE here? As long as %USERPROFILE% and > %HOMEDRIVE%%HOMEPATH% are susually set, then if they are unset then > something is wrong, I would think. It just doesn't sound like a > reasonable fallback to me. The UNIX fallback, or even "secure" method > is to read the /etc/passwd file. Maybe the closest fallback on Windows > is to read the registry? If all of %HOME%, %HOMEDRIVE%%HOMEPATH%, %USERPROFILE% are missing then we are indeed down to very improbable cases. I introduced %ALLUSERSPROFILE% only as another fallback that's a better alternative to hard coded values. > >Power users to modify the registry can relocate their profile away from the > >default profile root. > > > >Networked users with file server resident profiles is another case. > > True. Is %USERPROFILES% the best we can do here? I believe the "%HOMEDRIVE%%HOMEPATH% == %USERPROFILE%" will hold and plan to test both cases. I will modify a local profile and create a file server resident profile to test these cases. > >Windows has no support for "~" and similar. We can provide it as a reference > >to "$HOME", "$USERPROFILE" and/or "$HOMEDRIVE", "$HOMEPATH" combination. > > As part of glob, and to support consistent usage in CVS config files, > supporting "~" still seems reasonable. Determining what that means is > up to us. CVS supported the non-standard $HOME on Windows 95/98/ME > because there was nothing standard. It is possible that continuing to > support that for glob is fine sine it won't normally be set anyhow, but > what we should aim at is whatever seems morally closest in Windows. Agreed. > Newest is probably best, from the standpoint of supporting what > Microsoft declares most current first. Supporting the legacy stuff in > chronologically reverse order should manage to support both old systems > and those who unset their %USERPROFILE% to allow their old setup, which > knew how to deal with %HOMEDRIVE%%HOMEPATH%, or whatever, to work. I'll enumerate a list of possibilities shortly and then we can order them. > Is %USERPROFILE% and %HOMEDRIVE%%HOMEPATH% really the same thing? Now > that you have me talking about it, old memories that say the > %USERPROFILE% was just the equivalent of the UNIX .login script are > starting to surface. Other than user intervention I believe so but will continue testing it as an unproven hypothesis. > >I assume my suggestion to use the registry is not needed based upon the > >lack of feedback and the use of native Win32 API calls likely to create > >resistance from GLib and GNULib. > > Like I said, maybe we can get it in, especially if it is a new module. > Even if it isn't a new module, then we can support it in CVS, > regardless, and the effort is not a complete waste. If GNULIB folks > ever need it they can swipe it at their convenience. There is no environment variable to locate the "Default User" profile. I consider that only because the current "glob.c" hard coded value is a now obsolete reference to that profile. The registry is the only way to locate the "Default User" profile and the default root directory for creating local profiles. I'm not proposing we use these and enumerated them as alternatives to consider. Earlier in this message I committed to preparing as "list of possibilities" and will includes these for discussion purposes. > >I deliberately ignored Windows 95, 98 and Me when writing the drasft as > >I have not worked with any of these systems in years. I don't care but > >will include them consist with CVS Project policy whatever that may be. > >Can you share
Re: Feature Branch Windows Build Broken - lib/glob.c & WINDOWS32
Conrad T. Pino wrote:
>I propose we do both, I'll edit and test, you coach:
>
>
Sure.
>I'm OK with leaving WINDOWS32 undefined in our project. I'd like to see
>an improvement in the WINDOWS32 code for the benefit of other projects if
>for no other reason than saying thank you to GLib and GNULib by sending
>back some useful code.
>
>I will improve "pwd.c" also so long as cutting and pasting is acceptable
>between "pwd.c" and "glob.c" is acceptable.
>
>
Hrm? Cutting and pasting in which direction. You can try and get the
pwd.c module into GNULIB it might work. I just ran across the GNULIB
execute module which seems to have some Windows specific code. The
macros stuff is already in GNULIB, so if you could abstract some of the
Windows specific stuff out into those macros, I think it can only simplify.
>The bit of work concerns me only if we have an open issue that breaks the
>Windows build. If the Windows build works I'll work on this issue.
>
>
I believe the Windows build was working last night and probably is again
after my recent commit..
>I assume "inadvertantly fix...former" is the "pwd.c" improvement. If so
>I share your motivation and agree.
>
>
Yes.
>>Do you really expect this to be set if %USERPROFILE% is not? It depends
>>on it...
>>
>>
>
>Windows NT, 2000, XP and 2003 will set the values. I expect trouble only when
>the user has used command window to undefine or redefine which is unlikely.
>
>
I'm not sure why earlier CVS developers missed the %USERPROFILE% value
then, unless it was missing in earlier versions of NT, but if you say
so... Anyhow, if we leave %HOMEDRIVE%%HOMEPATH% as a fallback value, it
shouldn't be a big deal to add hte new handling.
>No "ALLUSERSPROFILE" does not depend on "USERPROFILE" and you are correct on
>it's use as shorthand to illustrate they typically have a common root.
>
>
Why even process ALLUSERSPROFILE here? As long as %USERPROFILE% and
%HOMEDRIVE%%HOMEPATH% are susually set, then if they are unset then
something is wrong, I would think. It just doesn't sound like a
reasonable fallback to me. The UNIX fallback, or even "secure" method
is to read the /etc/passwd file. Maybe the closest fallback on Windows
is to read the registry?
>Power users to modify the registry can relocate their profile away from the
>default profile root.
>
>Networked users with file server resident profiles is another case.
>
>
True. Is %USERPROFILES% the best we can do here?
>Windows has no support for "~" and similar. We can provide it as a reference
>to "$HOME", "$USERPROFILE" and/or "$HOMEDRIVE", "$HOMEPATH" combination.
>
>
As part of glob, and to support consistent usage in CVS config files,
supporting "~" still seems reasonable. Determining what that means is
up to us. CVS supported the non-standard $HOME on Windows 95/98/ME
because there was nothing standard. It is possible that continuing to
support that for glob is fine sine it won't normally be set anyhow, but
what we should aim at is whatever seems morally closest in Windows.
>>>+ if (home_dir == NULL || home_dir[0] == '\0')
>>>+ {
>>>+ /*"$SystemDrive/users" is Windows NT 4 specific
>>>+
>>>+NEW INSTALLS of Windows 2000 and later use
>>>+"$SystemDrive/Documents and Settings"
>>>+
>>>+UPGRADES use previous location
>>>+
>>>+The default user profile can't be found with an
>>>environment
>>>+variable. It's location is in the Windows
>>>registry.
>>>+
>>>+The SystemDrive environment variable is an
>>>alternative.
>>>+*/
>>>+ home_dir = "c:/users/default"; /* poor default */
>>>+ }
>>>
>>>
>>CVS already uses %HOMEDRIVE%%HOMPATH% on windows (set automatically for
>>a long time on NT and carried through to XP), which sounds like another
>>good possibility. I think it might predate %USERPROFILE%, so
>>%USERPROFILE% should probably be checked first. It might be nice to
>>roll this all together into one place, like the pwd.c stuff, to avoid
>>having different portions of hte program do different things on Windows
>>with respect to $HOME. Then the get_homedir() function from
>>windows-NT/filesubr.c should just check %HOME% then make the getpwname
>>(getlogin()) call.
>>
>>
>
>I can't say which came first but it's not particularly relevant to me.
>
>
Newest is probably best, from the standpoint of supporting what
Microsoft declares most current first. Supporting the legacy stuff in
chronologically reverse order should manage to support both old systems
and those who unset their %USERPROFILE% to allow their old setup, which
knew how to deal with %HOMEDRIVE%%HOMEPATH%, or whatever, to work.
Is %USERPROFILE% and %HOMEDRIVE%%HOMEPATH% really the same thing? Now
that you have me talking about it, old memories that say the
%USERPROFIL
RE: Feature Branch Windows Build Broken - lib/glob.c & WINDOWS32
Hi Derek,
> From: Derek Price
>
> Conrad T. Pino wrote:
>
> >Yes, the Windows build completes. Can you explain what "home_dir" value
> >will be in the "WINDOWS32" undefined logic?
>
> It looks like it would call, basically, getpwnam (getlogin()). There
> are substitutes for both in windows-NT/pwd.c, though it doesn't look
> like they are doing much useful.
I'd like to see a general improvement.
> >How about defining "WINDOWS32" and using the patch below?
>
> Maybe this would be preferable. This would enable some of the [a-z]:/
> swithcing other places in the file as well. Of course, it's possible
> much of that could be abstracted out using the FILE_SYSTEM_PREFIX_LEN &
> ISSLASH macros.
I don't have a preference at the moment and I agree with macros comment.
> My feeling is that it might be nice to move as much of your patch as
> possible into pwd.c, abstract out as much of the drive letter prefix
> stuff as possible into the aformentioned macros, skip defining
> WINDOWS32, and see how things look, but it might be a bit of work. If
> you'd rather take the easy way out, I won't argue, but the former might
> inadvertantly fix a few other hitherto unnoticed or ignored bugs on Windows.
I propose we do both, I'll edit and test, you coach:
I'm OK with leaving WINDOWS32 undefined in our project. I'd like to see
an improvement in the WINDOWS32 code for the benefit of other projects if
for no other reason than saying thank you to GLib and GNULib by sending
back some useful code.
I will improve "pwd.c" also so long as cutting and pasting is acceptable
between "pwd.c" and "glob.c" is acceptable.
The bit of work concerns me only if we have an open issue that breaks the
Windows build. If the Windows build works I'll work on this issue.
I assume "inadvertantly fix...former" is the "pwd.c" improvement. If so
I share your motivation and agree.
> >The #if logic was cut from "lib/glob.c" lines 53 through 71 with the
> >extras discarded. My patch is a quick hack. I would appreciate it if
> >you choose to make improvements.
>
> No, I think what you did is fine, at least until more than one #ifdef is
> needed. The version in glob.c is nice for making the rest of the
> dirent/direct switching pretty transparent, but it's not needed yet.
Thank you.
> >Index: lib/glob.c
> >===
> >RCS file: /cvs/ccvs/lib/glob.c,v
> >retrieving revision 1.15
> >diff -u -p -r1.15 glob.c
> >--- lib/glob.c 25 May 2005 20:23:38 - 1.15
> >+++ lib/glob.c 26 May 2005 10:57:36 -
> >@@ -524,8 +525,45 @@ glob (const char *pattern, int flags,
> > home_dir = "SYS:";
> > # else
> > # ifdef WINDOWS32
> >+ /* Windows doesn't set HOME, honor it if user sets it */
> > if (home_dir == NULL || home_dir[0] == '\0')
> >-home_dir = "c:/users/default"; /* poor default */
> >+ {
> >+ /* Windows sets USERPROFILE like UNIX sets HOME */
> >+ home_dir = getenv( "USERPROFILE" );
> >+ }
> >+ if (home_dir == NULL || home_dir[0] == '\0')
> >+ {
> >+ /* Windows sets APPDATA to "$USERPROFILE/Application Data" */
> >+ home_dir = getenv( "APPDATA" );
> >+ }
>
> Do you really expect this to be set if %USERPROFILE% is not? It depends
> on it...
Windows NT, 2000, XP and 2003 will set the values. I expect trouble only when
the user has used command window to undefine or redefine which is unlikely.
> >+ if (home_dir == NULL || home_dir[0] == '\0')
> >+ {
> >+ /* Windows sets ALLUSERSPROFILE to "$USERPROFILE/../All
> >Users" */
> >+ home_dir = getenv( "ALLUSERSPROFILE" );
> >+ }
>
> Does this really depend on %USERPROFILE% too or is this just your
> shorthand to refer to the user-profile directory?
No "ALLUSERSPROFILE" does not depend on "USERPROFILE" and you are correct on
it's use as shorthand to illustrate they typically have a common root.
Power users to modify the registry can relocate their profile away from the
default profile root.
Networked users with file server resident profiles is another case.
> >+ if (home_dir == NULL || home_dir[0] == '\0')
> >+ {
> >+ /* Windows sets SystemRoot to installation value typically
> >+ C:/WinNT but frequently C:/Windows */
> >+ /* This may be a bad idea but it's an alternative to the root
> >*/
> >+ home_dir = getenv( "SystemRoot" );
> >+ }
>
> I'm not sure how I feel about using SystemRoot as a fallback for ~ or
> ~username... sounds unintuitive and possibly dangerous.
Windows has no support for "~" and similar. We can provide it as a reference
to "$HOME", "$USERPROFILE" and/or "$HOMEDRIVE", "$HOMEPATH" combination.
> >+ if (home_dir == NULL || home_dir[0] == '\0')
> >+ {
> >+ /*"$SystemDrive/users" is Windows NT 4 specific
> >+
> >+NEW I
Re: Feature Branch Windows Build Broken - lib/glob.c & WINDOWS32
Conrad T. Pino wrote:
>Yes, the Windows build completes. Can you explain what "home_dir" value
>will be in the "WINDOWS32" undefined logic?
>
>
It looks like it would call, basically, getpwnam (getlogin()). There
are substitutes for both in windows-NT/pwd.c, though it doesn't look
like they are doing much useful.
>How about defining "WINDOWS32" and using the patch below?
>
>
Maybe this would be preferable. This would enable some of the [a-z]:/
swithcing other places in the file as well. Of course, it's possible
much of that could be abstracted out using the FILE_SYSTEM_PREFIX_LEN &
ISSLASH macros.
My feeling is that it might be nice to move as much of your patch as
possible into pwd.c, abstract out as much of the drive letter prefix
stuff as possible into the aformentioned macros, skip defining
WINDOWS32, and see how things look, but it might be a bit of work. If
you'd rather take the easy way out, I won't argue, but the former might
inadvertantly fix a few other hitherto unnoticed or ignored bugs on Windows.
>>Is it too much to hope for that Windows has and implements
>>the readdir() family of functions and defining HAVE_DIRENT_H would be
>>enough here?
>>
>>
>
>Yes, that's entirely too much to hope for. The Windows build fakes an
>"ndir.h" implementation in the "windows-NT" director and I committed a
>patch to "lib/glob_.h" that supports the "ndir.h" flavor.
>
>The #if logic was cut from "lib/glob.c" lines 53 through 71 with the
>extras discarded. My patch is a quick hack. I would appreciate it if
>you choose to make improvements.
>
>
No, I think what you did is fine, at least until more than one #ifdef is
needed. The version in glob.c is nice for making the rest of the
dirent/direct switching pretty transparent, but it's not needed yet.
>Index: lib/glob.c
>===
>RCS file: /cvs/ccvs/lib/glob.c,v
>retrieving revision 1.15
>diff -u -p -r1.15 glob.c
>--- lib/glob.c 25 May 2005 20:23:38 - 1.15
>+++ lib/glob.c 26 May 2005 10:57:36 -
>@@ -524,8 +525,45 @@ glob (const char *pattern, int flags,
> home_dir = "SYS:";
> # else
> # ifdef WINDOWS32
>+/* Windows doesn't set HOME, honor it if user sets it */
> if (home_dir == NULL || home_dir[0] == '\0')
>-home_dir = "c:/users/default"; /* poor default */
>+{
>+/* Windows sets USERPROFILE like UNIX sets HOME */
>+home_dir = getenv( "USERPROFILE" );
>+}
>+if (home_dir == NULL || home_dir[0] == '\0')
>+{
>+/* Windows sets APPDATA to "$USERPROFILE/Application Data" */
>+home_dir = getenv( "APPDATA" );
>+}
>
>
Do you really expect this to be set if %USERPROFILE% is not? It depends
on it...
>+if (home_dir == NULL || home_dir[0] == '\0')
>+{
>+/* Windows sets ALLUSERSPROFILE to "$USERPROFILE/../All
>Users" */
>+home_dir = getenv( "ALLUSERSPROFILE" );
>+}
>
>
Does this really depend on %USERPROFILE% too or is this just your
shorthand to refer to the user-profile directory?
>+if (home_dir == NULL || home_dir[0] == '\0')
>+{
>+/* Windows sets SystemRoot to installation value typically
>+ C:/WinNT but frequently C:/Windows */
>+/* This may be a bad idea but it's an alternative to the root
>*/
>+home_dir = getenv( "SystemRoot" );
>+}
>
>
I'm not sure how I feel about using SystemRoot as a fallback for ~ or
~username... sounds unintuitive and possibly dangerous.
>+if (home_dir == NULL || home_dir[0] == '\0')
>+{
>+/*"$SystemDrive/users" is Windows NT 4 specific
>+
>+ NEW INSTALLS of Windows 2000 and later use
>+ "$SystemDrive/Documents and Settings"
>+
>+ UPGRADES use previous location
>+
>+ The default user profile can't be found with an
>environment
>+ variable. It's location is in the Windows
>registry.
>+
>+ The SystemDrive environment variable is an
>alternative.
>+ */
>+home_dir = "c:/users/default"; /* poor default */
>+}
>
>
CVS already uses %HOMEDRIVE%%HOMPATH% on windows (set automatically for
a long time on NT and carried through to XP), which sounds like another
good possibility. I think it might predate %USERPROFILE%, so
%USERPROFILE% should probably be checked first. It might be nice to
roll this all together into one place, like the pwd.c stuff, to avoid
having different portions of hte program do different things on Windows
with respect to $HOME. Then the get_homedir() function from
windows-NT/filesubr.c should just check %HOME% then make the getpwname
(getlogin()) call.
Regards,
Derek
_
RE: Feature Branch Windows Build Broken - lib/glob.c & WINDOWS32
Hi Derek,
> From: Derek Price
>
> >Compiling...
> >glob.c
> >h:\conrad\projects\cvs-1.12\lib\glob.c(535) : warning C4013: 'sysconf'
> undefined; assuming extern returning int
> >h:\conrad\projects\cvs-1.12\lib\glob.c(535) : error C2065:
> '_SC_LOGIN_NAME_MAX' : undeclared identifier
>
> I've checked in what I hope is a fix for this.
Yes, the Windows build completes. Can you explain what "home_dir" value
will be in the "WINDOWS32" undefined logic?
How about defining "WINDOWS32" and using the patch below?
> Is it too much to hope for that Windows has and implements
> the readdir() family of functions and defining HAVE_DIRENT_H would be
> enough here?
Yes, that's entirely too much to hope for. The Windows build fakes an
"ndir.h" implementation in the "windows-NT" director and I committed a
patch to "lib/glob_.h" that supports the "ndir.h" flavor.
The #if logic was cut from "lib/glob.c" lines 53 through 71 with the
extras discarded. My patch is a quick hack. I would appreciate it if
you choose to make improvements.
> Cheers,
Ditto,
> Derek
Conrad
Index: lib/glob.c
===
RCS file: /cvs/ccvs/lib/glob.c,v
retrieving revision 1.15
diff -u -p -r1.15 glob.c
--- lib/glob.c 25 May 2005 20:23:38 - 1.15
+++ lib/glob.c 26 May 2005 10:57:36 -
@@ -524,8 +525,45 @@ glob (const char *pattern, int flags,
home_dir = "SYS:";
# else
# ifdef WINDOWS32
+ /* Windows doesn't set HOME, honor it if user sets it */
if (home_dir == NULL || home_dir[0] == '\0')
-home_dir = "c:/users/default"; /* poor default */
+ {
+ /* Windows sets USERPROFILE like UNIX sets HOME */
+ home_dir = getenv( "USERPROFILE" );
+ }
+ if (home_dir == NULL || home_dir[0] == '\0')
+ {
+ /* Windows sets APPDATA to "$USERPROFILE/Application Data" */
+ home_dir = getenv( "APPDATA" );
+ }
+ if (home_dir == NULL || home_dir[0] == '\0')
+ {
+ /* Windows sets ALLUSERSPROFILE to "$USERPROFILE/../All
Users" */
+ home_dir = getenv( "ALLUSERSPROFILE" );
+ }
+ if (home_dir == NULL || home_dir[0] == '\0')
+ {
+ /* Windows sets SystemRoot to installation value typically
+C:/WinNT but frequently C:/Windows */
+ /* This may be a bad idea but it's an alternative to the root
*/
+ home_dir = getenv( "SystemRoot" );
+ }
+ if (home_dir == NULL || home_dir[0] == '\0')
+ {
+ /*"$SystemDrive/users" is Windows NT 4 specific
+
+ NEW INSTALLS of Windows 2000 and later use
+ "$SystemDrive/Documents and Settings"
+
+ UPGRADES use previous location
+
+ The default user profile can't be found with an
environment
+ variable. It's location is in the Windows
registry.
+
+ The SystemDrive environment variable is an
alternative.
+ */
+ home_dir = "c:/users/default"; /* poor default */
+ }
# else
if (home_dir == NULL || home_dir[0] == '\0')
{
___
Bug-cvs mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature Branch Windows Build Broken - lib/glob.c & WINDOWS32
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Conrad T. Pino wrote: >Oops, I forgot the error message which follows. > >Compiling... >glob.c >h:\conrad\projects\cvs-1.12\lib\glob.c(535) : warning C4013: 'sysconf' undefined; assuming extern returning int >h:\conrad\projects\cvs-1.12\lib\glob.c(535) : error C2065: '_SC_LOGIN_NAME_MAX' : undeclared identifier I've checked in what I hope is a fix for this. >h:\conrad\projects\cvs-1.12\lib\glob.c(1171) : warning C4133: ':' : incompatible types - from 'struct direct *' to 'struct dirent *' >h:\conrad\projects\cvs-1.12\lib\glob.c(1171) : warning C4133: 'initializing' : incompatible types - from 'struct dirent *' to >'struct direct *' Is it too much to hope for that Windows has and implements the readdir() family of functions and defining HAVE_DIRENT_H would be enough here? Cheers, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFClN+OLD1OTBfyMaQRAi6LAJ0WECXd7eJETb52st5XbAcwTPsCyACg61oc X0Mj+ydzrG/osYJ1DCtmIWo= =2GBK -END PGP SIGNATURE- ___ Bug-cvs mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature Branch Windows Build Broken - lib/glob.c & WINDOWS32
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Conrad T. Pino wrote: >Hi Derek, > >The latest "lib/glob.c" introduced new macros not addressed >in the m4 stuff. Of interest are "WINDOWS32" and perhaps >"__MSDOS__" as "#define" and "#undef" respectively. > >Should I be expecting an "m4" solution which means I edit No. >"windows-NT/config.h.in.in" or not which means I edit the >"windows-NT/config.h.in.footer" instead? This stuff was cut and pasted from the glibc glob.c file. Isn't __MSDOS__ defined automatically by some compilers? Considering that I cannot find WINDOWS32 in any of the glibc header files, I would expect WINDOWS32 to be defined similarly. Looking at the code that is switching on those symbols, it looks mostly like directory stuff to allow C:/ style paths, so if it turns out not to be defined by your compiler it should be pretty harmless to just define one or the other for now there. I'm not so sure about the CONVERT_D_INO stuff and REAL_DIR_ENTRY stuff. Regards, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFClNzILD1OTBfyMaQRAuSaAKDfMOkgRHtBMgGWgDqIgtUS/WA1bACg8OYB yCCGQzMwcmEGpQQ6SeW6iv4= =oD74 -END PGP SIGNATURE- ___ Bug-cvs mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: Feature Branch Windows Build Broken - lib/glob.c & WINDOWS32
Oops, I forgot the error message which follows. Compiling... glob.c h:\conrad\projects\cvs-1.12\lib\glob.c(535) : warning C4013: 'sysconf' undefined; assuming extern returning int h:\conrad\projects\cvs-1.12\lib\glob.c(535) : error C2065: '_SC_LOGIN_NAME_MAX' : undeclared identifier h:\conrad\projects\cvs-1.12\lib\glob.c(1171) : warning C4133: ':' : incompatible types - from 'struct direct *' to 'struct dirent *' h:\conrad\projects\cvs-1.12\lib\glob.c(1171) : warning C4133: 'initializing' : incompatible types - from 'struct dirent *' to 'struct direct *' Error executing cl.exe. ___ Bug-cvs mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-cvs
