Postinstall scripts and bash functions

@bpavlov I think you're having an issue with JSS's Script Parameters

Sorry I should have clarified, I'm not testing in the JSS yet so it's not that. My only testing is in OS X 10.9.5, creating the package in Packages and running the built package.

@bpavlov so you're creating a PKG to locally mount a DMG to install a PKG?

Why not upload the PKG you're trying to install to Casper Admin?

Positional parameters, $0, $1, $2, $3 . . ., in bash are local variables. When you call a function, the positional parameters are defined differently in the context of that function.
http://tldp.org/LDP/abs/html/othertypesv.html

You can, outside the context of the function, define a global variable with the value of $3 in the script context. The function can then reference this variable inside the function since it is global. You can also pass the value of $3 to the function as a functional positional parameter when you call it. In this case, the position has changed and you will have to adjust your numbers accordingly. If you use the below code, it will be $1 in the context of the function.

1...
2if [[ ${osvers} -le 7 ]]; then
3    ScanSnap "$3"
4fi
5...

I, personally, think the code reads better using a global variable. I try to assign variables, global or local, at the "top" of the script/function to make the code more readable and then I don't have to worry about which context I'm in.

Yep, what josh said. When you put $3 inside the function, that is different than the $3 that you are passing to the script.

The $3 in the function means the 3rd argument you are sending to the function.

1#!/usr/bash
2
3echo "Script argument #3:  $3"
4
5function blah () {
6        echo $3
7
8}
9
10blah "1" "2" "three"

and when we run it:

1$ ./blah.sh 1 2 3
2Script argument #3:  3
3three

1#!/bin/bash
2
3#Working directory for script to reference resources
4install_dir=`dirname $0`
5
6# Determine OS version
7osvers=$(sw_vers -productVersion | awk -F. '{print $2}')
8
9#Variables for ScanSnap installer
10ScanSnapDMG="ScanSnap.dmg"
11ScanSnapDMGVolume="/Volumes/ScanSnap"
12ScanSnapInstaller="ScanSnap Manager.pkg"
13
14ScanSnap () {
15    /usr/bin/hdiutil attach -nobrowse -readonly $install_dir/"$ScanSnapDMG"
16    /usr/sbin/installer -dumplog -verbose -pkg "$ScanSnapDMGVolume/$ScanSnapInstaller" -target $1 -allowUntrusted
17    /bin/sleep 10
18    /usr/bin/hdiutil detach "$ScanSnapDMGVolume"
19    /usr/bin/killall "ScanSnap Manager"
20}
21
22if [[ ${osvers} -le 7 ]]; then
23    ScanSnap $3
24fi
25
26exit 0

Thanks @Josh_S and @chriscollins. That was very clear. The More You Know!

@bentoms I work of a simple rule. I try to do what I can so that if Casper is not available the package will work as is and has whatever logic is needed in it. From that simple rule I approach how I deploy packages. In this case this application requires 3 installers dependent on the OS version being run. I'm not going to create additional policies and/or smart groups when I can just package everything up and put the logic in a postinstall script. I chose to use the dmgs originally for just testing because I didn't want to take out the PKG out of it since it wasn't necessary and wanted to keep the original installers intact. I will ultimately take them out of the DMGs, but was just testing in this case. In certain situations I will take out the pkg if it needs to be modified right away, but in this case I didn't feel the need to do that since it was still a work in progress.

@bpavlov Fair do's. You have your reasons. :)