|
|
|
|
Let's first consider a simple example of XML input to the exp_plesk_ev operator:
<packet version="0.1.1.0">
<del>
<filter>
<id>3</id>
</filter>
</del>
</packet>
Here's how it must look like in the CLI variant:
$ exp_plesk_domain del filter id=3
As it can be seen a default behavior for the CLI input parser is to get the next argument and put it inside the previous one (the 'packet' node is not needed here, it will be inserted automatically). If an argument contains the '=' sign a node gets assigned a text data value, which comes directly after the '=' sign.
Here is one more example of XML input for exp_expand_config operator:
<packet version="0.1.1.0">
<person>
<add>
<login>nobody</login>
<email>nobody@test.com</email>
<name>Nobody person</name>
<password>setup</password>
<roles>
<role_id>1</role_id>
</roles>
</add>
</person>
</packet>
That is how it looks like in CLI input:
$ exp_expand_config person add login=nobody email=nobody@localhost \
name='Nobody person' password=setup roles role_id=1
As you can see, if a node gets its text data, it's considered a terminal one (i.e. having no children). Thus we can just enlist the sibling terminal nodes. In case we want to put 'roles' node as the first child of the 'add' node, the CLI input will look like this:
$ exp_expand_config person add roles [ role_id=1 ] \
email=nobody@localhost name='Nobody person' \
password=some-pass
Note the square brackets. They enclose all the children for a preceding node (in our example, the node 'role_id'). And the XML packet in this case will look as follows:
<packet version="0.1.1.0">
<person>
<add>
<roles>
<role_id>1</role_id>
</roles>
<email>nobody@test.com</email>
<name>Nobody person</name>
<password>setup</password>
</add>
</person>
</packet>
After a square bracket gets closed, the siblings for that node follow. You may say that this package is rather simple and there is no difference whether to use square brackets or not. But when you read this section further and consider more complicated examples, you will see how useful the square brackets are.
Note: Each bracket must be separated with at least one space from the arguments on both sides. This restriction stems from the method the shell uses to build the command line arguments list for a program. It just drops quotes.
Thus one can't tell these two structures one from another:
$ exp_expand_config person add name='Some weird [person]'
$ exp_expand_config person add name='Some weird '[person]
Both of them look identical from the shell's point of view. By the way, that's why an error is generated for such "obvious" shell commands:
$ [-n "foo" ] && echo OK
Note: Please remember: no spaces before or after the equation sign ('=').