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 an opinion here? Again, supporting %HOME% was the best CVS came up with, and that was even non-standard
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
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs
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
%USERPROFILE% was just the equivalent of the UNIX .login script are
starting to surface.
I suggest we continue CVS past practice in a backwards compatible fashion.
Yes.
I
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 dirent.h 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
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs
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 dirent.h 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
___
Bug-cvs mailing list
Bug-cvs@gnu.org
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 dirent.h 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 Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
