Thanks to a suggestion from a new user, I realized I had not documented how the XPATH environment variable is implemented. I've corrected that now by documenting it, but it exposed some problems. That is, XPATH cannot be set to more then 1 directory in the environment prior to calling xmlsh. XPATH is a XDM Sequence variable (like an "array"). Instead of how PATH is a : or ; separated string. I think this makes much more sense but it leads to compatibility issues.
The worse is that you cant preset XPATH before calling xmlsh ! I never thought this through completely but thanks to user feedback I am now.
Also PATH and XPATH are treated differently, which is, well, inconsistent to say the least.
What I've decided to do is this.
On startup, xmlsh will read both PATH and XPATH and parse them into an XDM sequence according to the OS path separator (";" or ":") and then from then on they will remain sequence variables in xmlsh. You can operate on them like any other sequence. Directory separators will be converted to "/" (as is already done).
On calling subprocesses, both variables will be re-serialized as a single string using the same (but reverse) algorithm. The result is subprocesses will see the same single-string, path separated and native OS directory separator strings as were passed into xmlsh.
This way PATH and XPATH can be treated the same, and both can be initialized prior to invoking xmlsh using normal OS environment settings.
The one problem is that this may break existing code in xmlsh which attempts to change the PATH variable using
Instead you'll need to do sequence operations like
PATH=<[ $PATH , "mydir" ]>
Since PATH will become a sequence variable this syntax wont produce the desired result.
Its possible I could try to hack this by parsing all string assignments to PATH , but I'm not excited about introducing that hack.
Suggestions anyone ? Do will this break any of your existing code ?
I'm relying on the presumption that PATH will have been set prior to invoking xmlsh in most (all?) existing scripts.