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
PATH="$PATH;/mydir"
Instead you'll need to do sequence operations like
PATH+=/mydir
or
PATH=($PATH /mydir)
or
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.
I'm relying on the presumption that PATH will have been set prior to invoking xmlsh in most (all?) existing scripts.
I'm not sure I understand how the string assignment way would be a "hack" - it may be a useful way to allow for presetting sequence variables from the environment. Seems like a fairly decent way in general to convert them to/from a flat string?
ReplyDeleteThere are a lot of other ways to convert from a flat string to a sequence. for example the xpath function fn:tokenize().
ReplyDeletevar=<[ tokenize("a;b;c",";") ]>
The "Hack" is treating PATH and XPATH magically and differently from other variables not only on startup and calling subprocesses, but also in "normal" operations of assignment within the shell. I just dont like that kind of arbitrary special treatment.
FYI I've implemented the above proposal and it appears to work fine. It will most likely be coming out with the next release, ETA this week.
ReplyDeleteSo how does that expression work from outside the shell?
ReplyDeleteN.B. I haven't even had xmlsh on my machine since I replaced my hard drive a month+ ago, please pardon my ignorant yet curious post.
I see the flaw in my logic - that xmlsh wouldn't know whether I want my environment variable LIST_O_COOL_THINGS to be a string with colons in it or to be automagically converted to a sequence. (Can of worms: context sensitive string/array conversion, e.g. ksh's $IFS in for loops?)
bash$ export XPATH='<[ tokenize("a;b;c", ";") ]>' xmlsh myscript.xsh
?
Your can of works is what I dont want to open (but already have for magic PATH and XPATH).
ReplyDeleteTrying to pass in arbitrary XDM values from "outside" and magically have xmlsh decide what to do with them is futile, IMHO.
Thats for something to do *inside* xmlsh.
What if you wanted to pass in a comma seperated sequence or even an XML file ?
It ends nowhere.
The suggested design pattern is to not do these things "outside" but rather "inside". Setup only as minimal environment "outside" then inside xmlsh you can do anything you want without having to invoke ESP mode.