Hi all. This one came from a discussion during a recent training course I attended. How could we deploy settings for Atom, without overwriting any settings configured by the user? Things like suppressing first run messages, and disabling auto-update?
Firstly, some detective work…
The Atom application stores it’s configuration and data files in a hidden folder, in each user’s home area at
Most (if not all) of the configuration settings are stored in a file called
config.cson in this directory. This includes core application settings, as well as settings for any installed packages. Forcing this file to open in a text editor shows what appears to be very similar to (but not quite) a JSON file:
This is actually a CSON (CoffeeScript Object Notation) file as detailed by the Atom developers here.
Why not just set the file up and push out to all users?
In theory, this would indeed work (assuming you deploy the file with the parent directory, and permission it appropriately), but would also wipe out any settings configured by the end user. Not ideal or user friendly!
Ok, so how can we pre-configure these settings?
My first thoughts here were to write a Bash script to work on the file, adding the configuration into whatever settings were already present. After struggling for an hour or so with this, it was pointed out that Atom supports a ‘start up’ script for configuration via the application APIs, an
An init.coffee file?
Yup, this is a file located in the same
~/.atom/ directory, with the name
init.coffee. The file contains configuration commands in the format:
For example, the below will suppress the welcome screen at startup:
I’ve built a full example
init.coffee file that will:
- Suppress the welcome screen on launch
- Turning auto-update off (ensure to patch via other methods!)
- Setting Telemetry consent to no and suppress the request.
That example file can be found here.
What else can the init.coffee file do?
To be honest, I didn’t delve too much further than this. I do know you can configure options for other packages (such as enabling the indent guide in the git-editor package), however check out the Atom developer documentation for more details.
So how can I deploy the init.coffee file?
So this init.coffee file will need to be:
- Added to each user’s home area
- Added to a directory called
.atomat the root of the user’s home area
- At least readable by the user account
You have a few options for this, depending on the toolset available, and personal preferences:
- (If you’re a Jamf customer) – Create the file in-place, package as a disk image via Jamf Composer and deploy with FEU (Fill Existing Homes) and optionally FUT (Fill User Templates) enabled.
- (If you use Outset) – Package up the file to be deployed somewhere local, and have a ‘login once’ or ‘login always’ script to copy the file into place
- (If you’re happy writing a LaunchAgent) – Package up the file to be deployed somewhere local, and have a Launch Agent triggered script to copy the file into place
- (If you’re lazy!) – I’ve written up a script that can be found here. This creates the directory and writes the file out to all home folders in
/Users/and all User Template folders in
/System/Library/User Template. This can be triggered as a script in a Jamf policy, a Munki post-install script or a traditional postinstall script in an installation package!
This post covers a possible method for pre-configuring some helpful Atom settings for your deployment. As always, if you have any questions, queries or comments, let me know below (or @daz_wallace on Mac Admins Slack) and I’ll try to respond to and delve into as many as I can.
The usual Disclaimer:
While the author has taken care to provide our readers with accurate information, please use your discretion before acting upon information based on the blog post. I will not compensate you in any way whatsoever if you ever happen to suffer a loss/inconvenience/damage because of/while making use of information in this blog.