Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!virtech!cpcahil
From: cpcahil@virtech.uucp (Conor P. Cahill)
Newsgroups: comp.unix.programmer
Subject: Re: Why use pwd(1) for getpwd(3C)? (Re: Why use find?)
Message-ID: <1990Oct10.231857.11668@virtech.uucp>
Date: 10 Oct 90 23:18:57 GMT
References: <28790001@col.hp.com> <1977@sixhub.UUCP> <1990Oct7.001518.14216@diku.dk> <1990Oct9.122813.1329@cbnews.att.com>
Reply-To: cpcahil@virtech.UUCP (Conor P. Cahill)
Organization: Virtual Technologies Inc., Sterling VA
Lines: 28

In article <1990Oct9.122813.1329@cbnews.att.com> jbr0@cbnews.att.com (joseph.a.brownlee) writes:
>
>While this is somewhat off the subject, I have to admit that I have always
>wondered why getpwd(3C) is implemented this way.  It seems exactly backward
>from one what normally expects (and sees) in UNIX, where UNIX programs are
>based on underlying system or subroutine calls.  Of course, this reversal
>causes the poor performance mentioned above.

I don't know the reason for making it a call to popen(),  one reason may
have been security (pwd could be a setuid pgm and do things that a 
function call couldn't).

Anyway, the reason that this has never been changes is probably that
it is not the performance looser that you seem to think.  No program
should make more than one call to getpwd(), since it will then know
where it is and has to know where it goes from there. 

For the relatively few programs that really need to know the full 
path of the current directory, making it a popen is probably not that 
bad of a decision.

Note that I am not saying that it was a good decision, just that it
might not be that bad of a decision.

-- 
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.,
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170