Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!indri!eta!nic.MR.NET!hal!ncoast!allbery
From: allbery@ncoast.ORG (Brandon S. Allbery)
Newsgroups: comp.unix.wizards
Subject: Re: getcwd() and friends.
Message-ID: <13555@ncoast.ORG>
Date: 12 Apr 89 00:53:12 GMT
References: <3675@ficc.uu.net> <14689@rpp386.Dallas.TX.US> <811@mtxinu.UUCP> <4438@psuvax1.cs.psu.edu>
Reply-To: allbery@ncoast.UUCP (Brandon S. Allbery)
Followup-To: comp.unix.wizards
Organization: Cleveland Public Access UN*X, Cleveland, Oh
Lines: 43

As quoted from <4438@psuvax1.cs.psu.edu> by schwartz@shire.cs.psu.edu (Scott Schwartz):
+---------------
| In article <811@mtxinu.UUCP>, ed@mtxinu (Ed Gould) writes:
| >Worse than that, the permission required to open a directory is "r"
| >(since one may not open a directory for writing), whereas the
| >permission required to change to one is "x".  Hence, Unix protection
| >would be completely violated by the existance of fchdir().
| 
| I consider the argument that "permissions on the object might have
| changed between open() and fchdir()" to be specious.  This is already
| the case with files and (even worse) devices, so we might as well
| accept the precident.  Unless someone wants to implement fvhangup(),
| that is... :-)
+---------------

Having an open file on which permissions change doesn't affect the
permissions of other, un-opened files.  fchdir() *would* affect the effective
permissions of other files, and is thus potentially more worrisome.

+---------------
| P.S.  Given that directories are chdir-able iff they are marked 
| executable, why do sh/csh/et.al. require that you type "cd"??
| Just execute the directory by chdir-ing to it!
+---------------

The Principle of Least Surprise, I'd guess.

My path on one system includes ~/bin, which contains a shell script called
"mh" (for use in a windowing environment so I can click on the "Mail" icon
to send or read mail.  The environment isn't compatible with or as complete
as X Windows, so xmh isn't an option); it also includes /usr/lbin, which
contains a *directory* called "mh" wherein reside the MH executables.

Now:  if I type "mh" at a prompt, it will be treated as the shell script
*or* as the directory, *depending on the order of my $PATH*.  This is
non-intuitive.

++Brandon
-- 
Brandon S. Allbery, moderator of comp.sources.misc	     allbery@ncoast.org
uunet!hal.cwru.edu!ncoast!allbery		    ncoast!allbery@hal.cwru.edu
      Send comp.sources.misc submissions to comp-sources-misc@<backbone>
NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser