Closed BigMacAdmin closed 1 year ago
I think this issue is related to what I also found when testing, I had to run a "scan" (non install) cycle (to populate the fragments folder), then run an "install" run. Otherwise the "--ignore" tags don't seem to work correctly.
It's an order of operations problem I didn't anticipate. Initially, I wasn't really planning on patchomator running unattended.
The way the labels are used is each one is run as a sub-script to check the current version, etc. Parsing through Installomator.sh each time would probably slow things down (though I'd have to try it to be sure).
I'll move the self-update/install steps higher in the script to make sure those fragments are there and up to date before patchomator tries to read them.
Currently, patchomator assumes that
/usr/local/Installomator/fragments
exists and is populated with data from the Installomator github repo.The problem is that if
--write
hasn't been run interactively on the workstation, that folder never gets generated.When using
--required
, this problem results in Errors being reported despite no actual Installomator errors occurring.Please add a function to check for this folder, and if it doesn't exist then populate it.
Alternately: Perhaps the
fragments
folder never needs to live locally on the device at all? All of the information from that folder is contained within theInstallomator.sh
script.Here is an example of how to scrape the
name=
label variable from the labelgooglechromepkg
. Perhaps the dependency on thefragments
folder can be discarded if this method is used to grab the necessary data.sed -n '/# label descriptions/,$p' /usr/local/Installomator/Installomator.sh | grep -i -A 50 "googlechromepkg" | grep -m 1 "name=" | sed 's/.*=//' | sed 's/"//g'
This same trick can be used to get any label value from any
${label}