Re: Environment variable availability within post-install script
Re: Environment variable availability within post-install script
- Subject: Re: Environment variable availability within post-install script
- From: Bill Coderre <email@hidden>
- Date: Mon, 10 May 2010 11:30:06 -0700
On May 10, 2010, at 10:22 AM, Greg Neagle wrote:
> Again, I urge installer writers to consider other scenarios that make this sort of thing problematic.
>
> Consider a company or school where the primary users do not have administrative rights:
>
> 1) An admin physically visits each machine, logs in with his/her admin account, and runs the installer. Your user-specific stuff is installed in the home for the admin account. The admin logs out and the primary user logs back in. How do they get your user-specific stuff?
>
> 2) The organization has remote deployment software that installs your software while no-one is logged in, or in the root context using /usr/sbin/installer. Assuming your scripts don't barf in this scenario, when a user later logs in, how do they get your user specific stuff?
>
> 3) The primary user leaves the company and a new user takes over the position and the machine, getting a new user account in the process. How do they get your user-specific stuff?
>
> There may be multiple users for a given machine - even in a home environment. How does a user other than the one that manually ran your installer get the user-specific stuff?
>
> Don't think you can just search for additional user folders under /Users and molest those as you install -- that won't cover new users added after the install; current users not-logged in whose home directories are protected with FileVault, or network users.
>
> If there are resources that must be copied to each user's home directory, consider using a LaunchAgent installed in /Library/LaunchAgents that checks for these resources and copies them from a cache at login. Or modify the application to do this upon launch. This way you cover all possible user account scenarios. This pushes the responsibility from the installer-writer to the software developer, which is where it belongs. (Of course if you have both roles, this makes little difference...)
Very important points. Here are some vague suggestions on how to cope:
1) Get rid of per-user things.
Obvious, but: Don't have your installer create per-user preference files! Put "Shared" content in /Users/Shared/ or /Library/Applications Support/YourApp/
This should take care of most things for App developers. (Yes, this is different than Windows. Sorry, but you're going to have to cope with it.)
Extreme case: Some people make "restore CDs" that completely populate users. They MIGHT need to research "User Templates" which create stuff when a new user is created. In almost all cases, you don't need to do this, and should not.
2) To find all the users on this machine, /usr/bin/dscl is your friend.
Go type man dscl.
dscl . list /users
(As stated, this doesn't cover users created after installation.)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Installer-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden