RE: Strange behaviour with defaults read in install script
RE: Strange behaviour with defaults read in install script
- Subject: RE: Strange behaviour with defaults read in install script
- From: "Glover,David" <email@hidden>
- Date: Tue, 10 Mar 2009 10:27:17 -0000
- Thread-topic: Strange behaviour with defaults read in install script
Hi, thanks for all the useful info.
I've got a distribution package which contains a number of localized packages - I'm trying to find out how I can determine the current language of the machine, and select the corresponding localized package for install by default.
I haven't been able to find a decent way of doing this with javascript in my .dist file, so I'm looking into using 'system.defaults....'
It would be great if there was an easier way of getting this info! :o)
-----Original Message-----
From: Nigel Kersten [mailto:email@hidden]
Sent: 09 March 2009 18:42
To: Bill Coderre
Cc: Glover,David; Installer-Dev mailing-list
Subject: Re: Strange behaviour with defaults read in install script
On Mon, Mar 9, 2009 at 11:24 AM, Bill Coderre <email@hidden> wrote:
> BEFORE the user clicks "Install," anything the installer does is run as the
> console user.
> AFTER that, for most installs, anything the installer does is run as root.
> (ie. if the installer requires an admin password)
> The environment variable USER is set to the console user short user name, so
> you probably want to do
>
> su $USER -c "defaults read -g AppleLocale"
Actually you probably *don't* as relying upon $USER in the environment
will break your package for all remote deployments via ARD, ssh/root,
or just about any large package deployment system.
Is this the right setting? It shows up as English for me...
defaults read /Library/Preferences/.GlobalPreferences AppleLanguages
and doesn't rely upon any user environments.
>
> to get the favorite language.
> Now, if you are trying to install, say, just one language, that's not
> standard. Mac OS X installers typically install all the languages, and the
> few users that are concerned can run a utility to get rid of unused
> languages (Monolingual is one).
> If you want to get a language to show the user some text during install:
> 1) Please try to do all your interaction before the user clicks install
> 2) if you can't do that, do
>
> su $USER -c "whatever_command arguments"
>
> On Mar 9, 2009, at 10:09 AM, Glover,David wrote:
>
> I'm trying out a few different things to retrieve the default language
> the machine is running in.
>
> What is really strange is that this works ok in a script...
>
> defaults read -g AppleLocale
>
> But that's not perfect as it's the language I'm trying to retrieve
> rather than the locale. By getting AppleLanguages, I can get the first
> language in the list.
>
>
> -----Original Message-----
> From: Karl Kuehn [mailto:email@hidden]
> Sent: 09 March 2009 17:00
> To: Glover,David
> Cc: Installer-Dev mailing-list
> Subject: Re: Strange behaviour with defaults read in install script
>
> On Mar 9, 2009, at 9:45 AM, Glover,David wrote:
>
> I'm using a preinstall script to read the available languages on the
>
> machine as follows;
>
> defaults read -g AppleLanguages
>
> This is fine via a Terminal command, or when running the script by
>
> Terminal, but when the script is run by Installer, the following is
>
> outputted;
>
> "The domain/default pair of (kCFPreferencesAnyApplication,
>
> AppleLanguages) does not exist"
>
> Has anybody come across this unusual behaviour before? Why has
>
> Installer decided to start lying to me?
>
> Installer isn't lying to you, it is telling you that for the
> user
> that you are running at at that point the list of default languages is
> not. This is true for any non-GUI user (try running this with sudo for
> instance). This command is essentially calling:
>
> defaults read .GlobalPreferences AppleLanguages
>
> And many users do not have a file at
> ~username/.GlobalPreferences.plist
>
> What are you really trying to accomplish here? And are you sure
> that
> the installer is the appropriate place for this?
>
> --
> Karl Kuehn
> email@hidden
>
>
>
>
> Promethean Limited is a company registered in England and Wales with company
> number 1308938 and VAT number GB 572 2599 18
> ______________________________________________
>
> Promethean Ltd and or associated and or subsidiary companies :
>
> The views expressed in this communication may not necessarily be
> the views held by Promethean Ltd and or associated and or subsidiary
> companies.
>
> This e-mail is for the exclusive use of the addressee(s). Unauthorised
> disclosure, copying or distribution is prohibited.
>
> This e-mail message has been swept for the presence of computer viruses.
>
> Promethean Ltd and or associated and or subsidiary companies accepts no
> liability for any loss resulting from this email transmission.
>
> Promethean, Promethean House, Lower Philips Road, Blackburn, Lancashire, BB1
> 5TH, UK. Please update your records accordingly. Thank you!
>
>
>
> *****************************************************************
> This email has been checked by the e-Sweeper Service
> *****************************************************************
>
> _______________________________________________
> 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
>
*****************************************************************
This email has been checked by the e-Sweeper Service
*****************************************************************
_______________________________________________
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