Shockwave and Rosetta - still need a command

The Open using Rosetta setting modifies the file: ~/Library/ Preferences/com.apple.LaunchServices.plist

defaults read com.apple.LaunchServices shows an entry:

LSPrefsFatApplications = { "com.apple.Safari" = ( <00000000 009a0003 00010000 c323458f 0000482b 00000000 00000023 0000727b 0000c2b0 8b4e0000 00000920 fffe0000 00000000 0000ffff ffff0001 00040000 0023000e 0016000a 00530061 00660061 00720069 002e0061 00700070 000f0014 00090053 00650072 00760065 00720020 00480044 00120017 4170706c 69636174 696f6e73 2f536166 6172692e 61707000 00130001 2f00ffff 0000>

that corresponds to what is seen using Property List Editor. When the button is clicked off, this entry disappears.

Two problems: 1) How to get this to be happen at the system level and 2) how to set it using the command line.

I don't know what the data between the <...>'s is. It is the same between users and between toggling Rosetta on and off, and the LSPrefsFatApplications entry in Tiger is replaced by a much different LSArchitecturesForX86_64 entry in Leopard:

"LSArchitecturesForX86_64" = { "com.apple.Safari" = ( <00000000 00a00003 00010000 c3ecd416 0000482b 00000000 000000a0 00028d9a 0000c2f1 13950000 00000920 fffe0000 00000000 0000ffff ffff0001 00040000 00a0000e 0016000a 00530061 00660061 00720069 002e0061 00700070 000f001a 000c004d 00610063 0069006e 0074006f 00730068 00200048 00440012 00174170 706c6963 6174696f 6e732f53 61666172 692e6170 70000013 00012f00 ffff0000>, ppc, <00000000 00960003 00010000 c44f641c 0000482b 00000000 0000005c 0000be47 0000c440 fd790000 00000920 fffe0000 00000000 0000ffff ffff0001 00040000 005c000e 0016000a 00530061 00660061 00720069 002e0061 00700070 000f0010 0007004e 00650074 0042006f 006f0074 00120017 4170706c 69636174 696f6e73 2f536166 6172692e 61707000 00130001 2f00ffff 0000>, ppc ); };

Dan Peterka

I don't know the answer, but the way I'd find it is to get a 'new and modified' snapshot via Composer before Rosetta is enabled, then enable Rosetta, then launch the app, then quit the app, then build the package in Composer and examine the changed files that relate to the app in question, or possibly launch services in this case.

If the desired file is a plist, as I imagine it would be in this case, I'd find the operative key(s) and use a 'defaults write' script rather than packaging the plist to avoid altering undesired settings.

Of course test, test, test and test again, on a system that won't cause you
any problems if you break it, but here's what I'd do...

Put together a defaults write script to create these plist entries. If you
make that script the object of a policy that is triggered at login, with a
frequency of once per user, you will set the preference for each user as
they login without the need to make the change at the system level.

Alternatively, you could package up the plist, and fill existing users (FEU)
and fill user template (FUT). The upside is that all all current and future
users on the target system will have this setting. The downside (and this
can be big issue with a plist like LaunchServices) is that all other prefs
contained within the plist will potentially be changed on the target system.

A third alternative would be to create a Launch Services package using the
User Environment tab within Composer and again, FEU and FUT. If you go this
route, I would recommend creating your Launch Services package using a test
machine that has all of the standard software for your environment installed
and tested. Further, I'd recommend re-creating your Launch Services package
after adding or removing any software titles to your environment.

I hope this helps.