It's been years since I've used Plan 9, and I very-much miss bind and union mount. For me, the big benefit of them is that you can hard-code well-known names for certain files or directories, and yet you can override those paths as needed, without having to set a bunch of environment variables and worry about whether the program you're dealing with checks the environment variables.
Real-world example: I maintain a commercial program that uses embedded Python and is run on customer servers over-which I have little or no control. I don't want my program to use the system Python libraries, if there are any. But in order to work in many different situations, including for testing while uninstalled, Python does a whole bunch of hunting around the system to find its libraries. This hunt is affected by the PYTHONHOME and PYTHONPATH environment variables, as well as code in site.py, and C initialization code with some hard-coded paths. To work around this, I set a flag that advises Python to ignore the environment, I overwrite the hard-coded paths (in spite of warnings in the Python docs) before initializing Python, and I supply my own replacement site.py. I think this isolates my program from the system Python, but it's complicated and there's probably some corner case I've missed. If the OS had bind and union mounts, then Python could always look for its libraries in /lib/python. Need a different library? bind ./lib /lib/python. There would be no need for PYTHONHOME or PYTHONPATH or sys.path or the searches in site.py and the C initialization code. I would simply bind my own library into the well-known location, and I would never have to worry about some bug in Python accidentally loading the system library. Off the top of my head, bind and union mount can eliminate the need for all of these common environment variables: PATH, MANPATH, LD_LIBRARY_PATH, PKGCONFIG, PYTHONPATH (as well as GOPATH, etc), TMPDIR, PAGER, EDITOR, and surely others. Namespace manipulation is not just an alternative to environment variables in cases like these; it's better because it eliminates code. Every program that wants to support one of these environment variables must contain code to do so. With namespace manipulation, they don't need any code, they just open() or exec() a well-known path. Namespace manipulation works to reconfigure any path name for any program, without the program's author having to provide a configuration hook of any kind. Micah
