Archive

Archive for the ‘AppleScript’ Category

Payload-Free Package Creator 2.4 now available

April 3, 2022 Leave a comment

Payload-Free Package Creator.app, an Automator application that allows the selection of an existing script and then create a payload-free package that runs the selected script, has been updated to version 2.4.

The functionality and operations of the app have not changed from Payload-Free Package Creator 2.3. The main change is that Payload-Free Package Creator.app is now a Universal app, allowing it to run natively on both Intel and Apple Silicon Macs.

Payload-Free Package Creator 2.4, along with all components and scripts, are available on GitHub via the link below:

https://github.com/rtrouton/Payload-Free-Package-Creator

Simple Package Creator 1.5 now available

April 2, 2022 Leave a comment

Simple Package Creator.app, an Automator application that will allow the selection of a self-contained application and creates an installer package that enables the installation of the application with pre-set permissions into /Applications, has been updated to version 1.5.

The functionality and operations of the app have not changed from Simple Package Creator 1.4. The main change is that Simple Package Creator.app is now a Universal app, allowing it to run natively on both Intel and Apple Silicon Macs.

Simple Package Creator 1.5, along with all components and scripts, are available on GitHub via the link below:

https://github.com/rtrouton/Simple-Package-Creator

First Boot Package Install Generator.app now adds product identifier tags to its packages

November 22, 2017 Leave a comment

As a follow-up to Greg Neagle’s discovery that product identifiers are now needed to ensure best results when adding additional packages to macOS High Sierra OS installers, I’ve updated First Boot Package Installer Generator.app to add product identifiers by default to the firstboot packages created by this tool.

The product identifier values will be the user-selected Package Identifier followed by the Version Identifier.

Screen Shot 2017 11 21 at 2 21 13 PM

Screen Shot 2017 11 21 at 2 21 19 PM

These values will appear in the firstboot package’s distribution file as shown below:

Screen Shot 2017 11 21 at 2 22 03 PM

For those who need this capability, an installer for First Boot Package Install Generator.app 1.7 can be downloaded via the link below:

https://github.com/rtrouton/First_Boot_Package_Install_Generator/releases/tag/1.7

Reading AppleScript source code with osadecompile

May 10, 2016 Leave a comment

When working with AppleScripts that other folks have written, it’s often useful to be able to look at the source of the AppleScript. One quick way to do this via the command line is to use the osadecompile command. This command is designed to output the source of a compiled AppleScript or other OSA language scripts to standard output. For more details, see below the jump.

Read more…

Setting Microsoft Outlook as the default application for email, contacts and calendars via Automator

December 1, 2015 10 comments

While working on an Outlook 2016-related issue earlier this week, I found that there is not a straightforward way to set Microsoft Outlook 2016 as the default application for email, contacts and calendars. To redress this, I’ve developed an Automator application named Set Microsoft Outlook as default application for email calendars and contacts.app to handle this task.

The Set Microsoft Outlook as default application for email calendars and contacts application leverages duti, an open source tool used for managing application ownership of document types and URL schemes on Mac OS X, to set the newest version of Microsoft Outlook on the Mac as the default application for email, contacts and calendars.

The application includes an embedded copy of duti, so it is not necessary to have duti pre-installed on the Mac in order to use this tool. For more details, see below the jump.

Read more…

Automator’s Ask for Finder Items windows no longer showing text prompts in OS X El Capitan

November 30, 2015 3 comments

As part of working with Automator to build applications, I’ve been leveraging the ability of Automator’s Ask for Finder Items action to set text prompts in my Automator-based applications.

These text prompts are included in the appropriate Finder windows and have been an easy way for me to set a particular message in an Automator selection window.

Screen Shot 2015 11 30 at 9 43 34 AM

I recently noticed in OS X El Capitan that these messages no longer appear, which is a bit inconvenient as it leaves users of my applications with no clear direction as to what to do when this window appears.

Ask for Finder Items windows in OS X El Capitan and OS X Yosemite 001

 

It does not appear that AppleScript is affected by this issue, as the comparable AppleScript function properly displayed the desired text in both Yosemite and El Capitan.

Screen Shot 2015 11 30 at 10 16 47 AM

As a workaround to keep my applications’ users informed on what to do, I’ve set standalone AppleScript notifications to appear in my Automator applications before the Ask for Finder Items Automator action’s window.

Screen Shot 2015 11 30 at 10 03 56 AM

All three of my Automator-based applications have now been updated with the workaround:

 

I’ve filed a bug report with Apple on this issue. For those interested in duplicating this, it is bug ID 23688457. I’ve also cross-posted the bug report to Open Radar, so the bug report details are available from the link below:

https://openradar.appspot.com/23688457

Payload-Free Package Creator.app Revisited

May 21, 2015 6 comments

I do a lot of work with payload-free packages and while I have a process for creating them as I needed them with pkgbuild, this approach requires some setup work. To help make the package creation process more convenient, I developed Payload-Free Package Creator.app, an Automator application that will allow to select an existing script and create a payload-free package that runs the selected script.

However, this tool has used pkgbuild‘s –nopayload function, which creates a package which doesn’t leave an installer receipt behind. This is intended behavior according to Apple, but not leaving a receipt behind can make it hard to determine whether an installer package has been run on a particular machine. This is especially problematic for Munki, which uses receipts along with other methods to track installation status.

While I don’t use Munki, I’ve heard from a number of folks who do and who had run into the no-receipt problem when they tried to use payload-free packages generated by Payload-Free Package Creator.app with Munki.

So the problem was this:

  1. I wanted to create payload-free packages which only run scripts and do not install files.
  2. I wanted to have an installer receipt.
  3. Apple’s built-in method for generating payload-free packages with pkgbuild didn’t provide receipts.
  4. I thought I needed to provide a payload to pkgbuild in order to generate a package which would provide receipts.
  5. Providing a payload meant I was installing files, which is what I didn’t want to do.

The matter had rested there for a while and I didn’t see a good way to fix it.

Fortunately, I was wrong about point 4. Greg Neagle recently documented that you can make a package with pkgbuild that, while not technically payload-free, will act just like one. The key is to create an empty directory and set pkgbuild‘s –root option to look there for files. pkgbuild‘s –root option is used to tell pkgbuild which files to package, but since there will be no files in an empty directory, the package will install no files on the destination Mac.

That’s where I had gone wrong on point 4 – I thought I had to give pkgbuild something to install in order to build a package with a receipt, but it turns out that pkgbuild will successfully build a package while using an empty payload directory. This information allowed me to reconcile points 1 and 2, which resolved the problem.

With this new information, I was able to update Payload-Free Package Creator.app and I’m happy to announce it has two new features:

  • Version numbering
  • Packages generated by Payload-Free Package Creator.app will leave receipts behind after installation.

For more details, see below the jump.

Read more…

First Boot Package Install Generator.app

October 19, 2014 25 comments

With the release of Yosemite, Apple has apparently made an undocumented change to the way it allows packages to be added to the OS installer. If you add any additional packages for installation as part of the OS install/upgrade, they must all be distribution-style flat packages. You can convert a component flat package to be a distribution-style flat packages by running the command below:

productbuild –package /path/to/component.pkg /path/to/distribution.pkg

This change is a problem for First Boot Package Install.pkg and First Boot Package Install With Automated Apple Software Update.pkg, as they are both built as a bundle-style package and not as flat packages. While both First Boot Package Install.pkg and First Boot Package Install With Automated Apple Software Update.pkg run fine on Yosemite, they cannot be added to customized NetInstall images created with System Image Utility or to createOSXinstallPkg-built Yosemite OS installer packages.

First_Boot_Package_Install_Generator_Icon  

To address this issue, I’ve developed First Boot Package Install Generator.app, an Automator application that will allow the selection of a folder containing installer packages and then generate a distribution-style flat package that enables the selected packages to be installed at startup. It’s designed for use with createOSXinstallPkg with the goal of allowing installer packages that can’t run in the OS X Install environment to be used as part of a createOSXinstallPkg deployment workflow. See below the jump for the details.

Read more…

Simple Package Creator.app

April 29, 2014 15 comments

One task that has always seemed to me to take more time than it should is the process of packaging applications like Firefox, Google Chrome or other applications which are self-contained and can be copied as-is into /Applications. While tools like AutoPkg have helped a good deal by automating the download and packaging of various self-contained applications, this approach still requires some setup work and requires a recipe to be written to handle the application.

Screen Shot 2014-04-28 at 3.06.33 PM

To help make this task easier, I’ve developed Simple Package Creator.app, an Automator application that will allow the selection of a self-contained application and creates an installer package that enables the installation of the application with pre-set permissions into /Applications. For more details, see below the jump.

Read more…

Payload-Free Package Creator.app

March 8, 2014 8 comments

I do a lot of work with payload-free packages and I’ve looked for a while for a tool that would let me easily create them from existing scripts. While I have a process for creating them as needed with pkgbuild, this approach still requires some setup work.

Payload-Free Package Creator logo

After thinking about it and taking a look at various approaches, I’ve developed Payload-Free Package Creator.app, an Automator application that will allow the selection of an existing script and create a payload-free package that runs the selected script. For more details, see below the jump.

Read more…

%d bloggers like this: