On Viewing `man` Pages

When you frequently use Terminal, you will use man pages. They contain tons of useful information on most of the tools and commands you use on the shell.

However, the man command’s user interface was designed for terminal output decades ago and does not really integrate well with the modern macOS UI. When you run the man command the output will take over your current Terminal window and scrolling through long man pages can be tedious.

Normal man page in Terminal


However, on macOS you do not have to man like it’s 1989.

First solution is to use

$ open x-man-page://ls

instead of man. This will open the man page in a new yellow Terminal window, so you can still see what you are actually doing, while reading the man page. If the yellow is just too annoying for you, you can change the look of the window by changing the ‘Man Page’ window profile in the Terminal Preferences. Since this window shows the entire man page, you can scroll and even use ‘Find’ (Command-F) in this window.

The beautiful yellow x-man-page window

Since typing this open command is a bit awkward, you can add a function to your bash profile or bashrc file:

function xmanpage() { open x-man-page://$@ ; }

Note: You could use xman here. However, that will conflict with another command when you have X11/XQuartz installed.

You can also put ‘x-man-page:’ URLs in other applications, such as emails or chat applications. However, not all applications will recognize URLs starting with x-man-page: as URLs, so your results may be mixed. It does work in Slack, even though Slack is skeptic of the links:

Slack will warn you about unusual links

Taken from Context

In Terminal, you can open a man page from the context menu. Simply do a secondary (ctrl/right/two-finger) click on a word in a Terminal window and choose ‘Open man Page’ from the context menu. This will open the man page in a separate window, like opening x-man-page URLs.

Open man Page in the Terminal context menu

man Page with a (Pre)view

Back in the early days of computing you could (or had to) convert man pages into postscript output, so they would look nicer when printing. These options are still present and we can (ab)use them to show a man page in Preview. (Please don’t waste paper printing man pages.) The command for this is:

$ man -t ls | open -f -a "Preview"
Preview showing a man page

The -t options pipes the man page into another tool (groff) to reformat it into pdf which we then pipe into open and send to the Preview application. (More on the open command.) If you use this more frequently, you want to create a function for this in your bash profile or .bashrc:

function preman() { man -t "$@" | open -f -a "Preview" ;}

Text Editors

You can also send a man page to a tex editor. Before you pipe the output into a text editor, you have to clean it up a bit:

$ MANWIDTH=80 MANPAGER='col -bx' man $@ | open -f

This will open in TextEdit. If your favored text editor can receive data from stdin, then replace the open -f with its command. For BBEdit, this will work great:

$ MANWIDTH=80 MANPAGER='col -bx' man $@ | bbedit --clean --view-top -t "man $@"

And again, if want to use this method frequently, create a bash function for it.


The ManOpen application has been around for a long, long time, but amazingly, it still works on macOS Sierra. It will also display man pages in a separate window. The main advantage MacOpen has over the other solutions here is that it will automatically detect other commands and highlight them as hyperlinks to their man pages. There is also a command line tool, confusingly called openman to open the app directly from the Terminal.


You can also create an Automator Service for this. Then you can open man pages from (nearly) any application with a keystroke or from the context menu. I described this in an older post on man pages.

Weekly News Summary for Admins – 2017-04-03

On ScriptingOSX

Posts and News


The updates for macOS 10.12.4, iOS 10.3 watchOS and tvOS(!) dropped this week. Lot’s of Apple support pages to catch up with:

To Watch

To Listen

New options for macOS Recovery

Mike Boylan on Twitter points to this new Apple Support article on re-installing your Mac. The option for restoring from internet recovery have changed:

Reinstall the latest macOS that was installed on your Mac, without upgrading to a later version.1
Upgrade to the latest macOS that is compatible with your Mac.2
Requires macOS Sierra 10.12.4 or later. Reinstall the macOS that came with your Mac, or the version closest to it that is still available.

News Summary: Week of 2017-03-24

Back when I was a Server Sales Engineer I would make a weekly summary for other Field Engineers and customers on server and admin related news.

Thought I might try this tradition, again. Welcome to the first Scripting OS X Weekly News roundup!

On this Blog

I published my second book ‘Property Lists, Preferences and Profiles for Apple Adminstrators’! (PR3 for short) Get the details in the pre-sales announcement and download the book here!

I also posted an update to the Packaging book last week. It got a new cover to fit with PR3 and some internal changes and corrections. I also added an extra page with the version history for all the update details. If you have purchased the book already, iBooks should have notified you of the update. If you have been ignoring that red batch on the iBooks app, go check it out!

If you have the books and like them, please leave a review on iBooks store!

And then I continued with the articles on the Terminal and command line with a new post: [Terminal – the ’’ marks the spot.

If I missed anything, let me know in the comments, twitter or the MacAdmin Slack forum!

Apple acquires Workflow app

You’ve probable heard it already: Apple has bought the Workflow application. The developers will keep working at Apple and the Workflow app is now offered for free on the AppStore, although with a few interesting changes.

Workflow has always been one of those apps that would have liked to get into. However, as an admin, my workflows center on macOS and Unix. You cannot build packages on iOS. Even iBooks Author only exists on macOS. As much as I like the iPad and iOS it has been relegated to secondary device because of the focus of my work.

Still it will be interesting to see how Apple will integrate Workflow with iOS and the Apple applications. I am looking forward to it.

If you now want to catch up with what Workflow is all about, you can’t do much better than Frederico Viticci’s articles on MacStories.

Sierra update 10.12.4: Disable iCloud Desktop and Documents Sync

Babo D: Disable iCloud Desktop and Documents Sync

Very useful discovery. When you search Apple’s profile documentation page for ‘10.12.4’ you also find a new key to disable Touch ID login on the new MacBooks and an entire new payload type for SmartCard setup.

BTW: you can of course learn more about configuration profiles in my new book: ‘Property Lists, Preferences and Profiles for Apple Administrators’ available in the iBooks Store now!

New Book — Property Lists, Preferences and Profiles

As it happens so often, the plan changed.

The plan was to go from ‘Packaging’ right to the obvious sequel ‘Automated Packaging’. And I am working on that book. However, since AutoPkg uses property list files for the recipes, I needed to introduce property list file formats and all the tools, quirks and caveats.

So the sidenote on property lists grew into an appendix. And it kept growing. Then I thought it would be a waste to explain property list files but not talk about preference files. And once you explained preference files, you should also introduce configuration profiles, especially custom profiles. Profiles are property lists after all.

So I moved the chapter on property lists into a new iBook. And I added chapters on preferences and configuration profiles, leading to a cumbersome, but memorable title. (‘PR3’ for short.)

So, here we are, not a sequel, but a ‘sidequel’. I will of course continue writing ‘Automated Packaging’ once this book is published.

PR3 is not quite done yet. I am still getting great feedback from the proofreaders. (Thank you!) But all the small pieces that are still missing or need refinement should fall in to place next week and I aim to release on March 20. (Deep breaths!)

And there will be updates to the iBook (like with ‘Packaging’) as I find more typos and learn more in future.

As with ‘Packaging’ the main target audience is either an administrator who is new to the Mac platform or a Mac user who is new to Mac administration and management. However, the proofreaders have all told me, there are many nuggets and pieces of new information for experienced admins as well.

Until then you can download the first chapter on property list file formats from the iBooks Store!

You can also pre-order and get the book automatically, as as soon as I press the ‘Publish’ button!

Get it on iBooks

Overall, writing these books is a great experience. It is a great chance to dive deeply into a topic. It is also a great chance to give back to the community that is amazingly generous in sharing knowledge and experience. There are many more topics on my list that I would like to write books on.

Is Packaging Dead?

I wrote a book on Packaging, you may have heard. (Please buy it! If you have bought and read it, please leave a review!)

I have been asked whether it was wise to publish a book on Packaging now. There is lots of talk in the Mac Admin community about the future of admin tools. The general consensus is that Apple wants to move macOS further towards a locked down system like iOS (and watchOS and tvOS). We have already seen the first moves in that direction with System Integrity Protection. Some suspect the new file system APFS may break traditional imaging workflows.

Note: I used to work for Apple, but that was years ago. I have no inside knowledge and all this is speculation, based on my many years of experience working with and for the company. I hope I am right, but would be the first to admit that I have made very wrong predictions regarding Apple before.

Up to now, these changes are not too severe. Some (myself included) even approve of deprecating legacy practices such as imaging, given that the alternative solutions bring many other benefits. However, there is the spectre of the completely locked down macOS, which can only be managed the same as iOS can: with an MDM server.

I do not think this is Apple’s ultimate goal. I also believe it will take longer than many are afraid of, and it may be even impossible in the long term without breaking the nature of macOS fundamentally. I’d like to give a few examples:

Omnigroup has been a productive and successful developer for macOS since NeXTSTEP. They were on Mac OS X before there was a Mac OS X. Last year, the OmniGroup switched some of their applications in the Mac AppStore from the one-time purchase model to a free-download with trial and in-app purchase model. I understand why Omnigroup decided to do this. However, Apple has no VPP solution for in-App-Purchases so an administrator cannot deploy Omni software with an MDM anymore. OmniGroup still sells their apps directly, so you can buy a volume deployment license directly from OmniGroup and deploy without the Mac AppStore, VPP, or MDM.

Veertu is an interesting new virtualisation solution, which started out in the Mac App Store. It could do that because it uses Apple’s Hypervisor Framework, which is meant to provide the system resources necessary for virtual machines to SandBoxed apps. However, last year, Veertu removed their solution from the Mac App Store because the limitations were still too stringent. Similarly, VMware Fusion, Parallels and VirtualBox are all not in the Mac App Store and not deployable with VPP or MDM.

MATLAB is a powerful solution for building scripts and tools with mathematical and engineering libraries. Calling MATLAB an ‘app’ would be like calling your MacBook a ‘typewriter with a screen.’ Scientists and engineers not only use MATLAB to build complex mathematical and statistical solutions, they share those solutions as products or open source tools. Many people may not even be aware that they are using a tool running the MATLAB runtime in the background. MATLAB is one of many powerful math/numerical/statistics tools, such as Wolfram Mathematica, IBM SPSS, R, etc. None of which are in the Mac App Store or even possible with the current Mac App Store limitations.

These math tools are deeply entwined with the UNIX philosophy of tools passing data from one to the other to do specialised steps of processing. Some workflows I have encountered are Rube-Goldberg-Machine-like sequences of MATLAB, Python, and bash scripts with a Qt or Java UI. As monstrous as these ‘solutions’ may be, they are essential for many people’s day-to-day work.

The only Adobe application in the Mac App Store is Photoshop Elements. There are many more Adobe apps in the iOS App Store, but none of their core Creative Cloud applications. One of the reasons may be that many Mac users, not only rely on the applications, but on plug-ins for these applications.

For some solutions, like AutoCad, the plug-ins have plug-ins. There is no method to provide, sell and deploy plug-ins for applications in the Mac App Store. You can argue that App Extensions can fill that functionality, and may even be more flexible than app-specific plug-ins, but they have certainly not been adopted on a large scale yet.

While macOS has improved how users discover and install drivers for printers, there is no way of managing driver deployment in the MDM spec. Administrators still have to deal with downloading and deploying printer driver installers and settings. The same is true for any other hardware driver software. While you can argue that the vendors sometimes seem to go out of their way to make driver deployment as complex as possible, even the best of them have no way of providing their software in the Mac App Store or manage it with an MDM.

This is but a short list of examples. I am certain any admin can easily list a many more. All of them have in common that Mac administrators need to use package installers and/or shell scripts to install and manage these solutions. Sometimes you can re-use the vendor installer, but even then you need to know how to inspect and verify these files. In many cases you have to reverse engineer the installation and re-build your own packages. (How to do all of this is covered in my book: “Packaging for Apple Administrators”)

As long as the Mac App Store has no manageable (VPP) solutions for upgrades, subscriptions and in-App-Purchases, it has to be considered broken for client management. Any such feature which gets added to the Mac App Store (such as subscriptions last year) have to have a VPP solution, otherwise it is useless for managed deployments.

The Mac App Store excludes entire categories of software because of the sandbox requirement, software providers. Users and admins still need a way to deploy that software. If Apple were to go ahead and lock down macOS completely, users and admins would have to either jailbreak their Macs, or abandon the Mac platform.

The number of users who would be affected by this is paltry, compared to the hundreds of millions of iOS devices Apple sells each year. So, the cynic will, “what does Apple care if a few hundred thousand users leave?”

A locked down macOS would provide little benefit over iOS running on an iPad Pro. A locked down MacBook may have more processing power (barely), and more ports for connecting hardware, but the software to use them to their full extent would simply not be available.

Apple wants to lock down macOS to make it more secure, because that distinguishes macOS from the other desktop systems. On the other hand, Apple has an interest in keeping macOS open because it is not iOS.

Apple has its own set of Mac applications that have no iOS counterpart: Xcode, Logic Pro X and Final Cut Pro. These are the ‘Pro’ apps, the lighter apps: GarageBand and iMovie have iOS counterparts. Swift Playgrounds which may be considered ‘Xcode lite’ is iOS only.

There are good reasons for each of these not being on iOS. Final Cut Pro and Logic Pro X rely very much on external hardware for input, most of which is not available for iOS. Xcode relies on integration with many command line tools (llvm, git, etc.) to develop its full potential. There may be some projects within Apple that can be built without shell scripts, but I am sure they are in the minority. Just look at the postinstall scripts of any Apple installer package.

Interesting Sidenote: Xcode, GarageBand and Logic Pro bypass the Mac App Store limitations by installing additional components at first run. Apple is hitting the limitations of their own rules. There is also no way of deploying these additional components with an MDM.

There are many people at Apple who use their Macs for graphic design, hardware design, running complex computations, writing shell scripts, compiling complex software and hardware drivers, and testing on virtual machines, etc. Do you believe Apple wants to buy them Dells so they can run Photoshop, bash, AutoCAD, SPSS, or VMware? Apple also needs to deploy and manage the Macs in their retail stores. They are, after all, one of the largest deployments of their own OS.

So, assuming Apple is not planning to lock down macOS like iOS, what are they going to do?

They certainly will continue to restrict access by users and processes to security critical parts of the OS. They also want to gain (more) control of vectors where malicious software can inject itself into the system. Apple obviously wants to use MDM as the main conduit for Macs to be managed. The MDM spec already has the ability to deploy an custom package to a client. This is probably supposed to push client agents for management systems for features not included in the MDM spec (such as reporting).

Apple, third party MDM vendors and open source MDMs could build on this existing feature to provide package installation of software for non-App Store solutions. This alone would alleviate many concerns that administrators currently have. Maybe the packages will have to be signed with an Apple developer certificate or some other extra security step. (Learn how sign packages in my book.) This will require major re-architecting of many tools such as Munki, but those are do-able, maybe even desirable. The format the MDM spec is using to install software is, not surprisingly, a flat package installation file, so packaging skills will be needed more, rather than less in this scenario.

From my perspective, Apple’s choices are to obsolete the Mac platform, or to gradually keep improving security and working on the Mac App Store, VPP, DEP and MDM as management solutions while maintaining the openness that makes the Mac such a powerful and creative tool.

While I believe that ‘pro’ users of the Mac platform need to get accustomed to the fact that they are not Apple’s main focus anymore, I also refuse to believe that Apple is planning to obsolete the Mac entirely, because they would hurt themselves in the process.

The balance between security and openness will not be easy to find. The openness is what sets the Mac platform apart from iOS. The control and security is what sets macOS apart from the other desktop operating systems. There will be much back and forth between the ‘pro’ users and Apple. We as admins have to keep harping and nagging at Apple to do the right thing. (File bugs!)