bug-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Conrad T. Pino
Subject: RE: Feature Branch Windows Build Broken - lib/glob.c & WINDOWS32
Date: Mon, 30 May 2005 15:06:24 -0700

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

Agreed.
==========================
Expect the "list of possibilities" within a day or so.

In the mean time, can you address the following questions:

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.

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?

3. The "windows-NT/pwd.c" implementation is broken because it does NOT call
the "get_homedir" function.  Do you agree?

4. Should we back port these changes to stable branch?

> Cheers,

Ditto,

> Derek

Conrad





reply via email to

[Prev in Thread] Current Thread [Next in Thread]