I think it would be useful/convenient if the current directory determined one's shell environment. This would mean that the command
..., for example, would not only set the current working directory (and update
$dirstack, etc.), but would also adjust a host of other environment elements (shell options, variables, functions, aliases, etc.) in a manner appropriate to the contents of the new
At first blush this seems like a relatively simple thing to implement, especially with
zsh, since it already supports a
chpwd hook, and the
$chpwd_functions array. But, as they say, the devil is in the details1.
Therefore, before plunging into rolling my own, I thought I'd ask: is anyone aware of a mature implementation of this idea?
chpwd et al., does
zsh provide other tools that would be helpful towards implementing such a thing? In particular, does it provide any support for encapsulating/saving/restoring environments? (I'm thinking of something in the vein of
R's environment objects, but encompassing not only variables, but also, e.g., aliases, options, etc.)
FWIW, I am aware of Python's
virtualenv, which shares some features with the idea described in this post, but of course, this is limited to Python-related settings, however. Furthermore, it creates a new "state variable", if you will, the "current virtual environment", orthogonal (rather subsumed under) the "current working directory" state variable.
1 Once one looks into the matter more carefully one quickly meets some non-trivial questions. For example: if
/my/projects/foo activates a custom environment, what exactly happens after
cd /my/projects/foo/modules/bar? Can we have nested custom environments, demarcated by the filesystem's tree structure? What about symlinks? E.g., what if
/my/projects/foo/modules/bar is actually a symlink to
/my/shared/modules/bar? Or, if I execute
/tmp, say, what should be the environment of the resulting process? Etc., etc., etc. I don't find these questions necessarily intractable, but I do find them at least not-totally-trivial.