Duet Display adds Touch Bar

I like to use Duet Display to add some screen real estate to my 13" MacBook Pro. When you connect the iPad with a Lightning cable Duet turns it into an external second screen. Depending on your settings there can be a slight lag, so you won’t play action games, but it works wonderfully for normal tasks (such as writing a book.) It will also translate touch input to mouse inputs and if you have an iPad Pro it also works with the Apple Pen.

I have the 2015 MacBook model, so no Touch Bar and I have no urgency to upgrade yet, even though I think the Touch Bar seems to be very interesting.

So, I am very excited to see that Duet Display added an option to add a Touch Bar at the bottom of the iPad screen). Since the iPad will probably be sitting next to your MacBook screen, rather than right above your keyboard, this is not perfect. But a great way to test an application’s support and see how the Touch Bar works without having to shell out for a new MacBook. This will take away a bit of your second screen on the iPad, but you can enable or disable the Touch Bar at whenever you want.

They have also reduced the price for the iOS application by 50% ‘for a limited time.’ Duet Display uses a Mac or Windows application, which is free and an iOS application which usually costs US$19.99 (now $9.99). Full Apple Pen support which turns the iPad Pro into a retina drawing pad for your Mac is an extra in-App purchase.

On hidden Files, especially Library

I published a book: “Packaging for Apple Administrators

While writing on the next book “Automated Packaging for Apple Administrators”, I will keep publishing small side notes and excerpts. There is a nice gem for macOS Sierra in the last section, so keep reading.;)

Mac OS X has always hidden certain folders and files from the user. The more ‘UNIXey’ folders like /usr, /bin, and /etc were considered too confusing or even dangerous for most users and hidden away. Most users noticed this in OS X Lion when Apple started hiding the user’s Library. Messing with files in the Library can cause damage or data loss if a user does not know exactly what they are doing. Here is the summary on hidden and invisible files.

Dot Files

In UNIX, files or directories with a name beginning with ‘.‘ (period or dot) are considered hidden and will not be shown in a normal file list with ls. You can however easily list them with the option ls -a. Usually dot files are configuration files or folders.

When does Finder consider a File hidden?

Like the ls command Finder will not show files beginning with a ‘.‘ (period or dot). However, there is also an extra hidden flag that Finder will check to see wether it should hide a file. You can see this hidden flag in Terminal with the -O (capital o) option for ls

$ ls -lO 
drwx------+ user  staff  -        Downloads
drwx------@ user  staff  hidden   Library
drwx------+ user  staff  -        Movies

(I removed lines and columns to make the output more legible.)

You can also use the find command to show all files with the hidden flag:

$ find ~ -flags +hidden -print

Use the chflags command to set or unset the hiddenflag:

$ chflags nohidden ~/Library
$ chflags hidden ~/Library

Finder will show or hide the file or folder immediately.

Navigating to your hidden Library

When you click on Finder’s ‘Go’ Menu with the option key, Library will appear as an option.

You can also use Finder’s ‘Go to Folder…’ menu and enter ~/Library as the target. This is especially useful since you usually want to go to a subfolder of Library anyway. This panel supports tab-autocompletion like the shell. OS X 10.11 and earlier would autocomplete to the alphabetically first match so ~/Library/Pref would complete to ~/Library/PreferencePanes rather than ~/Library/Preferences. macOS Sierra will show a popup list if the completion is ambiguous. The keyboard shortcut for ‘Go to Folder…’ command-shift-G will also work in open and save panels.

If you are already in a Terminal window you can use the open command:

$ open ~/Library/

Show all hidden Files and Folders

macOS Sierra has added a great Finder keyboard shortcut to quickly show hidden files and folders. Command-Shift-. (dot or period) will quickly show all hidden files and a second time will re-hide them.

This keyboard shortcut has worked in open and save dialogs for a while already.

In older versions of OS X you have to open Terminal and run:

$ defaults write com.apple.Finder AppleShowAllFiles true
$ killall Finder

Change the true to false to switch it back.

Editing Property Lists with plutil

I stumbled over these option this morning. I do not know when they were introduced, but I can see the options in 10.11 and 10.12. You can see them yourself with plutil -help. (The options are not listed in the man page.)

Note: Managing and editing Property List files and preferences is covered in much more detail and depth in my book “Property Lists, Preferences and Profiles for Apple Administrators

Quick recap: plutil manipulates property list files. Its main use up to now was to convert between property list formats (mainly from binary plists to something readable)

$ plutil -convert xml1 /path/to/propertylist.plist

and to check wether the syntax is valid

$plutil -lint /path/to/propertylist.plist

On Sierra, when you run plutil -help you see some new options. These allow you to directly manipulate keys and values in a property list. This may be useful to replace PListBuddy and defaults to manipulate property lists.

When testing this I noticed one downside of plutil immediately: it cannot be used to create a new property list file. Copy this to create an empty plist file:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict/>
</plist>

Inserting a new key/value pair

$ plutil -insert somekey -string somevalue test.plist
$ plutil -insert flag -bool YES test.plist
$ plutil -insert bestNumber -integer 1 test.plist
$ plutil -insert pi -float 3.141592 test.plist

This is pretty straightforward.

Inspecting a property list

You can use the -p option to check our progress:

$ plutil -p test.plist
{
  "newkey" => "newvalue"
  "pi" => 3.141592
  "bestNumber" => 1
  "flag" => 1
}

This uses a non-standard output format, and the help text warns to use this parse plists. But it will do to look at the content.

Note: you can use plutil -p to read the content of binary plists without converting!

Modifying values

You can modify values with the -replace option.

$ plutil -replace flag -bool NO test.plist

Note that you can create new entries with -replace:

$ plutil -replace otherkey -string othervalue test.plist

But you cannot overwrite an existing value with -insert.

Deleting values

Very straightforward:

$ plutil -remove otherkey test.plist

Arrays

You can insert an empty:

$ plutil -insert list -xml '<array/>' test.plist

or

$ plutil -insert list -json '[]' test.plist

and add items to the array

$ plutil -insert list.0 -string 'list item 1' test.plist
$ plutil -insert list.1 -string 'list item 2' test.plist
$ plutil -insert list.2 -string 'list item 3' test.plist

or do it all at once

$ plutil -replace list -json '[ "yes", "no", "maybe" ]' test.plist

Dictionaries

$ plutil -insert dictionary -xml '<dict/>' test.plist
$ plutil -replace dictionary -json '{}' test.plist
$ plutil -insert dictionary.key1 -string value1 test.plist
$ plutil -replace dictionary -json '{ "otherkey" : "othervalue" }' test.plist

Getting Values

It looks like -extract is meant to get values from a property list, but there is caveat. -extract will not merely get the value of a key in the property list but will write it to a new file! And by default if you do not provide an new output file path with the -o option it will overwrite the current file with the extracted data.

The proper, non-destructive syntax to use -extract is:

$ plutil -extract list xml1 -o - test.plist 
$ plutil -extract list json -o - test.plist 

This will print a full property list file to stdout. The -o - option tells plutil to print to stdout. You can give a filename instead of the -.

Since the output is encumbered with the json or xml syntax, it will be hard to use this to get to property list values in shell scripts. However, it still may be useful to, well, extract property list data from a complex plist file.

Conclusion

Keep in mind that there now is an alternative to defaults and PlistBuddy. Not having to convert a plist before changing data might be helpful, as well as the possibility to manipulate arrays and dictionaries with key paths. (You still should always use defaults when working with preference plist files, since defaults will go through the preferences system and possibility notify a process to update data.)

If you are using python or a similar high level scripting language it will still be more effective to use the libraries for property lists.

Visual Studio on the Mac

At its heart, Visual Studio for Mac is a macOS counterpart of the Windows version of Visual Studio. If you enjoy the Visual Studio development experience, but need or want to use macOS, you should feel right at home. Its UX is inspired by Visual Studio, yet designed to look and feel like a native citizen of macOS. And like Visual Studio for Windows, it’s complemented by Visual Studio Code for times when you don’t need a full IDE, but want a lightweight yet rich standalone source editor.

Read more at MSDN

Introducing: Packaging for Apple Administrators

packagingcover-v1-0This is exciting!

TL;DR: I wrote and self-published an iBook: “Packaging for Apple Administrators”. Go get it on iBooks!

Call it arrogance or hubris, but I have been pondering to write a book on Mac System Adminstration for a long time.

Personally, I have learned much from other people in the community and at work. I have tried to give back in a similar way in the various fora, on this weblog and by participating and presenting at conferences. But there is something about a book, even in digital form, where you can spend so much more time with a topic than a blog post or even a presentation can ever do.

However, there is always something else that seems more important. Usually a full-day job to pay the bills.

Recently, however, something happened. My wife got a wonderful offer from a university in Europe. We decided we could not pass up on that and moved the family back over the Atlantic. That gave me an opportunity to reconsider what I care about in my job and career. All along this there was this nagging voice whispering: “If you don’t do it now, you never will.”

So I started writing.

This iBook is an experiment on many levels.

I went down several dead ends. I have re-written, put aside, and discarded more than will be published in the end. I guess that’s normal. Some of the pieces which cannot or will not be used now, are ‘parked,’ hopefully to be used later. Maybe they will only serve as a reminder of where I came from and will be good for a laugh later on.

It is an experiment on wether I can self-publish a book on Mac management. If you are reading this, this part succeeded, at least. It’s a start.

I decided to self-publish on the iBooks store. This will allow me faster turnaround times for debugging. It will also allow me to keep the iBook up to date as I learn more on the topic (which I undoubtedly will) and when the OS and other tools get updated.

I also chose to make the book comparatively short. It has about a hundred or so iBook pages. This will make it easier to update it for the unvoidable bugs and errors and also to adapt the book to future OS upgrades. I also hope it will make more palatable to read and work through and a bit less daunting.

It is an experiment on wether self-publishing a book like this to an extremely niche market (Mac administration) is worth the effort and can pay my bills.

This book is the result of months and months of planning, writing, back-tracking and starting over. I also hope that what I learned in the past months means that I can write and publish a next book much faster.

Because of the experimental nature, I chose a well contained topic. There are many other skills and topics for Mac Administration that can and need to be addressed and that I hope to be able to address in the future.

The topic I chose for the first book is ‘Packaging.’

Using, analyzing and building installer packages is very fundamental to a system administrator’s job. Every management system relies on packages to deploy software, files and scripts to some degree.

Many questions on the different Mac Administrator fora is answered with “put it in a package” with the common reply of “yeah, I really need to learn more about packaging.”

This is your chance!

This book will guide from analyzing packages and their contents to simple projects where you build your own packages. In the end there will be some failry complex packaging projects. The examples chosen are ‘real-world’ projects from my work as a system administrator. Some of the projects should be useful for your deployment right away. I also chose the examples so they cover a spectrum of problems and can be adapted to other problems.

If you are just briefly aware of packaging and scripting in the Mac community, you will have heard of autopkg and AutoPkgr. Originally I had planned to cover these in the first book (and much more). But the sheer versatility, complexity and and power of these tools would have delayed this book even more than it already is.

I do hope I get the chance to write that follow-up book. And many more.

Now go, get the book on iBooks!

Get it on iBooks

SSH-installer

Mac System Administrators regularly have to build and test installer packages. One of the best ways to test a package is to install it on a virtual machine. You can then quickly revert the VM to a snapshot after the installation and try again.

Since most package building happens on the command line, the fastest way to copy and install a package is with ssh. You can use scp to copy the pkg file and then run the installer command in an ssh session.

Doing two separate commands over and over seemed quite tedious. so I built myself a short script that combined both. ssh-installer takes two arguments, the first is the remote host in the form [user@]hostname (user is optional) and the second in the pkg file you want to send and install. All other arguments will be passed into the installer command on the remote host. You will probably want to add -target / in most cases. I did not add the -target as a default in case you want to test installer’s other parameters.

This script is just a shortcut for a task I have to do several times while building and testing packages. It is not in any way meant to serve as a means of managing Mac clients. You really should use a decent management system for that.

Randomize Window Backgrounds in Terminal

Quick Terminal tip:

Make a copy of the /Library/Desktop Pictures/Solid Colors/ directory in your home folder and delete all dark and medium gray color files from the copy.

In “Terminal” > “Preferences” > “Profiles” choose the “Basic” profile. Drag your copy of the Solid Colors folder from the Finder on to area next to the “Image” label where it says “no Background Image”.

TerminalProfile

If you already have Terminal windows using this profile they should apply the color immediately, and any other terminal window you open will get a random background from the colors in your folder.

ColoredTerminals

If you prefer light text on dark background you can remove the lighter colors from the folder instead, or make your own set of background images. Enjoy!

AutoPkg Recipe definition for PlistEdit Pro

With AutoPkg and Munki you are juggling property list files all the time. Sometimes using a text editor is the best choice, other times you want a graphical representation of the property list. Xcode can be used for that, but launching Xcode for a humble plist always seems overkill… and slow. My preferred tool of choice for this is FatCat Software’s PlistEdit Pro.

AutoPkg recipes have a well defined format. Creating them from scratch in an editor can be boring and error prone. PlistEdit Pro offers a feature called ‘Structure definitions’ which… well… allows you to define the structure of a property list. Best thing is you can create your own, though the documentation on their website is a bit outdated.

If you want to do this, download this definition file and put it in ~/Library/Application Support/PlistEdit Pro/Structure Definitions. Then restart PlistEdit Pro. Finally, go to “Preferences > Definitions”, select the “AutoPkg Recipe” in the list and add ‘recipe’ as a file extension.

Now when you open a .recipe file, it will know to use this definition. This will help with some steps of managing recipes. For example when you create a new element in the Process array, it will automatically be set to be a dict and pre-filled with a Processor string element and a Arguments array element. It will also warn when you try to delete mandatory elements.

When you create a new empty file and change the definition from the ‘Definition’ menu, it will pre-fill your new file with the right keys for a recipe. Enjoy!

Make tab-completion in bash case-insensitive

I added this to a discussion on the MacAdmins Slack today and realized it could be useful for a broader audience.

The underlying problem is that by default HFS+ (the file system of OS X) is “case preserving, but case-insensitive.” That means the file system will remember wether you named a file or directory “README.TXT” “ReadMe.txt” or “readme.TXT” and preserve that case, but using either of these will point to the same file.

This may be confusing in Terminal. Since most other Unix and Linux file-system are case-sensitive (i.e. README.TXT and readme.txt are different files) most shells are, too. So on OS X in bash you can write:

$ cd ~/DESKTOP

and it will actually work. Though if you then print the working directory, you get

$ pwd
/Users/armin/DESKTOP

which doesn’t hurt anything really, since Desktop and DESKTOP are the same. But it does hurt our OCD, right?

While I have not yet found a way to change this behaviour directly, one thing you can change is wether tab-completion is case-sensitive or not. Since the underlying filesystem is insensitive, there really is no reason tab-completion should be. This way you can type /sy[tab]/l[tab]/cor[tab] and it will expand to /System/Library/CoreServices/.

Tab-completion is not just for laziness, but also a way to ensure you are typing a path correctly, especially since tab-completion will escape spaces and other nasty characters automatically.

To make tab-completion in bash case-insensitive put this in your .inputrc (create if necessary)

# Ignore case while completing
set completion-ignore-case on

and then close all Terminal windows and start a new one.