File error (note: jsc max size is 2147483647 bytes): Error: Could not open file.

[FranckSartori]

Hi. I have attached 2 JSON files produced from Jamf Pro API (curl then redirection to file so you can get the content). The request is made using EA_ID=$(echo "$JSON_DATA" | jpt -T '$..*[?(@.name=="EasyLAPS")].definitionId') With the content of file C39BB5D2-342A-597E-BF83-2D60E923C362.json, the ID is returned With the content of file A7D7D99B-1CF6-58FB-A47A-BDC555E24E6F.json, the error is File error (note: jsc max size is 2147483647 bytes): Error: Could not open file. In the 2 files, we have the same entry for the EasyLAPS attribute. Using https://jsonformatter.curiousconcept.com, the 2 files are reported valid. Do you see why jpt returns the error ? Franck Archive.zip

[brunerd]

I say use set -x in your script to debug and make sure $JSON_DATA really contains the data you think it does... as you can see below I fed both of those files into a variable and I get answers for both. So something is off in your script.

The error File error (note: jsc max size is 2147483647 bytes): Error: Could not open file. is printed whenever readFile() has any file error. The shell script part of jpt does existence, readability and even size checking. Sorry if the error implies filesize is the reason, I should probably take that out.

But again place set -x at the top of your script so you can see what is truly going on in your script

[FranckSartori]

Amazing. I don't read the files I gave here but I parse directly the curl answers from Jamf Pro (and the files provided are just redirections of these curl answers). Let's try again.

[FranckSartori]

I have this script : JSON_DATA=$(< ./C39BB5D2-342A-597E-BF83-2D60E923C362.json) echo "File 1" echo "$JSON_DATA" | jpt -T '$..*[?(@.name=="EasyLAPS")].definitionId'

JSON_DATA=$(< ./A7D7D99B-1CF6-58FB-A47A-BDC555E24E6F.json) echo "File 2" echo "$JSON_DATA" | jpt -T '$..*[?(@.name=="EasyLAPS")].definitionId'

Using set -xv.

For the first file returning the ID :

echo "File 1"

• echo 'File 1' File 1 echo "$JSON_DATA" | jpt -T '$..*[?(@.name=="EasyLAPS")].definitionId'
• jpt -T '$..*[?(@.name=="EasyLAPS")].definitionId'
• echo '{ "applications" : [ { "bundleId" : "com.jamfsoftware.selfservice.mac", "externalVersionId" : "0", "macAppStore" : false, "name" : "Self Service.app",

For the second file returning the error :

echo "File 2"

• echo 'File 2' File 2 echo "$JSON_DATA" | jpt -T '$..*[?(@.name=="EasyLAPS")].definitionId'
• echo '{ "applications" : [], "attachments" : [], "certificates" : [], "configurationProfiles" : [], "contentCaching" : null, "diskEncryption" : { "bootPartitionEncryptionDetails" : null, "diskEncryptionConfigurationName" : null, "fileVault2EligibilityMessage" : null, "fileVault2EnabledUserNames" : [],
• jpt -T '$..*[?(@.name=="EasyLAPS")].definitionId' "individualRecoveryKeyValidityStatus" : "UNKNOWN", "institutionalRecoveryKeyPresent" : false }, "extensionAttributes" : [ {

At each execution, the jpt line is more or less high in the log. And I have the same issue when reading the curl answers and not the files. I will ask around to see what is happening because I don't see.

[FranckSartori]

I found. In my context, it works with sh and zsh but not bash. I need now to go forward and parse directly curl answers.

[brunerd]

Good luck... zsh is a fine shell, I just don't appreciate the 1 based arrays and weird word splitting behavior (set -y for bash-like behavior) but jpt does work with bash

[FranckSartori]

As I said, not in my context and I don't know why. Too bad !

[brunerd]

Just to note here for future reference - because it's so esoteric!

@FranckSartori As the faulty script works in another session, I compared the content of the root of the home folders. I deleted some extra files and folders without success and at the end, I changed the content of the .CFUserTextEncoding to match the other session : 0x0:0x0 and not 0x0:0x1 And you know what ? It works from Terminal and CodeRunner.

More info here Mac: What's ~/.CFUserTextEncoding for? and Apple's Technical Note 2228

Core Foundation tries to access the user's home directory to determine their default text encoding (stored in the file ~/.CFUserTextEncoding). If you switch the EUID to the UID of the logging in user and then call CF, you may have problems when Core Foundation accesses this file. You can prevent this access by setting an environment variable that tells Core Foundation the default text encoding to use. The environment variable name is __CF_USER_TEXT_ENCODING. Its value should be constructed with the format string "0x%X:0:0", where %X is replaced by the UID of the logging in user.

Which does not seems to be true for the file which usually appears to be:

% cat .CFUserTextEncoding
0x0:0x0%