chdir is a loser (?)
David Vinayak Wallace
gumby at Gang-of-Four.Stanford.EDU
Wed Feb 7 08:15:33 AEST 1990
Date: 31 Jan 90 04:31:35 GMT
From: gwyn at smoke.BRL.MIL (Doug Gwyn)
>My first message also included an unrelated gripe about chdir, which
>is an anachronistic loser. Does it have a legitimate use?
I should have said archaic. It's a hangover from the days when
machines didn't really have filesystems, just one disk or tape drive.
When people later developed primitive filesystems, it was easier just
to "connect" to one, and then program the old way. As others have
pointed out, even relatively new systems like cp/m exhibit this
behaviour.
I believe (but am not sure) that Multics was the first system with
pathnames; but certainly by 1966 the idea of connected directory
should have been on the way out.
Why are you posting this to UNIX-WIZARDS? A UNIX wizard knows
that chdir() establishes the process's root directory for relative
pathname interpretation.
My most abject apology. I guess I'm not a UNIX WIZARD because failed
to mistake policy for mechanism! chdir() has well-known semantics in
the current unix environment. I don't believe that it's legitimate.
One reason for taking it out of the kernel is ideological. There's
no reason for the kernel to implement a directory-searching policy;
the file-handling system calls should always take an absolute pathname
(or handle of some sort, as we've discussed in another thread). Any
searching should be implemented in user code. This keeps the kernel
size down.
More importantly however, hiding this mechanism encourages people to
write slightly inferior programs. Programmers blindly pass pathnames
to open calls rather than doing defaults merging (and, since the
merging is done in kernel space, the tools for it aren't conveniently
available to the programmer, but would have to be re-implemented).
Systems which do extensive, context-sensitive pathname defaulting like
the lisp machine (or for that matter, emacs) are more convenient to
use. With the proper libraries it's trivial to do this kind of
pathname handling. But in unix pathname merging is by default hidden
behind the chinese wall.
More information about the Comp.unix.wizards
mailing list