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

[Derek Price]

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