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: Greg Neagle <email@hidden>
- Date: Mon, 10 May 2010 10:22:03 -0700
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...)
-Greg
On May 10, 2010, at 9:56 AM, Tim Streater wrote:
> On 10 May 2010 at 16:19, Christian Lindemer <email@hidden> wrote:
>
>> Wouldn't it be better to use $HOME instead of the user name? THis works
>> if the user folder is in a non-standard location, e.g. a network home
>> folder or a home on a secondary volume.
>
> Thanks, that's a useful improvement.
>
> _______________________________________________
> 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
_______________________________________________
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