Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!ames!haven!decuac!e2big.mko.dec.com!bacchus.pa.dec.com!decwrl!sdd.hp.com!usc!rutgers!mcnc!uvaarpa!mmdf
From: marc@athena.mit.edu
Newsgroups: comp.lang.perl
Subject: Re: pwd in perl
Message-ID: <1990Aug11.043957.856@uvaarpa.Virginia.EDU>
Date: 11 Aug 90 04:39:57 GMT
Sender: mmdf@uvaarpa.Virginia.EDU (Uvaarpa Mail System)
Reply-To: marc@mit.edu
Organization: The Internet
Lines: 35


    You can have 'x' access and no 'r' access.  On your system, /bin/pwd
    would fail in this case, and so would any call to getwd() or the Perl
    routine that's been published (or anything from user-level non-setuid
    code).  I think that's why /bin/pwd is setuid on some machines.
    (Interesting...  it's not setuid on Sunos4.1 either)

Ok, I did that, and I'm convinced.  However, our version of tcsh doesn't
like it very much (although perl doesn't need tcsh) :

<57> portnoy:/tmp# cd /tmp/foo/bar/baz
<58> portnoy:/tmp/foo/bar/baz# su marc
getwd: can't open ..
(Did you su in a fascist directory?)

I still think creating a directory like this is a bad idea, but I'll
stop flaming about it.  So, I propose as an implementation for (a
default implementation of) a builtin getwd():

1) call libc's getwd().  If you get an error,
2) fork /bin/pwd.  If you get an error from that,
3) return false and set $@

This has the advantage of only forking if necessary.

    I agree with Larry, though.  chop($pwd = `pwd`) is portable and fast,
    and there are more important features for Larry to add (I know, I've
    been writing about them for a week now :-).

That's not portable to my IBM PC, and I don't consider forking "fast."
We're still using VS2's some places around here, and what's fast on a
Sparc may not be elsewhere.  Of course, someone would write a version
which would work on a PC, and my scripts would run merrily along.

		Marc