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