Push script along with XML

How big is the XML? Small files that are needed by a script I usually create 'on the spot' using the here document syntax (http://tldp.org/LDP/abs/html/here-docs.html). Bigger files I put on a web-server and have the script fetch it using curl.

Always more than one way to skin a cat,

the way i would approach this is the following.

A. Create a package containing the .XML in a hidden directory with permissions appropriate for utilization by your shell script & deploy it to computers via JAMF.

B. House Shell script in JAMF & run from JAMF & path to hidden .XML where required in script.

C. Create a script the deletes the newly placed .XML

NOW

Create 1 policy that does the following in sequence.

1. Deploy .XML Package.
2. Run shell script that utilizes .XML.
3. Run shell script to remove .XML.

@Hugonaut So you are saying use jamf composer new and modified snapshot after it runs the first part in a location like /Users/Shared create a folder and add my xml in the folder. Finish the snapshot and build it as a pkg. Upload the pkg to Jamf Pro. Create the script in jamf pro but at the top have it "cd /users/shared/foldername" and then create a policy with the pkg and script in the policy and that should work?

@Hugonaut I did not see a reply to @bmichael . I am hoping that is what you meant as well. I need to copy an .xml file to all computers to a specific folder "/Library" and I do not know how to do it. I am thinking your suggestion would work but first I need to teach myself how to use the composer.

I have done 2/3 steps needed for a software to work. The last step needed is for a configuration.xml to be in the library folder on the local computer before the package is runs. Manually I have placed the file in the folder locally and ran the policy with success. I need to find a way for JAMF to place the files on all of our macs in the Library folder.

Unless it's a very large xml file, I would probably go with the method @mschroder pointed out (heredoc), which can create the xml file on the fly from within the script itself, set any appropriate permissions on the file and then proceed to use it. But it depends on a few factors. If the script you have is from a software developer and not something you yourself created, then it may be best to leave that script as is and just package up the xml file in Composer to drop it into a particular location before running the main script.
The location where you drop the xml file may be dependent on whether the main script expects to see the xml file in it's own running directory or not. Some scripts work like that. If so, your best bet may be to package up both the main script and the xml file in the same folder, and deploy that folder in a Composer package to the client system. Then when the script gets executed it should see the xml file in its working directory.

As for the questions from @bmichael and @amclaughlin, you do not need to use the snapshot method for this. In fact, I would say don't do that at all. Many people don't realize it, but Composer has the ability to create sources by directly pulling in files and/or folders into the left sidebar. It will create a new Source in the app and copy those items directly in, without the need for a lengthy and often inaccurate New or New and Modified Snapshot process.
@amclaughlin, using your example, I would place the xml file in the location in /Library/ where you need it to be, open Composer, cancel out of any windows that come up if any, then drag the file directly from /Library/ into the Composer sidebar (where it says SOURCES at the top) and it will create a new source instantly, with that xml file and any folders in the path to it.

For deploying any single files that are text and not binary and also seems like something that I would need to change the contents of at some point I've been deploying via this heredoc method. I had no idea until now that it was called this. I found someone on here one day post a script doing this and it was like a light bulb going off when I realized what it did. It's been awesome since I don't need to create packages for those files and any changes to them are just done in the script on Jamf and then redeployed. I wish I could recall where I originally saw this and thank them. It's one of those tips that makes hanging out on Jamfnation worthwhile.