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: Xochitl Lunde <email@hidden>
- Date: Mon, 10 May 2010 09:57:00 -0500
<installer-dev-bounces+xochitl_lunde=email@hidden>
wrote on 05/09/2010 05:14:18 PM:
>
> On May 9, 2010, at 8:10 PM, Tim Streater wrote:
>
> > My post-install script (written in PHP) must write a file on
the
> > user's desktop, and so needs the user's shortname in order to
> > construct the path. The script also modifies the apache config
file
> > and so needs admin priv. I appear to be able to give it that
by
> > ticking "Require admin authentication".
> >
> > In my PHP, I appear to be able to do:
> >
> > $user = getenv ("USER");
> >
> > to have the logged-in user's name. This seems unexpected to me,
I
> > would have thought that I would get "root", if anything
at all. It
> > also seems at variance with the documentation that lists the
> > environment variables available to the scripts. Can I rely on
what
> > I've done or is there a better way of getting the user's shortname?
>
> I didn't know you could use PHP code in a post-install script but
> that's the correct environment variable.
> _______________________________________________
I had some issues doing user-specific stuff in my
scripts. I noticed that the preflight script gets different environment
variables and I couldn't rely on the SUDO_USER or other user variables
and have it work for command line and GUI install. I also had to
change my script to work when no users were logged in, which seemed to
fix the problems I had with ARD installation.
I ended up doing something like this which works for
all cases for me, but I don't have a way of knowing if it's an OK practice
or a long term solution. What I do is check if the user is not the
root user (which happens in a GUI installation) and if I'm not root use
the $USER variable. Otherwise if I am root (command line install)
then I use the HOME environment variable to compare to 'users' logged in
who have a console session on the machine. If I try to use launchctl
to start a program for a user I don't have access to, then launchctl doesn't
give me permission. In the event of a failure, I just make sure that
my later parts of the script don't count on the program having started
since in my case it will start on the next reboot anyway.
(This next stuff might have a typo or two, I had to
retype it for this email)
if [ ! "${USER}" = "root" ] ;
then
su $USER -c 'launchctl
load -w /Library/LaunchAgents/com.mycompany.product.plist' || : # dont'
hang
else
home_user="";
for user in `who
| grep console | awk {'print $1'}`
do
user_in_home="`echo "{$HOME}" | grep
$user`"
if [ -n ${user_in_home}" ] ; then
$home_user=$user
echo "Home
user is '${home_user}'."
fi
done
#if there's a
home_user discovered start the program. otherwise the home user is not
logged in or is using a terminal session.
if [ -n "${home_user}"
] ; then
su $home_user -c 'launchctl load -w /Library/LaunchAgents/com.mycompany.product.plist'
|| : # don't hang
fi
fi
_______________________________________________
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