Re: Postflight install script issue

[bluebox]

[QUOTE][u]Quote by: larkost[/u] [i]While this sort of thing is why I put in the chroot jail in the first place, I do consider this sort of thing bad scripting on the package maker’s part. But the solution is really easy: you just have to reference the “target” drive that the installer is feeding you as the “$3” (third) argument to your script.[/i][/QUOTE]
Ah, but I’m a bad bash-scripting newbie, and [lightbulb goes on] didn’t catch the connection of using special variables in the postflight script!

[QUOTE][u]Quote by: larkost[/u] [i]And you are also being a bit creative with the SetFile command, and there is a better way: include SetFile in the resources of your package, then reference it using the “$2” argument provided to your script.[/i][/QUOTE]
I [i]was[/i] including it as a package resource; the postflight script wasn’t finding the executable until…

[QUOTE][u]Quote by: larkost[/u] [i]So here is your modified script (assuming that you put SetFile in resources):
#!/bin/sh
“$2/Contents/Resources/SetFile” -a V “$3/Library/Scripts/script.sh”
Note that I am quoting both paths in case they have spaces in them. This is also off-the-cuff and untested, so you might need to do some troubleshooting.[/i][/QUOTE]
[b]…and it worked like a charm.[/b]

[QUOTE][u]Quote by: larkost[/u] [i]Overall I would say that you probably should not be trying to hide this. Smart users are going to find it anyways, and not-so-smart users are probably not going to be looking in /Library/Scripts in the first place. If you are hiding things in this script, then there is probably a better way.[/i][/QUOTE]
Totally right — I was appeasing others. Intended users of this image will not be allowed access to the system folder anyway.

Thanks!