Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.unix.programmer
Subject: Re: Why use pwd(1) for getpwd(3C)? (Re: Why use find?)
Message-ID: <28623:Oct1103:09:1990@kramden.acf.nyu.edu>
Date: 11 Oct 90 03:09:19 GMT
References: <1990Oct9.122813.1329@cbnews.att.com> <23012:Oct1019:12:2790@kramden.acf.nyu.edu> <1990Oct11.012643.11274@diku.dk>
Organization: IR
Lines: 22

In article <1990Oct11.012643.11274@diku.dk> kimcm@diku.dk (Kim Christian Madsen) writes:
> >In article <1990Oct9.122813.1329@cbnews.att.com> jbr0@cbnews.att.com (joseph.a.brownlee) writes:
> >  [ why is getpwd() implemented as `pwd` in System V? ]
> >Because there's no getwd() system call to have the kernel do the job.
> >Unless you have some sort of privileges, you won't be able to figure
> >out the current directory when any higher directory is unreadable.
> That's maybe the indirect reason, the rest is because of sloppy AT&T
> programmers, that figured that there was no reason to copy code from
> pwd(1) into the getpwd(3C) routine.

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. This is not an ``indirect'' reason.

> SYSVR4 is supposed to eliminate this
> idiotic behaviour of getpwd(3C),

POSIX has the system call (why'd they have to use a different name?), so
all modern UNIX versions have a fast getpwd().

---Dan