Bash script issue in Jamf

FritzsCorner
Contributor III

I have been working on a simple script to divide a variable by a static integer that works just fine when run on it's own, but when run via a policy in JAMF it is throwing an error.

Here is my code:

warningSeconds=7200
convertTime=$((warningSeconds/60))

echo "Time: $convertTime"

When I run this in terminal I get the expected result: Time: 120

However when I use this same snippet of code via a JAMF Policy, the variable is always seen as /1 and spits out the following error: line 28: /1: syntax error: operand expected (error token is "/1")

Is there something simple I am missing here?

2 ACCEPTED SOLUTIONS

mm2270
Legendary Contributor III

@FritzsCorner Is the $10 or $11 parameter being assigned to the warningSeconds variable?

I just created a quick script like so:

#!/bin/bash

warningSeconds="${10}"

convertTime=$((warningSeconds/60))

echo "$convertTime"

I then ran the script locally through the jamf binary with

sudo jamf runScript -script param10-testing.sh -path ~/Desktop/ -p7 7200

(The -p7 is actually the Parameter 10 assignment when run this way)

This was the result:

Running script param10-testing.sh...
Script exit code: 0
Script result: 120

Meaning it seemed to work. But, this was testing it using the jamf runScript verb. I'm not sure if there's a difference in how it would run via actual policy, but there shouldn't be.

View solution in original post

FritzsCorner
Contributor III

@mm2270 I did the same thing as you and I get the same results as you. I then set that simple script up as a policy and it worked as well. So, then I just copied and pasted my original script over the new test script and left the parameter descriptions blank, used the same test policy, and now everything is working fine. The only difference between the old policy and new policy is that the script parameters didn't have descriptions.

FYI, thanks for the help. Until today I had no idea about the runScript verb. That will come in handy for testing.

EDIT: I went back in and added the parameter descriptions and the script still works. No clue why my old script isn't working.. They are exactly the same.

View solution in original post

7 REPLIES 7

FritzsCorner
Contributor III

Okay so just to test my own sanity, I switched from division to subtraction, addition, and multiplication and they all work fine in JAMF. I only have an issue when doing division. Do I need to escape the "/" somehow?

FritzsCorner
Contributor III

After banging my head against my desk, I must have knocked some sense into myself. I finally got it working using the following.

Well it looks like it only works when it decides to. After testing the script out, it worked 2 times and now is back to interpreting the variable as /1 again.

warningSeconds=7200
convertTime=$[warningSeconds / 60]

echo "Time: $convertTime"

tlagrange
New Contributor III

Give this one a go:

warningSeconds=7200
convertTime=$(expr $warningSeconds / 60)

echo "Time: $convertTime"

FritzsCorner
Contributor III

Well I think I am running into this old issue that @mm2270 was having 6 years ago.

The policy I am using in JAMF is actually passing the 7200 into the script using the 11th parameter. After some testing, anything I put in Parameters 10 and 11 return /0 and /1 respectively. I tried formatting the variables in my script as ${10} and ${11} as suggested back in 2012, but no dice.

mm2270
Legendary Contributor III

@FritzsCorner Is the $10 or $11 parameter being assigned to the warningSeconds variable?

I just created a quick script like so:

#!/bin/bash

warningSeconds="${10}"

convertTime=$((warningSeconds/60))

echo "$convertTime"

I then ran the script locally through the jamf binary with

sudo jamf runScript -script param10-testing.sh -path ~/Desktop/ -p7 7200

(The -p7 is actually the Parameter 10 assignment when run this way)

This was the result:

Running script param10-testing.sh...
Script exit code: 0
Script result: 120

Meaning it seemed to work. But, this was testing it using the jamf runScript verb. I'm not sure if there's a difference in how it would run via actual policy, but there shouldn't be.

FritzsCorner
Contributor III

@mm2270 I did the same thing as you and I get the same results as you. I then set that simple script up as a policy and it worked as well. So, then I just copied and pasted my original script over the new test script and left the parameter descriptions blank, used the same test policy, and now everything is working fine. The only difference between the old policy and new policy is that the script parameters didn't have descriptions.

FYI, thanks for the help. Until today I had no idea about the runScript verb. That will come in handy for testing.

EDIT: I went back in and added the parameter descriptions and the script still works. No clue why my old script isn't working.. They are exactly the same.

seann
Contributor

You can always multiply by .016666666...., instead of dividing