Subject: SGI & NIS

From: e <[email-masked]>
Date: Thu, 27 May 1993 09:02:10 -0400 (EDT)

I am having problems getting pine to use NIS entries on an SGI platform.
Any local user ids that can't be found end of with a TO: entry of

To:  e <[email-masked]>

I noticed that the make does include the sun lib which is suppose to then
use the NIS calles for getpw... but it does not look like it is working.
The NIS password file is in a separate file from /etc/passwd.

Anyone else have similar problems or suggestions.
Thanks
Jamie

------------------------------------------------------
Jamie Wyatt
Network and Systems Administrator
Dept. of Computer Science, Brock University
St. Catharines, Ontario, Canada, L2S 3A1
[email-masked]

---

From: Eran Lachs <[email-masked]>
Date: Thu, 27 May 1993 16:36:31 +0300 (IDT)

Hello All,

  I've been meaning to write about Pine under SGI for quite some time now.
Our imap server runs on a DecStation. Transparent access via the rimap
mechanism works fine from Sun machines and IBM RS6K machines. 
Pine under SGI, although compiled with -lsun for NIS support, always asks
for a username/password combination. 

> Any local user ids that can't be found end of with a TO: entry of

I've tested Composer on Sun, IBM and SGI - all produce a To: line like:
To      : [email-masked]

Only the imap server machine, while running Pine, produces:
To      : Eran Lachs <[email-masked]>

Any pointers to the above two points much appreciated.
BTW - all mentined Pines are 3.05 (IBM's are 3.0.5a).

Eran Lachs   ([email-masked])
Ben Gurion University Computation Center
Beer Sheva, Israel

---

From: Mike Brudenell <[email-masked]>
Date: Fri, 28 May 93 08:02:00 +0000

>   I am having problems getting pine to use NIS entries on
>   an SGI platform. Any local user ids that can't be found
>   end of with a TO: entry of
>   
>   I noticed that the make does include the sun lib which
>   is suppose to then use the NIS calles for getpw... but
>   it does not look like it is working. The NIS password
>   file is in a separate file from /etc/passwd.
>   

Yes!  I had exactly this problem too!

I traced the problem to some apprarent incompatibility between the compatibility
routines declared in the c-client/os_sgi.c & .h files and the ones provided by
the real operating system.

For some strange reason the c-client for SGI comes shipped with its own
functions for these functions: strtok; strchr; strrchr; strstr; strpbrk;
strerror; memcpy; memmove; memset; strtol.  These are all available as standard
IRIX provided routines (an din fact keeping the extra c-client routines in leads
to some warning mesages later from ld about multiply defined routines).

I "cured" the problem simply by removing *all* the above routines from the
c-clinet/os_sgi.[ch] files, did a "make clean" to remove *all* the .o and .a
files, and doing a total rebuild.

This problem was in Pine 3.05 too (where I originally encountered and traced
it); when Pine 3.07 came along I just reapplied my context diffs to elimiate the
bogus routines again.

                                                        Mike B-)

---

From: Mark Crispin <[email-masked]>
Date: Fri, 28 May 1993 00:49:37 -0700 (PDT)

Mike -

     Thank you for informing me about the problem with the SGI port.  I have
fixed it in the c-client sources, and eventually the change will percolate
into the Pine distribution.  I have no access to any SGI systems, so I am
completely dependent upon those who do for information.  The SGI port was
supplied by a user, modified from one of the other ports (probably the BSD
port).

     I would like to plead with everyone that if you discover this sort of
incompatibility, don't just fix it at your site and let the matter be.  Tell
us about it!  We are interested, and will do our utmost to get fixes in later
releases.  Most of the Pine development at UW is done under Ultrix or NeXT,
since those are the machines used by the Pine team.  We have access to a few
other machines (most notably, we support Pine/imapd on the computer center's
PTX machine), but otherwise we are dependent upon you for ports for other
platforms as well as keeping these ports from succumbing to software rot.

-- Mark --