Recipes neglect quotes passed in the arguments

[pedro.crespovalero@…]

I have troubles using the | as an argument in a recipe since bitten is neglecting the quote characters. For instance, I would like write a recipe that can execute a program in the shell as:

foo.exe --config "Deploy|x64"

Unfortunately, I do not manage to implement this instruction in the recipe. When the slave reads the recipe it seems to neglect the quotes of the arguments and it interprets that | is a pipe character.

This defect can be reprodruced following these steps:

a) Wrote the following recipe into example_recipe.xml:

<build description="Building System"
      xmlns:sh="http://bitten.cmlenz.net/tools/sh" >
 <step id="Example">
   <sh:exec file="echo" args="--config &quot;Deploy-x64&quot;"/>
   <sh:exec file="echo" args="--config &quot;Deploy|x64&quot;"/>
   <sh:exec file="echo" args="--config &quot;Deploy&#124;x64&quot;"/>
  </step>
</build>

b) Run within the same folder bitten-slave as

bitten-slave example_recipe.xml

c) In OSX, it prints

--config Deploy-x64
--config Deploy|x64
--config Deploy|x64

but *neglects* the quotes!

In Windows (two different installations) it prints errors and again, it neglects the quote characters

C:\Development\Projects\Slave\recipes>bitten-slave example_recipe.xml

[INFO    ] Slave launched at 2009-09-02 16:21:19
[INFO    ] Executing build step 'Example'
[INFO    ] --config Deploy-x64
[ERROR   ] 'x64' is not recognized as an internal or external command,
[ERROR   ] operable program or batch file.
[ERROR   ] 'x64' is not recognized as an internal or external command,
[ERROR   ] operable program or batch file.
[ERROR   ] Executing echo failed (error code 255)
[ERROR   ] Executing echo failed (error code 255)
[ERROR   ] Build step 'Example' failed
[WARNING ] Stopping build due to failure
[INFO    ] Slave exited at 2009-09-02 16:21:20 

This was discussed in this thread ​http://groups.google.com/group/bitten/browse_thread/thread/99f56b272085e28a

[osimons]

Note that this is also partly an inconsistency with running the recipe xml directly, and fetching it from the slave.

When I run the same recipe from a config on master, I get Windows to run this correctly using current trunk - no issues. OSX on the other hand needs escaping the quoting: args="--config \"Deploy|x64\"".

These inconsistencies between local vs master and Windows vs Posix needs to be resolved.

Insight most welcome... :-)

[osimons]

Replying to osimons:

Note that this is also partly an inconsistency with running the recipe xml directly, and fetching it from the slave.

"...fetching it from the master." of course :-)

[osimons]

Remove shell execution for Windows, and add docs about quoting and escaping.

[osimons]

I actually think I got it finally. It seems the difference between OSX and Windows in our testing was due to Windows executing through a shell - which I did for a reason I can no longer recall... All tests and my various configs build fine without shell on Windows, so I've dropped it in the patch.

With that out of the way, I've tried to write up a simple explanation for behaviour and rules for quoting and escaping - for adding to the documentation. Also part of the patch.

If that is all well, the cross-platform-works-for-all answer will be to escape the quotes to have them convey meaning:

args="--config \"Deploy|x64\""

Could you please test and verify?

[osimons]

I've updated the docs and example locally (after posting the patch) - latest version:

If needed, most commands use regular shell rules to split parts of the input - typically like args input for sh:exec command. Double-quotes (") can be used to mark the start and end if any sub-parts contain whitespace, alternatively '\' can be used to escape whitespace or any other character that carries meaning as part of input - including double-quotes and backslash itself:

<sh:exec file="echo" args="o\\ne &quot;4 2&quot; \&quot;hi\ there\&quot;"/>

This will pass 3 arguments: o\ne + 4 2 + "hi there".

[osimons]

Updated version, also with a simple test that just verifies that splitting is done the same on all platforms.

[osimons]

Last patch committed in [745].

[osimons]

Heh. Well, testing using 'echo' on Windows was not really the smartest thing to do as it isn't an executable but a cmd.exe built-in. And setting shell=False would of course drop support for all the built-ins - which wasn't too smart either... Especially not when I didn't notice that my Windows test slave instead called my Cygwin 'echo' command that of course performed flawlessly :-)

I've added back support for the important built-ins in [748] by modifying the command executed to call something like cmd.exe /C command + arguments - leaving shell generally disabled so that the new, uniform quoting and escaping rules should still apply for any executable called directly.