[311] in Zephyr Mailing List
Re: undead zwgcs
daemon@ATHENA.MIT.EDU (Steven Freed)
Mon Sep 21 10:01:02 1998
Date: Mon, 21 Sep 1998 08:02:52 -0600 (MDT)
From: Steven Freed <sfreed@gilasoft.com>
Reply-To: sfreed@gilasoft.com
To: Greg Hudson <ghudson@MIT.EDU>
Cc: Ken Raeburn <raeburn@MIT.EDU>, zephyr@MIT.EDU
In-Reply-To: <199809211256.IAA00319@nephthys.grey17.org>
On Mon, 21 Sep 1998, Greg Hudson wrote:
> > and a very short patch to make it compile on BSD/OS.
>
> Patches like this don't help me much. You can send a bug report
> (preferrably to zephyr-bugs rather than zephyr) which says, "it
> doesn't compile on BSD/OS because of this and this and this is how I
> worked around it," but I'm not going to include operating system
> #ifdefs like that in an autoconf'd source tree.
I didn't expect you to. There were small enough that it shows *exectly*
what the problem was and *exactly* how I was able to work around it. I
could have included all sorts of verbage on the problems, my thoughts
about them, how I fixed them, how I didn't expect you to fix them in the
same way, how I didn't even really expect you to fix them since they are
for one minor OS that I'm probably the only one using zephyr on so it
really doesn't matter anyway, etc. etc. The few lines of patches did that
very clearly.
> Not to mention they're just plain bizarre:
I have stated very clearly: I AM NOT A PROGRAMMER
> do you really need
> <rpc/types.h> to get INADDR_LOOPBACK on a BSD/OS machine?
Yes, it is the only include file where it is defined:
% cd /usr/include
% find . -name \*.h -exec grep INADDR_LOOPBACK {} \; -print
#ifndef INADDR_LOOPBACK
#define INADDR_LOOPBACK (u_long)0x7F000001
./rpc/types.h
> It's not even a vaguely RPC-related constant.
That's fine. Maybe in the zephyr code it should be done the way it is done
in the rpc/types.h file. If it's not defined, just define it. Having the
loopback something other than 127.0.0.1 would be just plain bizarre too.
> And setpgid(0, getpgrp()) is a no-op.
Well, what was happening here was that I was getting a too many arguements
error for getpgrp from the compiler for the line:
setpgid(0, getpgrp(getppid()));
I looked at the man page for getpgrp and it says:
This version of getpgrp() differs from past Berkeley versions by not tak-
ing a pid_t pid argument. This incompatibility is required by IEEE
Std1003.1-1988 (``POSIX'').
From the IEEE Std1003.1-1988 (``POSIX'') Rationale:
4.3BSD provides a getpgrp() function that returns the process group ID
for a specified process. Although this function is used to support job
control, all known job-control shells always specify the calling process
with this function. Thus, the simpler System V getpgrp() suffices, and
the added complexity of the 4.3BSD getpgrp() has been omitted from
POSIX.1.
So, I dropped the getppid() and it seems to work fine. If it's wrong, then
maybe a programmer can fix it.
--
Steven.
