Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!ucsd!pacbell.com!decwrl!csus.edu!ucdavis!csusac!jetfuel
From: jetfuel@csusac.csus.edu (Dave Jenks)
Newsgroups: comp.unix.programmer
Subject: Re: Why use pwd(1) for getpwd(3C)? (Re: Why use find?)
Summary: getpwd(3) at least as good as pwd(1)
Keywords: getpwd(3) pwd(1) "." ".."
Message-ID: <1990Oct11.044435.3729@csusac.csus.edu>
Date: 11 Oct 90 04:44:35 GMT
References: <1990Oct9.122813.1329@cbnews.att.com> <23012:Oct1019:12:2790@kramden.acf.nyu.edu> <1990Oct11.012643.11274@diku.dk> <28623:Oct1103:09:1990@kramden.acf.nyu.edu>
Reply-To: jetfuel@csusac.UUCP (Dave Jenks)
Organization: California State University, Sacramento
Lines: 24

In article <28623:Oct1103:09:1990@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>They weren't sloppy. There certainly was a reason not to copy code into
>getpwd(). If getpwd() doesn't invoke any system calls and doesn't invoke
>any setuid programs, then it may not be able to figure out the current
>directory. That would be ungood.

Actually, pwd(1) has no better chance of being able to figure out the
current directory than getpwd(3) could, since pwd follows the
directory from "." to "/" using each directory's ".." entry.

The obvious advantage of using getpwd(3) is that it need not create a
new process, etc. which does the same thing.  Just having it all in a
library routine (even the EXACT same code) would be faster and less
prone to possible (however unlikely) errors.

An interesting side note to all this - pwd won't work in a directory
which doesn't contain the "." and ".." entries, or part of the path
does not.  I guess you could keep someone from knowing where the
program chdir()ed to...
-- 
=======================================================================
	    "Pro is to con, as progress is to Congress..."
>>-@@-> Dave Jenks              {uunet | ucbvax!ucdavis}!csusac!jetfuel
=======================================================================