Testing a script?

[#1]

If I wanted to test a script locally on my mac before deploying it out - how would i go about doing it?
Do I open my terminal and drag the".sh" file in there?

[claudiogardini · Accepted solution]

Coderunner can also be useful to write and Debug Scripts. https://coderunnerapp.com

[seann]

chmod +x yourscript.sh
./yourscript.sh

[mm2270]

That's one way, though I would drop sudo in front of it since you likely want it running as root.
But if you want to simulate the script being run by a Jamf Pro policy, another way to do it would be to run it thru the jamf agent, like so

sudo /usr/local/bin/jamf runScript -script "MyScriptName.sh" -path "/path/to/script/"

With this method, you can also pass parameters to the script in case you happen to use that in it. This is done with flags like -p1 <value> for $4 and -p2 for $5, etc etc. See the help page for more on that.

Keep in mind that in some cases, scripts might run perfectly when run in Terminal (using either of the above methods), but fail when run by the Jamf Recurring Check-in trigger, simply because the recurring check-in trigger gets called by a LaunchDaemon, so it's running completely as root, whereas dropping it into Terminal it's really running as your account, even when you put sudo in front of it. There is a difference, and in some cases, it can make all the difference between working and failing. For this reason, I recommend testing it in a policy called by whatever actual triggers will run it, after you've tested it locally.

[#5]

what i ended up doing - was:

open terminal
typed "su administrator"
put in admin password
typed "sudo sh 'script' "
put in admin password

[claudiogardini · Accepted solution]

Coderunner can also be useful to write and Debug Scripts. https://coderunnerapp.com

[beano]

I highly 2nd the recommendation to learn with coderunner, really quick for testing any scripts and code locally and debugging

[easyedc · Accepted solution]

I use BBEdit (which replaced the same vendor's TextWrangler) for my script composition. It's got a handy option to run with some variables.

[#9]

thank you everyone!!!

[nvandam]

I was introduced to shellcheck.net at JNUC last year and really like it. Doesn't run the script, but helps check your formatting and such. Very handy.

[skinford]

Good morning,

@claudiogardini Can you run CodeRunner with sudo privileges? If so, how? I recently started using it since last weeks MacAdmins at PSU. I can't figure if it will or how to do it.

Thank you!

[claudiogardini]

@skinford Not as far as i know.

[jkeller13]

@skinford & @claudiogardini - You can run the script with sudo using CodeRunner. With the script open, go to "Run Settings" in the top left corner, and change the 'Run Command:' to add sudo in front.

1 | bash $filename       changes to        1 | sudo bash $filename

This is per script window, though you can change the default setting to include sudo as well.

[techdan]

I am getting error when running this with sudo

[jkeller13]

Never saw this reply until now, my apologies. If you didn't figure it out, that's because you set a breakpoint at line 7 for the debugger. Un-click the blue mark on line 7 and you should be good.

[VitorCostaUK]

Highly recommend coderunner aswell

[poormatt]

+1 for Coderunner

[tlarkin]

Pro tips for running a script during your development phase

1 - use VCS, like git
2 - IDEs are helpful, even for shell scripts (VS Code, Jetbrains, even vim has IDE like env)
3 - run your code in debug mode, for shell you can do bash -x /path/to/script,sh or even zsh -x /path/to/script.sh
4 - use some sort of coding style and break out larger code into functions, yes even in shell use functions. Why? So, when looking back at code you wrote 6+ months ago, all the logic is split up into blocks of code that do a specific thing. This makes debugging old code so much easier and organized, versus sifting through tons of inline code that you have to follow around
5 - document your code, use comment code and doc strings, and be specific what each thing does
6 - have it peer reviewed. Find someone you work with to review your code and go over it. A second set of eyes always helps and it also helps keep the checks and balances in place of people making bad decisions unknown to themselves.

[mm2270]

All excellent suggestions above from @tlarkin. Although I do not do everything on that list, I'm particularly fond of points 4 & 5. I tend to put nearly anything that is semi complex or has even a small chance of needing to be done more than once in a script into a function block. It really makes understanding the code much easier since it means your if/then blocks are less complicated, among other things. It also makes doing loop/repeat type stuff easier to implement in general.

And documenting your script/code is important. You sometimes make decisions in your script creation that won't make sense down the line, so putting some comment blocks explaining what something is doing can be essential. I've even designed out workflow diagrams for my more complicated and lengthier scripts. Those tend to be more for others than myself, but they can also be helpful later on when looking over the script to make any edits.

As for the suggestions on an app to use, CodeRunner is a good app. I tend to use BBEdit myself, which does have the ability to run scripts. Since BBEdit is really an advanced "text editor" and not necessarily just a script/code editor, it doesn't have all the code related bells and whistles of CodeRunner, but it does a good enough job for me nonetheless. To each his/her own I suppose. The important takeaway should be to use a good code/script writing app, and avoid general purpose text writers like TextEdit, which will certainly mangle your scripts unless you're very careful.

[phredman]

I would also recommend testing code in a VM, versus using the local device.

[tlarkin]

@mm2270

The whole comment your code thing could not agree more. I remember dealing with older Apple bugs and coding around them way back in the day in my career, and then having to go over that code after Apple fixed the binary bugs. I did not always comment what I was doing back then, so I was trying to remember why I did a work around. I could remember that I had to do a work around, but i could not remember why. Knowing the "why," part is equally important sometimes as the "how," part. In my opinion of course.

[tlarkin]

Also, huge emphasis on test environments or staging. For example, when I push out new code or flows, after the dev/QA/POC process the first two business units that get the new code are always security and IT at my job. I use department scoping to stage the changes to both IT and security. That way both parties can experience and vet the changes, and if there is any security issue they can speak up before I deploy to gen pop.

I do have a test JSS, but that is mostly for dev work, as at the end of the day the only true real test is in production. This is why I do staging in production on major changes to only two business units first. Then after validation in staging that it works, it goes into release.