Posted on
08-16-2018
11:17 AM
- last edited on
03-04-2025
09:20 AM
by
kh-richa_mig
It is very strange how suddenly the xpath GET stopped printing the data correct, for this line:
id=`/usr/bin/curl -k -u $user:$pass "$jssurl/JSSResource/computers/udid/$uuid" -X GET | xpath //computer/general/id | cut -f2 -d ">" | cut -f1 -d "<"`
Getting this output with ALL the data from JSS on that specific computer:
% Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 37386 100 37386 0 0 43174 0 --:--:-- --:--:-- --:--:-- 43170 not well-formed (invalid token) at line 1, column 0, byte 0: {"computer":{"general":{"id":1992,"name": ..... .... [ALL THE DATA] .... ^ at /System/Library/Perl/Extras/5.18/darwin-thread-multi-2level/XML/Parser.pm line 187.
It displayed computer id before and now all data raw...
I wonder why it stopped working like that, any ideas?
Solved! Go to Solution.
Posted on 08-16-2018 11:33 AM
It looks like the response is in JSON, and xpath is for parsing XML. You'll want to add an Accept header to specify that you'd like to receive XML. More information on supported schemas and the Accept header are available on the Developer Portal
Posted on 08-16-2018 11:33 AM
It looks like the response is in JSON, and xpath is for parsing XML. You'll want to add an Accept header to specify that you'd like to receive XML. More information on supported schemas and the Accept header are available on the Developer Portal
Posted on 08-16-2018 11:42 AM
That's what was it, thanks Sam! I wonder why it worked before :)
Posted on 08-16-2018 11:46 AM
Jamf Pro doesn't have a default return type which means that the data type returned is determined by the underlying infrastructure (Tomcat and Java). The upgrade to one or both likely triggered the change in behavior, which is why it's recommended to add the Accept header to all scripts or tools that use the API.
Posted on 08-16-2018 11:55 AM
Makes sense, thanks!