Restore hidden files from Time Machine

About backups

A working backup is like a stock of 10 billion masks waiting for a pandemic. You only use it when things go bad and since you never know when things go bad your backup needs to work flawlessly all the time.

Time Machine makes it extremely easy to restore anything that's on the backup disk to your machine. If you have not yet installed an external drive for your Time Machine backups, do it NOW. There is nothing more important than having a reliable backup of all your important files.

Time Machine has an optional setting (System Preferences > Time Machine > [Options...] button) where you decide what not to backup. Anything that is not there is basically copied to the Time Machine disk.

Hidden files are also hidden in Time Machine

This is not a Time Machine tutorial, so I'll stop here. But, what matters is that when you click on the "Enter Time Machine" menu item, macos shows a nice time based display of the contents of the current window, but it only shows what is visible. Not hidden files that are used in Unix applications as preference files and that are routinely created at the root of your home folder.

Yesterday I messed with one such file and since it was hidden, I could not restore it from the Time Machine display.

The easy way, for moderately experienced people

Time Machine can be accessed from the command line with the tmutil command.

$ man tmutil

TMUTIL(8)                 BSD System Manager's Manual                TMUTIL(8)

NAME
     tmutil -- Time Machine utility

SYNOPSIS
     tmutil verb [options]

DESCRIPTION
     tmutil provides methods of controlling and interacting with Time Machine,
     as well as examining and manipulating Time Machine backups.
     Common abilities include restoring data from backups, editing exclusions,
     and comparing backups.

The "verb" we're looking for is restore and its syntax is:

restore [-v] src ... dst
        Restore the item src, which is inside a snapshot, to the location dst.
        The dst argument mimics the destination path semantics of the cp tool.
        You may provide multiple source paths to restore. The last path
        argument must be a destination.

The src is where the restore date/time can be chosen since the backups have their own folders based on date/time.

So what I needed was:

$ tmutil restore /Time/Machine/path/to/.hidden.file ~/.hidden.file.test

I restored to a .test file just to make sure that really was the file I wanted.

The longer road, a half command-line, half GUI approach

Another solution is to make hidden files visible in Finder, start Time Machine, restore from the graphical interface and re-hide the files (they're hidden to avoid messing with them by accident).

There is no visible Finder setting that allows for that, so to get the job done one still has to use the command line to modify some non-GUI Finder setting from Terminal. This has been documented for years but I keep forgetting about it.

In Terminal, enter the following command:

$ defaults write com.apple.finder AppleShowAllFiles TRUE

What does all that mean ?

In Terminal, enter the following comment:

$ man defaults

To display the "defaults" command "man"ual. You should see:

DEFAULTS(1)               BSD General Commands Manual              DEFAULTS(1)

NAME
    defaults -- access the Mac OS X user defaults system

SYNOPSIS
    defaults [-currentHost | -host hostname] read [domain [key]]
    defaults [-currentHost | -host hostname] read-type domain key
    defaults [-currentHost | -host hostname] write domain { 'plist' | key 'value' }
    defaults [-currentHost | -host hostname] rename domain old_key new_key
    defaults [-currentHost | -host hostname] delete [domain [key]]
    defaults [-currentHost | -host hostname] { domains | find word | help }

(etc.)

Do you see the "defaults [-currentHost | -host hostname] write domain { 'plist' | key 'value' }" line ?

What that means is that the command syntax is:

defaults + optionally either "-currentHost" or "-host hostname" + write + the "domain" to which belongs the preference + a compulsory settings value.

In our case, the "domain" is "com.apple.finder", the "key" is "AppleShowAllFiles" and the "value" is "TRUE".

which means "Please, write down somewhere that Finder is now required to show all the files."

Next step

When you're done with your un-hiding hidden files, you can enter Time Machine, restore the file you want and then re-hide the hidden files with:

$ defaults write com.apple.finder AppleShowAllFiles FALSE

Et voilà !

Now, Finder doesn't know about that change of settings until you actually relaunch it. You can do that from Finder itself, or, since you're already in Terminal, you can do it from there by using the following command:

$ killall Finder

where "man killall" gives you:

KILLALL(1)                BSD General Commands Manual               KILLALL(1)

NAME
    killall -- kill processes by name
...

$ killall Finder

will actually kill and restart Finder.

To do the un-hidding and killalling in one fell swoop just tell Terminal that the two commands should be followed in order:

$ defaults write com.apple.finder AppleShowAllFiles TRUE; killall Finder

And the same for hidding them again when you're done with Time Machine:

$ defaults write com.apple.finder AppleShowAllFiles FALSE; killall Finder

Knowing about the command line is a must

Knowing about the command line and Terminal in a must. You can't pretend that system does not exist and trying to make sense of all that will drastically increase the amount of stuff you can do on your machine. There are plenty of tutorials on the web. One day I'll eventually write one for "us" translators, with commands that are relevant to our work...

Easily launch scripts from Spotlight

I've been advertising AppleScript a lot here. Automating a task is something, but easy access to that automation is quite important too.

Since I try to stick to Apple solutions and free software* I prefer using Spotlight instead of all the smart launchers that we have for macOS.

What I do is that I call my script names that are easy to call first in Spotlight. A few screenshots speak louder than words so here we are:

The series that start with ">" usually is scripts that I use to open something.

See how just typing ">" suggests ">BB". That ">BB" is what I use to open the files selected in Finder with BBEdit.

The one below is ">Tedit", short for "TextEdit" and opens selected files in TextEdit, etc.

If I type "c" after ">", I get the following list of choices. ">command" is to launch an arbitrary command in Terminal, ">Capture" is to use org capture in Emacs (see here and here for more information) and ">cd" just opens a Terminal tab on the front Finder window, or selected Finder folder.

When I use "<" to initiate the search, I get a different list. That series is for scripts that usually act by themselves. "<text file" creates a text file in the front Finder window and proposes to open it in BBEdit for editing, "<facturation" is an invoicing script for the job selected in Finder, "<job" is a job managing script that creates a job hierarchy in Finder based on a mail, along with an event in calendar, and then "<xls2tmx" is a TMX converter for multicolumn Excel reference data (I'll publish it when it's more polished, but creating XML data with AppleScript is documented here).

I have a few more scripts (a dozen) that I routinely call with Spotlight, which I find totally sufficient for my needs.

As you know, hitting Command+Enter when you have a selection in Spotlight is a way to reveal that selection in the Finder if it is available. So when I want to edit a script, I start by calling it in Spotlight, I hit Command+Enter when it is selected and then I call ">SEditor" (Script Editor) or ">debugger" (Script Debugger) on the selection, to open it with the appropriate application...


* Ok, I do have BBEdit, Microsoft Office and Illustrator... And maybe a few others...

From Finder to Terminal: cd anywhere

At a point in a Mac user life, the Terminal utility and all the command line applications that it brings to the game become a daily necessity. Typically, you work in a Finder window and want to work on the window items from the command line. For that, you can go up to the parent window, select the folder that you just exited and copy it, move to terminal, hit "cd", add a space, paste the folder and hit "Enter". That's a lot of fiddling around.


I just checked and found that I needed about 10 seconds to complete the task. 10 seconds, 4 times a day, 5 times a week, 40 times a year and you've lost 8,000 seconds = more than 2 hours. Eventually you'll notice that you're wasting time on this particular task and you end up either cursing yourself that you can't go faster, or start looking for a solution.
Here is my take on the problem.
On a side note, I spent way more than 2 hours to find that solution (and all the solutions that I write about here). Namely, I had to learn enough AppleScript, then I applied that knowledge to Finder and Terminal, then I found all the issues that made this a non trivial task, then I asked around (eternal thanks to the members of the AppleScript Users list hosted by Apple), then I tried a new implementation, then I was not satisfied with it, rewrote the whole thing and that's where I stand today. But the time spent on learning AppleScript and the workings of the various applications translates into knowledge (along with its own lot of frustration) that I can apply to other issues, while not spending that time only translates in frustration and a sense that you can't do much with computers...

use AppleScript version "2.4" -- Yosemite (10.10) or later

use scripting additions

tell application "Finder"

activate

try # if what is selected in Finder is a folder, then use that folder

if class of item 1 of (selection as list) is folder then

set myFolder to item 1 of (selection as alias list)

else # if nothing is selected or if the selection is not a folder, use the parent folder

set myFolder to insertion location as alias

end if

on error # if nothing works, default to using the Desktop

set myFolder to desktop as alias

end try

set myPath to quoted form of (POSIX path of myFolder)

set myCommand to "cd " & myPath

end tell

# I use a separate "handler" to launch the command.

# That handler can be saved in a script library so as to be able to call it from other scripts

my launchMyCommand(myCommand)

# A handler is useful because what matters is what it outputs, not how it works.

# So, if at one point in the future I decide that this way of launching a command in Terminal is not efficient anymore, I can change the way the handler works but I won't have to change the scripts that call it.

on launchMyCommand(myCommand)

# First I use GUI scripting to create a new Terminal window

tell application "Terminal" to activate

tell application "System Events" to tell application process "Terminal"

set frontmost to true

delay 0.1

keystroke "n" using {command down}

end tell

# Then I ask the newly created window to run the command

tell application "Terminal"'s front window

delay 0.1

do script myCommand in its last tab

activate

end tell

# And I eventually merge that window to the other so as to keep everything tidy

tell application "System Events" to tell application process "Terminal"

set frontmost to true

delay 0.1

keystroke "m" using {control down, command down}

end tell

return

end launchMyCommand

I save this script as an AppleScript application and I call it ">cd". Now when I am working in Finder, I just call Spotlight with a system shortcut, I start hitting >c and Spotlight autocompletion proposes >cd.app, I hit Enter and I'm in Terminal with a window opened on the item I wanted.

Applescript everywhere

Artificial languages are no different from natural languages. Either you're fluent and you will have fewer problems doing what you want to do, or you're not, and you're going to spend a lot of time on trivial issues that don't seem to make much sense.

I was in the middle of writing a very optimistic article on how automating your tasks could greatly enhance your workflow and your life in general, and how automation on Mac generally meant "Applescript" when I stumbled on some of those issues when trying to work with Terminal.

I will finish the article because computers are automation systems and using them without trying to automate more than what's provided by bundled programs means letting programs govern the way we work. But that episode painfully reminded me how non-trivial it was for me to work in Applescript, even though I am not exactly a beginner anymore, which does not mean that I know much, just that I know where to look for information when I don't know, and that I can more or less make sense of what I find.

With Applescript, I never read the "manual". I started with online examples, I copy pasted a lot, modified a few scripts, checked the errors, modified again until I got where I wanted, and checked the official reference only rarely (only 333 pages for the PDF I have, but still). And I'm saying to myself, now that I can sort of see how things fall in place, that I should definitely spare some time to go through either the reference or one of the excellent books that are out there.

If Applescript is a language, you're most likely going to use one of its "dialects" too, since any application that supports Applescript actually has a list of words that are specific to it and if the words look the same between applications, they are, like we say in French about some English words "false friends". They look the same but don't always mean the same. Applescript is not a language that you will use to make heavy-duty computations (although you could). Applescript was made to work with "Apple Events", which are used to connect applications together. As you'll eventually read in that other article, one of my script creates a Finder group of folders based on a job request I received in Mail that will end up as a Calendar item.

Applications that don't support Applescript can also be talked to: think about the primitive sign language that we use when we don't know a language. But that can be pretty powerful because just as you can show a person how to click the button that will move a robot, you can also tell Applescript to click on any button or menu item of pretty much any application that runs on a Mac. In fact, some parts of Applescript supporting applications are only available through their user interface, for example, asking a Terminal window to enter full-screen mode requires an Applescript that says "click on such menu item of such menu bar" or even better "hit F while pressing Command and Control" to simulate the shortcut. That's the part that bit me last weekend when I was trying to create a tabbed full-screen window in Terminal opened on the folder that was selected in Finder.

And Applescript can also call the services that are hidden under your Mac's hood: the command line applications that you can usually only access through Terminal, and reciprocally, you can call Applescript from the Terminal. I do that when I select an OmegaT project folder in Finder and use Applescript to tell the command line to use that folder as a parameter to launch OmegaT.

All this is very powerful but can be pretty daunting for amateurs. In my next article, I'll try to show you how I got where I'm at today, which is, in all honesty, not very far ahead of any person who's reading about Applescript today for the first time. I'll publish the Applescript code I'm using, with extensive comments, so that you don't have to just blindingly take for granted what I wrote but get to understand why I wrote it that way. And hopefully that will help you being more productive while working on your Mac.

Update (a few minutes after posting):
I clicked on the "Applescript" tag that's in the column on the right side of the articles, which brought me back to November 2007 when I wrote "I have never found a practical way to use AppleScript in my workflows..." Well, things have changed and now I'm pretty sure I could not live without Applescript on my machine...

Okapi tools on OSX...

In my "Okapi tools for Mono" post, last November, I discussed the possibility to use Okapi on OSX without installing Parallels/VMWare/WhateverVirtualSolutionYouPrefer and Windows and .NET... Which in the end makes Okapi a very expensive free tool...

Okapi has recently been released to work on Mono, the free (as a bird) version of .NET and I've promised myself to install everything and try the package as soon as I'd have a job requiring it.

This job has come. At last. It is a small set of InDesign files (that will eventually end up being Illustrator files) that are part of a much bigger translation package...

So, at the time of writing, here is the procedure you need to follow to get everything to work:

(Beware, Okapi for mono does not come with a graphical interface and everything must be done in the Terminal, at the command line. It is not terribly hard but not super trivial either for the translator who is not used to that. For people who need an introduction to working with the Terminal on OSX, check this link.)

1. Download Mono (1.2.6 at the time of the post):
   
   http://www.go-mono.com/mono-downloads/download.html


2. Install it by clicking on the package file and following the instructions.


3. Download Okapi for Mono (R00020 at the time of the post):
   
   http://sourceforge.net/project/showfiles.php?group_id=42949
   


4. Unzip/untar the package and read the ReadMe_ForMono.htm file found in the Tikal folder


5. Do what the file says under "Using the Okapi tools"
   
   (for some reason, I am yet unable to properly set the path to Okapi...)

When this is done, you'll need to take a look at the Mono for OSX page to know how to use the beast.

Basically, it comes down to opening the Terminal and typing:

$ mono ~/bin/OkapiMono/Tikal/Tikal.exe

Here, I've left my path to Tikal because I could not set it properly in the install step. But a proper install should accept:

$ mono Tikal.exe

Running only Tikal.exe without any arguments will have the application display its basic help where you'll see what you need to type to do a few basic things, like:

$ mono Tikal.exe -lf
to list the available filters.

Just for your information, since you can find that on the Okapi help pages too, here are the filters that are directly available from the Mono command line:

• okf_po (Okapi PO Filter)


• okf_properties (Okapi Properties Filter)


• okf_script (Okapi Script Filter)


• okf_netres (Okapi NETRes Filter)


• okf_rc (Okapi RC Filter)


• okf_xml (Okapi XML Filter)


• okf_wordfast (Okapi Wordfast Filter)


• okf_tradostext (Okapi Trados Text Filter)


• okf_illustrator (Okapi Illustrator Filter)


• okf_table (Okapi Table Filter)


• okf_inx (Okapi INX Filter)


• okf_html (Okapi HTML Filter (ALPHA TEST ONLY)
)

• okf_json (Okapi JSON Filter)

If you use the parameter -lu you'll get a list of available utilities:

• oku_set01:extraction


• oku_set01:merging


• oku_set01:rewriting


• oku_set01:encodingconversion


• oku_set01:lbconversion


• oku_set01:bomconversion


• oku_set02:qualitycheck


• oku_set02:update


• oku_set02:rtfconversion


• oku_set02:xsltransformation


• oku_set02:twbanalysis


• oku_set02:rtfsplitting


• oku_set02:alignment


• oku_set02:rtftotmx


• oku_set03:alignment


• oku_set04:dnllistedit


• oku_set04:xliffsplitting


• oku_set04:xliffconcatenation


• oku_set04:tmxsplittingdup


• oku_set04:xliffconversion


• oku_set04:proofreading


• oku_set04:searchandreplace


• oku_set04:uriconversion


• oku_set04:cdataconversion


• oku_set04:xmlpruning


• oku_set04:ttx2tmx


• oku_set04:xmlpartitioning

All the filters and utilities etc require specific parameters to run. Check the Okapi for Mono manual that comes with the download to know how to use all that.

Don't forget that Okapi has a very nice user group managed by Yves Savourel, the developer. It is possible to access the archives without having to subscribe to it.

Et voilà ! That is pretty much everything you need to know to get started... I hope that helped !