Why use pwd(1) for getpwd(3C)? (Re: Why use find?)

[Guy Harris]

>> >  [ why is getpwd() implemented as `pwd` in System V? ]
>> >Because there's no getwd() system call to have the kernel do the job.

OK, so why *isn't* "getwd()" implemented as `pwd' in BSD?  After all,
there isn't a "getwd()" system call in BSD to have the kernel do the
job, either, at least as of 4.3-tahoe.  There's a "getwd()" routine, but
it ain't a "system call", it's more-or-less the algorithm "pwd" uses,
turned into a subroutine.... 

>> >Unless you have some sort of privileges, you won't be able to figure
>> >out the current directory when any higher directory is unreadable.
>
>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.

The "pwd" command isn't set-UID on any UNIX systems I've run across, so
regardless of *how* the *NON*-kernel implementation of "get the current
working directory" in those systems happens to be done, it can't figure
out the current directory when any higher directory is unreadable....

>POSIX has the system call

Bzzt!  Sorry, wrong answer, next contestant please.  POSIX has *NO*
"system calls", in the sense of "stuff that traps into a kernel that can
do stuff user-mode code can't".  POSIX has a bunch of *function calls*,
and doesn't specify *how* they're implemented.

>(why'd they have to use a different name?),

Because it's a different call from "getwd()".  It takes a "buffer size"
argument that limits the number of characters that will be stuffed
into the first argument.

I.e., they standardized the *interface* from S5, not the *interface*
from BSD.