getcwd() and friends.

[Scott Schwartz]

In article <811 at mtxinu.UUCP>, ed at mtxinu (Ed Gould) writes:
>
> >>One thing that really would make things a lot easier would be a fchdir()
> >>call, that took a file descriptor and tried to chdir to it.
>
>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().

As long as we have entered the magical world of unix++, how about
this: Add a new flag to open, O_EXEC, that would permit opening a file
for execution only.  Then to do an fchdir() you would first open the
directory for execution.  Similarly, fexecve() would take a descriptor
opened for execution.  "Open for execution" would be operationally
defined as "can only be passed to fchdir(), fexecve(), or close()".

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... :-)

Frankly, I think permitting more system calls to take fd arguments
rather than pathnames would be a big win.  It certainly seems more
logical in most cases.

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!