getcwd() and friends.

[Brandon S. Allbery]

As quoted from <4438 at psuvax1.cs.psu.edu> by schwartz at shire.cs.psu.edu (Scott Schwartz):
+---------------
| In article <811 at mtxinu.UUCP>, ed at 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 at ncoast.org
uunet!hal.cwru.edu!ncoast!allbery		    ncoast!allbery at 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