Re: Feature Branch Windows Build Broken - lib/glob.c & WINDOWS32

[Derek Price]

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 was aware of "HOMEDRIVE" and "HOMEPATH" when I drafted the patch but
>didn't include them because I don't know how to cleanly deal with the
>allocation and disposal issues the concatenation requires.  Typical
>NT and derivative systems will have:
>
>       %HOMEDRIVE%%HOMEPATH% == %USERPROFILE%
>
>I expect the above identity to be broken only if the users has done so.
>  
>

Oh, OK.

>Since CVS documents "HOME", "HOMEDRIVE" and "HOMEPATH", we should give
>these priority over my suggested addition which include "USERPROFILE".
>=======================================================================
>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.

>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 there.  Users just had to set %HOME% to use CVS.

Cheers,

Derek