An ``<environment_variables>`` top-level XML block can be used to define these.
```
<environment_variables>
<environment_variable name="FOO">$bar</environment_variable>
<environment_variable name="FOO2">$bar2</environment_variable
</environment_variables>
```
The expressions are contained in the text of the block.
Implementation Detials:
In order to avoid odd shell expression stuff - the evaluated expressions are written to files and environment variables are read from these files at runtime.
Testing:
A demo tool ``test/functional/tools/environment_variables.xml`` with a test case that can be executed with the following expression.
```
./run_tests.sh -framework -id environment_variables
```
Previously there were two hard-coded toke types at_tokens an dollar_tokens. Now all tokens for the same macro must have the same wrap string and this string can be set arbitrarily with token_quote attribute. The defualt token_quote value is @.
This comes in two modes - simple lists of required attributes and per-attribute parameters that may specify defaults.
The following toy example:
```
<tool>
<expand macro="inputs" bar="hello" />
<macros>
<xml name="inputs" dollar_tokens="bar">
<inputs type="the type is $BAR$" />
</xml>
</macros>
</tool>
```
will evalute to ``<tool><inputs type="the type is hello" /><tool>``. The XML macro definition tag can now take in two new fixed attributes dollar_tokens and at_tokens - which will be interpreted as a list of parameter names. Each parameter can be specified when expanding the macros as simple attributes specifying the value of the parameter. The "dollar" parameter with name bar would map to a token with name $BAR$. Likewise an "at" parameter with name foo would map to a token with name @FOO@.
Both parameter types can be specified on a per-parameter basis to also specify default values. So the following example:
```
<tool>
<expand macro="inputs" foo="hello" />
<expand macro="inputs" foo="world" />
<expand macro="inputs" />
<macros>
<xml name="inputs" at_token_foo="the_default">
<inputs>@FOO@</inputs>
</xml>
</macros>
</tool>
```
Would evalute to ``<tool><inputs>hello</inputs><inputs>world</inputs><inputs>the_default</inputs>``.
Updated unit tests explain the above much more succinctly - though some like English and words for reasons that escape me.
If present, it can be one of
- "default", no-op fallback to stdio tags and erroring on standard error output.
- "exit_code", error if tool exit code is not 0. (The @jmchilton recommendation).
- "aggressive", error if tool exit code is not 0 or either Exception: or Error: appears in standard error/output. (The @bgruening recommendation).
Refactoring and unit/functional tests to support and demonstrate this.
Run functional test with:
./run_tests.sh -framework -id detect_errors_aggressive
Run relevant unit tests:
nosetests test/unit/tools/test_parsing.py
Updated from original version to reflect comments on pull request #117 - in particular the ``detect_errors`` tag was moved from ``tool`` to ``command``.
Nicola Soranzo