Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!dkuug!freja.diku.dk!kimcm
From: kimcm@diku.dk (Kim Christian Madsen)
Newsgroups: comp.unix.programmer
Subject: Re: Why use pwd(1) for getpwd(3C)? (Re: Why use find?)
Message-ID: <1990Oct11.012643.11274@diku.dk>
Date: 11 Oct 90 01:26:43 GMT
References: <1977@sixhub.UUCP> <1990Oct7.001518.14216@diku.dk> <1990Oct9.122813.1329@cbnews.att.com> <23012:Oct1019:12:2790@kramden.acf.nyu.edu>
Organization: Department Of Computer Science, University Of Copenhagen
Lines: 21

brnstnd@kramden.acf.nyu.edu (Dan Bernstein) 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. SYSVR4 is supposed to eliminate this
idiotic behaviour of getpwd(3C), and I pray that AT&T have learned from
the negative response they have got, and do not try this path again.


As a sidenote, Doug Gwyn released a PD getpwd(3C) routine some time ago,
that behave as supposed. Check source archives for the source.

				Regards,
				Kim Chr. Madsen