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
