windows-NT/pwd.c - struct passwd - Home Directory

[Conrad T. Pino]

Hi Derek,

I'm starting new threads for specific questions related to below:

> From: Derek Price
> Subject: Re: Feature Branch Windows Build Broken - lib/glob.c & WINDOWS32
> 
> >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%.

We agree on the standard "pwd.c" should adhere to.  Compatibility layers must
be compatible with their respective standards.

What I don't understand is why "." is a reasonable home directory according
to the "getpwuid" implementation:

        static char *home_dir = ".";    /* we feel (no|every)where at home */

        /* return something like a username in a (butchered!) passwd structure. 
*/
        struct passwd *
        getpwuid (int uid)
        {
          pw.pw_name = getlogin ();
          pw.pw_dir = home_dir;
          pw.pw_shell = login_shell;
          pw.pw_uid = 0;

          return &pw;
        }

Can you elaborate please?

My thought was along the lines of:

        struct passwd *
        getpwuid (int uid)
        {
          pw.pw_name = getlogin ();
-         pw.pw_dir = home_dir;
+         pw.pw_dir = get_homedir ();
          pw.pw_shell = login_shell;
          pw.pw_uid = 0;

          return &pw;
        }

which works with Windows files but creates a stack overflow loop when attempting
to use the "src/filesubr.c" implementation.

Another thought can take use one step closer to using "src/filesubr.c" instead
of "windows-NT/filesubr.c" by defining "wnt_homedir" in "woe32.c":

        struct passwd *
        getpwuid (int uid)
        {
          pw.pw_name = getlogin ();
-         pw.pw_dir = home_dir;
+         pw.pw_dir = wnt_homedir ();
          pw.pw_shell = login_shell;
          pw.pw_uid = 0;

          return &pw;
        }

then the "get_homedir" implementation in "src/filesubr.c" works as "getpwuid"
returns a useful value where the "." returned now doesn't seem useful at all.

A grep of "get_homedir" usage (below) leads me to believe that whichever way
we choose, functions "getpwuid" and "get_homedir" should present a consistent
view of where the home directory is on a given platform.

> Cheers,

Ditto,

> Derek

Conrad

H:\Conrad\Projects\cvs-1.12-edit>grep -dn get_homedir *.c
File emx\filesubr.c:
703     get_homedir ()
File os2\filesubr.c:
755     get_homedir ()
File src\cvsrc.c:
67          homedir = get_homedir ();
File src\expand_path.c:
229                 e = get_homedir ();
File src\filesubr.c:
787        get_homedir which remembers root's home directory in the static
788        variable.  Then the switch happens and get_homedir might return a
791        fix would be to make the value returned by get_homedir only good
797        get_homedir won't get called until after the switch in user ID.
803     get_homedir (void)
File src\history.c:
784             pwdir = get_homedir ();
File src\ignore.c:
84          home_dir = get_homedir ();
File src\login.c:
52          homedir = get_homedir ();
File src\wrapper.c:
114         homedir = get_homedir ();
File vms\filesubr.c:
907     get_homedir ()
File windows-NT\filesubr.c:
758        get_homedir.  Of course you lose .cvsrc and .cvsignore, but many
767     get_homedir ()

H:\Conrad\Projects\cvs-1.12-edit>