This is the mail archive of the
cygwin-patches@cygwin.com
mailing list for the Cygwin project.
Re: Reorganizing internal_getlogin()
On Wed, Jun 12, 2002 at 11:08:33PM -0400, Pierre A. Humblet wrote:
>At 10:12 PM 6/12/2002 -0400, you wrote:
>>Yes, and as I explained previously, I didn't really like what you did to
>>spawn_guts or your additions to environ.cc.
>
>You never really explained why, except the style of the names!
Ok. Let me say it now, then -- IMO it was overly invasive. You
invented new ways of doing things rather than extending the old ways,
which is what I did.
I'm not going to comment on the rest of your reexplanation of why
setting the environment is bad. I'm assuming that you haven't looked at
the new code. I agree that setting the environment only when necessary
is a good thing. My implementation goes a step further and tries to set
it only when it is actually needed for non-cygwin programs, assuming
that only non-cygwin Windows programs will be interested in most of the
environment variables.
>The other important change I did was not to call internal_login at all
>from seteuid, and to avoid calling LookupAccountSid() [another
>logonserver lookup, really] . Calling internal_getlogin is useless
>(except for setting the environment) and it has the additional cost of
>traversing passwd.
Yes, sounds like a good thing to do.
>>If you don't set the child's uid here then where is it going to be set?
>
>It's already set! (as is myself->gid and the rest).
Actually, I thought it was required in the spawn (P_NOWAIT) scenario,
but a code review reveals that I was wrong. So, sorry, nevermind.
>BTW spawn_info->moreinfo->uid has a misleading name (probably for
>historical reasons).
Maybe so.
>>The correct way to find out if the parent is a cygwin process is to
>>check for ppid_handle. If it is zero, then the parent was not a cygwin
>>process. I've already made this change to uinfo.cc.
>
>I just checked (printed myself->procinfo in gdb), same problem as ppid.
>If Windows starts a Cygwin process and this process exec()s.' then the
>exec'ed process has ppid_handle==0 even though the parent is a cygwin
>process.
Ah. Ok. Should have read your explanation more closely. I was using a
different definition of "parent_process". You want to check
child_proc_info, then. If it is non-NULL, the process has been
forked/execed.
cgf