🚀 go-pugleaf

In article <1990Oct11.012643.11274@diku.dk>, kimcm@diku.dk (Kim Christian Madsen) writes:
> 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? ]
> 
...
> 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.

	at&t, as are other large vendors, is responsible for some terrible
code but this is really a poor choice to attack them on. as has been
pointed out, a safe getpwd() routine has to fork so that chdir failures
do not ruin the calling program's working dir. and if you are going
to fork anyway, popen("pwd") sounds like unobjectionable overhead
UNLESS you call getpwd() a whole lot.
	now, if your objection is why didn't at&t recode pwd
into just calling a subroutine (that does its own fork and pipes etc),
and i agree that in the long run this might have been better,
then the answer is probably the regular one (its not broken, there are
no MRs on it, don't bother it).

	i still don't understand why people get so uptight about how
getpwd() is implemented. it took years to get anyone to pay any attention
to implementing stdio efficiently and that hurts billions more
programs ALL the time mor ethan getpwd() ever will.

	get a sense of proportion.

andrew hume