(responses inline) On 3/30/17 1:22 PM, "Mike Pullen" <mike@thepullen.net> wrote:

Stephen, I don't think it's necessary, or even a good idea, to do things in "public" places like /Applications as any given user. As long as the installer requires admin permissions to install, the script should run with admin permissions and should be able to remove those files. So, there shouldn't be any need to masquerade as a console user for this-- if there is a console user at the moment.

OK, sounds logical. My problem is I really don't know (yet) much about shell-scripting so I'm kinda mimicking other script examples I've seen. If what you say is the case, then it seems that using this to open the folder is unnecessary?: #!/bin/sh if [ "$COMMAND_LINE_INSTALL" = "" ]; then /usr/bin/su $USER -c "/usr/bin/open \"$2\"/.." fi exit 0 ...and simply this should suffice (for the operation): open "$2/.."

I'll harp again: Are you absolutely certain that your app will never be installed when noone is logged in (like, pushed by ARD or a software deployment mechanism when the machine is at the login screen, or shutting down)?

Yes! I know you keep recommending that article, and if I was starting out with a new app I would follow it, but I just don't see how most of it applies to my situation. This is not an app that will ever be "deployed". I've delivered it and installed it this way for over 15 years now, and that's not a defense for bad practices (or what was once 'ok' but is now considered bad), but it's not worth the effort to redesign the whole thing at this point because I generally just do incremental updates as required to support it as a legacy app, which isn't very often. It's a niche application, bought by individuals and installed for one user on a personal computer. The fact that I've recently discovered that I was opening a resource file with write permission and it would fail for any other user except admin or 501, yet I never received a single report related to that issue in 15 years shows that it was probably never installed in any way other than a single user installing it on a personal computer for which he has admin privileges. This whole re-examination of my installer practices was only prompted by the fact that I always used VISE-X and MindVision has gone out of business, and I needed to find a different installer solution. Thanks, - Stephen

(I don't wanna be a broken record-- I just hate to see anyone invest time on an installer that would break any of the "Commandments of Mac Packaging <https://www.afp548.com/2010/06/03/the-commandments-of-packaging-in-os-x/> "! There is no downside to embracing those commandments with every installer... : )

Mike

On Thu, Mar 30, 2017 at 3:09 PM, Stephen Kay <sk@karma-lab.com> wrote:

My installation puts a folder inside /Applications that holds the .app and some other support files (sorry, it's old). Within that folder, there is another folder that holds a pdf Help File.

The structure is like this (note spaces in names):

/Applications/My App Folder/My App.app /Applications/My App Folder/Help Folder/Help File 3.3.pdf

So if you install the new version on top of an older version, all files having the same names get replaced except for the Help File which has a version number at the end of it. So the user can end up with several older help files.

So I wanted to have the post-install script that is attached to my .app bundle delete any older Help Files.

In testing this, this WORKS to delete an older file (if it exists, and if not, who cares):

rm -rf "$2/../Help Folder/Help 3.2.pdf"

But I had gotten the impression that you should use sudo and the current user for everything, as shown in most of the examples I've seen here.

If I try this, it doesn't work:

/usr/bin/su $USER -c "/usr/bin/rm -rf \"$2/../Help Folder/Help 3.2.pdf\""

I must have something wrong with the quoting, I tried it without quotes, numerous variations of quoting and escaping etc., but I can't see it. Or there's something I'm misunderstanding about the examples I've seen.

Thanks, - Stephen

_______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/installer-dev/mike%40thepullen.net

This email sent to mike@thepullen.net

- Stephen =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Stephen Kay Karma-Lab :: developers of KARMA http://www.karma-lab.com =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.... This email sent to site_archiver@lists.apple.com