> I assume you mean /bin/pwd since many shells do have pwd built in

Yes.  Many commercial package installation scripts use /bin/pwd
because they're written in sh, and they get the "wrong answer".

> If you mean something like having a coda-volume for each architecture,

I mean a sequence of hundreds of commands like these, executed by the
client at boot time:

# do-mnt @my-servers:/exp/depot/emacs-19.10/bin-_at_sys /depot/emacs-19.10/bin
# do-mnt @my-servers:/exp/depot/emacs-19.10/lib-_at_sys /depot/emacs-19.10/lib
# do-mnt @my-servers:/exp/depot/emacs-19.10/etc      /depot/emacs-19.10/etc
# do-mnt @my-servers:/exp/depot/emacs-19.10/man      /depot/emacs-19.10/man
# do-mnt @my-servers:/exp/depot/emacs-19.10/lisp     /depot/emacs-19.10/lisp

# do-mnt @my-servers:/exp/depot/X11R6-1.0/bin-_at_sys   /depot/X11R6-1.0/bin
# do-mnt @my-servers:/exp/depot/X11R6-1.0/lib-_at_sys   /depot/X11R6-1.0/lib
# do-mnt @my-servers:/exp/depot/X11R6-1.0/etc        /depot/X11R6-1.0/etc
# do-mnt @my-servers:/exp/depot/X11R6-1.0/man        /depot/X11R6-1.0/man
# do-mnt @my-servers:/exp/depot/X11R6-1.0/lisp       /depot/X11R6-1.0/lisp

@my-servers is a cookie that specifies a set of machines that are
serving a filesystem.  A given client will speak to several sets.  You
probably want X to survive campus network partitions, so you will have
many geographically distributed hosts in that set.  You may only have
two hosts in the set that serves the dictionary datafiles or the
shared tmp space, because you don't want to spend the disk space on a
lot of copies.  There may be many sets for home dirs such they are
local on a bunch of users' machines.  If you allow for hundreds of
mounts from tens of sets of servers, the admin can build whatever mess
he needs.

The mounts need to be changable on machines without disrupting
processes not using that namespace.  For instance /home/foo/bb fills
up, so I tell bb to log out, copy /home/foo/bb to /home/bar/bb, change
the password file, and he logs back on to more space.

For amd we used the yp map distribution method.  However, yp sucks.
For Coda the map notification mechanism should happen automatically,
i.e. guaranteed delivery to the hosts using a volume, not a script I
run on all hosts I think may have have mounted something on.
Preferably the map notification mechanism will not require
individually disabling the old mounts first, i.e. whenever a
filesystem call happens it uses the most recent definition for that
namespace, and does a new mount behind the scenes if necessary.

> But, Coda would need reliable support for mounting the same volume
> at multiple locations.

And/or mounting arbitrary subtrees of a volume at multiple locations.

> We have however found a need to extend this mechanism.  For example
> it could be very handy to have a name: @user which would expand to
> $HOME, or a programmable one @MACHINE which would refer to a
> directory called "desktop" on desktop workstations and to a
> directory called "notebook" on laptops.

Yes.  Or some sort of mechanism that would assemble values from files
that could change without recompiling Venus.


Another member of the League for Programming Freedom (LPF) www.lpf.org
-------------------------------------------------------------------------------
Brian Bartholomew - bb_at_wv.com - www.wv.com - Working Version, Cambridge, MA