XML encoding issues

[entusdictus]

When using jamf-migrator to download scripts as trimmed sources (Download-only mode), the resulting downloaded file is not valid.
Steps to reproduce:

• create a simple script in Jamf Pro with specific content (the script does nothing and makes no sense - this is just to get the expected result)

#!/bin/zsh

LogFile="/private/tmp/test.log"

exec > >(tee -a "${LogFile}") 2>&1

exit 0

The downloaded trimmed xml source gets:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<script>
    <name>Test Script</name>
    <category>Settings</category>
    <filename>Test Script</filename>
    <info></info>
    <notes></notes>
    <priority>After</priority>
    <parameters></parameters>
    <os_requirements></os_requirements>
    <script_contents>#!/bin/zsh

LogFile="/private/tmp/test.log"

exec > >(tee -a "${LogFile}") 2>&1

exit 0
</script_contents>
</script>

But instead, this would be correct:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<script>
    <name>Test Script</name>
    <category>Settings</category>
    <filename>Test Script</filename>
    <info></info>
    <notes></notes>
    <priority>After</priority>
    <parameters></parameters>
    <os_requirements></os_requirements>
    <script_contents>#!/bin/zsh

LogFile="/private/tmp/test.log"

exec &gt; &gt;(tee -a "${LogFile}") 2&gt;&amp;1

exit 0
</script_contents>
</script>

Please note the encodings of the "greater than", "lower than" and ampersand characters. The actual script contents are not correctly encoded, which brakes the surrounding xml and subsequent uploads are going to fail.

[BIG-RAT]

Did you find the migrated script was actually incorrect on the destination server?
I have to confess I didn't dig into the code, but my recollection is that the downloaded file displays the script in a format (decoded xml) that makes it easy to simply copy the script and run it. As the xml is uploaded the script is encoded.

[entusdictus]

Sorry, I need to be a bit more precise.
The migration works when only using jamf-migrator. Seems to match your description that the XML is encoded before uploading.
We're using a mixed set of jamf-migrator to download e.g. scripts from a dedicated instance and then use a cURL command to upload the xml (this is used as a quick-setup-script for new Jamf Pro instances, but shouldn't matter here).
cURL, or at least the Jamf Pro API, won't accept the downloaded file from jamf-migrator as XML is not correctly encoded.
Does this make sense to you?

[BIG-RAT]

Makes perfect sense and I was afraid that's where you were going.
Files are intended to be used with migrator, couple of thoughts.

• the app is scriptable, use that to upload instead of cURL
• add some code to your process to encode the script before uploading

Suppose it would also be a nice option to have in the app the ability to choose what 'format' to export scripts.

[entusdictus]

Well, at least it worked in previous versions of jamf-migrator. So I'd assume you changed the code at some point to encode/decode the XML before down- and uploads. If that is the case, an option to select the downloaded format would indeed help a lot. Of course, if this is not too much effort in implementing this.

For the other two options:

• the app is scriptable, use that to upload instead of cURL => I'll definitely have a look at this
• add some code to your process to encode the script before uploading => are you aware of any built-in tools or 3rd party libraries that I can use to encode my stuff?

[BIG-RAT]

Afraid I do not have any existing resources to do the encoding. Thinking some regex/stylesheets (xslt) would be involved.