windows-NT/pwd.c - struct passwd - Home Directory
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:
787get_homedir which remembers root's home directory in the static
788variable. Then the switch happens and get_homedir might return a
791fix would be to make the value returned by get_homedir only good
797get_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:
758get_homedir. Of course you lose .cvsrc and .cvsignore, but many
767 get_homedir ()
H:\Conrad\Projects\cvs-1.12-edit>
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature Branch Windows Build Broken - lib/glob.c & WINDOWS32
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
Re: Module "run.c" Interface Standardized - Feature To Stable Branch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Conrad T. Pino wrote: >I'll implement at least Option 2 by Wednesday. Do you have any preferred >language or points you'd want covered in the "FIXME" note? Nothing in particular. Have at it. Cheers, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCm5FkLD1OTBfyMaQRAt79AKCuZL4zTBKRpmBRYNCEPlPjjpdYqQCeIpNK A157dndVzb7yQq/1HFrO4dA= =788F -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: Feature Branch Windows Build Broken - lib/glob.c & WINDOWS32
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
RE: Module "run.c" Interface Standardized - Feature To Stable Branch
Hi Derek, > From: Derek Price > > >2. If no one steps forward to assist with building should > >we attempt a fix that can't be tested nevertheless? > > The policy, as I thought was documented in HACKING or somesuch, is that > we do not bother. I can't find the original text in a quick scan, however. > > In general, if there is no way to tell if it works, what is the point? > In reality, I ocassionally cut and paste a new function or API change > when I change it elsewhere, but more often lately, I don't bother. If > someone decides to fix the platform up, it should be easy enough to > trace the missing functions to their counter-parts in src, lib. or wherever. I agree on both points which is part of my motivation to raise the issue. As I see it we have three choices: 1. Do nothing more to "os2/run.c". 2. Add "FIXME: ..." to "os2/run.c". 3. Cut and paste new functions into "os2/run.c" Option 1 penalizes innocent OS/2 newbies by wasting their time when I feel we should reward newbies by easing their entry when economical to do so. I'll implement at least Option 2 by Wednesday. Do you have any preferred language or points you'd want covered in the "FIXME" note? > Cheers, Ditto, > Derek ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: OpenBSD 3.6 sparc64 stable crash
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alexander Taler wrote: > Core was generated by `cvs'. > Program terminated with signal 10, Bus error. > #0 0x0014f148 in run_add_arg_p (iargc=0x7a8000, > iarg_allocated=0x7a8004, iargv=0x7a7ff8, s=0x293838 "diff") > at /home/cvstest/cvs-nightly-cvs1-11-x-branch/src/run.c:81 > 81 if (*iargc >= *iarg_allocated) Why would the dereference of an int * or a size_t * or the comparison of the resulting int and size_t cause a bus error? Your stack trace makes it look like there are valid addresses in the inputs (iargc=0x7a8000, iarg_allocated=0x7a8004) and this same code is compiling and passing test on 7 or more other platforms, including NetBSD 1.6.1 and BSD/OS though, as far as I know, none of the platforms are 64-bit. Can you be a little more specific about the problem? Perhaps loading the core back into your debugger and trying to print some values (e.g. iargc, *iargc, iarg_allocated, *iarg_allocated), might provide more clues. Regards, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCmzi/LD1OTBfyMaQRAsXyAJ9yaDIHvIBY5njvFV6f3dBFbDvxQQCgpunU tJnHHSFgVjHZyTXRDIf/SEk= =vLzc -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
OpenBSD 3.6 sparc64 stable crash
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sun, 29 May 2005 21:02:58 EDT Hi, my nightly testing started generating crashes on saturday morning on the stable branch. The platform is OpenBSD 3.6 sparc64, and the crashes are occuring in run.c. I am including basic debugging information (sanity.sh output and stack trace), hoping that the cause will be obvious to you Derek. If it's not obvious, let me know and I'll spend more time trying to track it down. Here's the output from sanity.sh: Nightly test results for Sat May 28 03:01:07 EDT 2005 OpenBSD fire.0--0.org 3.6 GENERIC#304 sparc64 /bin/sh /home/cvstest/cvs-nightly-cvs1-11-x-branch/src/sanity.sh `pwd`/cvs This test should produce no other output than this message, and a final "OK". (Note that the test can take an hour or more to run and periodically stops for as long as one minute. Do not assume there is a problem just because nothing seems to happen for a long time. If you cannot live without running status, try the command: `tail -f check.log' from another window.) FAIL: basica-6.2 *** Please see the `TESTS' and `check.log' files for more information. *** Error code 1 Stop in /tmp/cvs-nightly-cvs1-11-x-branch/src (line 634 of Makefile). PASS: basica-6 ** expected: Index: sdir/ssdir/ssfile === RCS file: /tmp/cvs-nightly-cvs1-11-x-branch/cvs-sanity-cvs1-11-x-branch/cvsroot/first-dir/sdir/ssdir/ssfile,v retrieving revision 1\.1 diff -c -r1\.1 ssfile \*\*\* sdir/ssdir/ssfile[a-zA-Z0-9 ][a-zA-Z0-9 ]* [0-9:][0-9:]* - 1\.1 - --- sdir/ssdir/ssfile [a-zA-Z0-9 ][a-zA-Z0-9 ]* [0-9:][0-9:]* - \*\*\*\*\*\*\*\*\*\*\*\*\*\*\* \*\*\* 1 \*\*\*\* - --- 1,2 ssfile + ssfile line 2 ** got: Bus error (core dumped) FAIL: basica-6.2 /bin/sh /home/cvstest/cvs-nightly-cvs1-11-x-branch/src/sanity.sh -r `pwd`/cvs This test should produce no other output than this message, and a final "OK". (Note that the test can take an hour or more to run and periodically stops for as long as one minute. Do not assume there is a problem just because nothing seems to happen for a long time. If you cannot live without running status, try the command: `tail -f check.log' from another window.) FAIL: basica-6.2 *** Please see the `TESTS' and `check.log' files for more information. *** Error code 1 Stop in /tmp/cvs-nightly-cvs1-11-x-branch/src (line 638 of Makefile). PASS: basica-6 ** expected: Index: sdir/ssdir/ssfile === RCS file: /tmp/cvs-nightly-cvs1-11-x-branch/cvs-sanity-cvs1-11-x-branch/cvsroot/first-dir/sdir/ssdir/ssfile,v retrieving revision 1\.1 diff -c -r1\.1 ssfile \*\*\* sdir/ssdir/ssfile[a-zA-Z0-9 ][a-zA-Z0-9 ]* [0-9:][0-9:]* - 1\.1 - --- sdir/ssdir/ssfile [a-zA-Z0-9 ][a-zA-Z0-9 ]* [0-9:][0-9:]* - \*\*\*\*\*\*\*\*\*\*\*\*\*\*\* \*\*\* 1 \*\*\*\* - --- 1,2 ssfile + ssfile line 2 ** got: Index: sdir/ssdir/ssfile === RCS file: /tmp/cvs-nightly-cvs1-11-x-branch/cvs-sanity-cvs1-11-x-branch/cvsroot/first-dir/sdir/ssdir/ssfile,v retrieving revision 1.1 diff -c -r1.1 ssfile Terminated with fatal signal 10 Core dumped; preserving /tmp/cvs-nightly-cvs1-11-x-branch/cvs-sanity-cvs1-11-x-branch/tmp/cvs-serv20140 on server. CVS locks may need cleaning up. FAIL: basica-6.2 Here's the stack trace from the core: Core was generated by `cvs'. Program terminated with signal 10, Bus error. #0 0x0014f148 in run_add_arg_p (iargc=0x7a8000, iarg_allocated=0x7a8004, iargv=0x7a7ff8, s=0x293838 "diff") at /home/cvstest/cvs-nightly-cvs1-11-x-branch/src/run.c:81 81 if (*iargc >= *iarg_allocated) #0 0x0014f148 in run_add_arg_p (iargc=0x7a8000, iarg_allocated=0x7a8004, iargv=0x7a7ff8, s=0x293838 "diff") at /home/cvstest/cvs-nightly-cvs1-11-x-branch/src/run.c:81 #1 0x00149e78 in call_diff_setup (prog=0x293838 "diff", argc=1, argv=0x7b8200) at /home/cvstest/cvs-nightly-cvs1-11-x-branch/src/rcscmds.c:118 #2 0x0014a944 in diff_exec ( file1=0x7b4b00 "/tmp/cvs-nightly-cvs1-11-x-branch/cvs-sanity-cvs1-11-x-branch/tmp/cvsM12313", file2=0x7ac2c0 "ssfile", label1=0x7b4a00 "-Lsdir/ssdir/ssfile\t29 May 2005 07:21:45 -\t1.1", label2=0x7b4a80 "-Lsdir/ssdir/ssfile\t29 May 2005 07:21:50 -", dargc=0, dargv=0x7b8200, out=0x0) at /home/cvstest/cvs-nightly-cvs1-11-x-branch/src/rcscmds.c:577 #3 0x0014a7dc in RCS_exec_rcsdiff (rcsfile=0x7b4880, diff_argc=1, diff_argv=0x7b8200, options=0x7ac300 "", rev1=0x7ac330 "1.1", rev1_cache=0x7ac2c0 "ssfile", rev2=0x0, label1=0x7b4a00 "-Lsdir/ssdir/ssfile\t29 May 2005 07:21:45 -\t1.1", label2=0x7b4a80 "-Lsdir/ssdir/ssfile\t29 May 2005 07:21:50 -", workfile=0x7ac2c0 "ssfile") at /home/cvstest/cvs-nightly-cvs1-11-x-branch/src/rcscmds.c:454 #4 0x0011a280 in diff_fileproc (caller
