applescript: make your own battery health meter

main
A couple of weeks ago, I posted about how to extract numbers from strings. That led one reader to wonder what use they could make of such a handler. That sounded like an invitation for a little AppleScript tutorial, so in this post we’re going to build our own, colourful and highly useful battery health meter. In the process we’ll not only use the numbersInString handler I posted last time, but learn how to make our AppleScript displays a little more colourful by adding images, and we’ll take a quick look at some very useful Bash utilities that will do some of the heavy lifting for our little app. So, open up your AppleScript editor and let’s get started!

Step 1. Grab the returnNumbersInString(inputString) handler I posted here, and paste the code into a new, blank AppleScript editor window. Hit ‘cmd-K’ to turn it into ‘pretty text’ and check that it compiles OK.

Step 2. Underneath that, hit return a couple of times to create some white space, and define a new handler like this:

on powerstats()
set iconAC to ""
display dialog iconAC & "Power Source: " with icon 1
end powerstats

Hit ‘Cmd-K’ again to compile, then underneath our new powerstats handler, hit return to make some space again and type

powerstats()

Hit ‘cmd-R’ this time, which will build and run our code at the same time, and you should get the nice if not terribly useful result as so:

icon1

Believe it or not, that’s all it takes to get the core of our app, and all that remains now is to fill out the powerstats() handler and the display dialog command with the details.

Step 3: You might have been wondering what that ‘iconAC’ variable at the beginning of the display dialog command was doing, since all we did was set it to an empty string with “”. That was a placeholder. Let’s put something in it.

First, place the cursor between the two quote marks in the line that reads

set iconAC to ""

Now, either use the keyboard shortcut control+command+spacebar, or open the Character Viewer from the Keyboard menu bar (check the System Preferences > Keyboard | Keyboard: Show Keyboard & Character Viewers in menu bar item if necessary). Pick an image you like to represent AC Power. You can find the same image as I used by typing plug in the search/filter bar, but feel free to choose any image you like.

When you find the image you want, double-click it, and you should see it inserted between the quotation marks in your AppleScript. With the cursor placed immediately after the plug character but before the final quotation mark, hit the space bar three times. That’ll position it just nicely with our ‘Power Source:’ text:

icon2

OK, we’re going to set the other images we need in the same way. So, now place the cursor after the quote marks on the ‘set iconAC ‘ line, and hit return to create a space between that line and the display dialog line.

Now add the following lines, but do not include the words in orange like #battery after each set of quote marks. I’ve included those here just as search tips to help you find appropriate characters in the Character Viewer. As before, put the cursor between each set of quote marks and use the suggested orange words to find the images. Of course, you can use any image you like, but don’t forget to add the three spaces after the ASCII image.

set iconBatt to ""    #battery
set iconCharge to ""    #voltage
set iconTime to ""    #clock
set iconHealth to ""    #clover
set iconCycles to ""    #cyclone
set iconWarning to ""    #warning

Now we’re going to update our Display Dialog command so that we get the images at the beginning of a new line. We do that by adding

& return &

between each variable. Also, we don’t need all the images (iconBatt and iconAC are alternatives, and the warning sign appears elsewhere), so we’ll just add the ones we know will always be displayed. Finally, we’ll add an extra

return &

between iconTime and iconHealth to create some space. Update your Display Dialog command so that it now looks like this:

display dialog iconAC & "Power Source: " & return & iconCharge & return & iconTime & return & return & iconHealth & return & iconCycles with icon 1

When you hit ‘cmd-R’ it should now give you this:

iconsAll

Step 4: Ok, we’re done with the images, but not quite with the Display Dialog command. We need some more static text in there, so edit the command to look like the following:

display dialog iconAC & "Power Source: " & return & iconCharge & "Current Charge: " & return & iconTime & return & return & iconHealth & "Battery Health: " & return & iconCycles & "Cycles: " with icon 1

Be careful to ensure you close every quote and add an ampersand between every term and every return, or your code won’t compile correctly. Feel free to cut and paste it from above if necessary, but you should now have something like this:

add static text

This is all the ‘static text’ — text that will appear every time we run the script. As you can see, there’s some parts missing, as they will need to be added depending on the state of our battery.

Step 5: Coding time! We need to get our data for the battery before we can do much else, and for that we’re going to use a couple of unix utilities. Rather than messing around in Terminal, though, we’re going to let AppleScript manage them for us using the ‘do shell script’ command. First, we’ll ask pmset for a load of information about the machines power management settings, then we’ll ask grep to narrow it down to just the bits we’re interested in. To do all that, we’ll add the following short but powerful command to our powerstats() handler. Place the cursor on a new line after all the set icon commands, but before the Display Dialog command. Then type the following:

do shell script "pmset -g everything | grep Cycles"

Now run the script again and hit the “OK” button. The dialog will look the same as before, but this time we’re interested in what is in the ‘Replies’ (not ‘Result’) panel in the lower half of the AppleScript editor:

pmset

Note you won’t see this until after you hit the “OK” button on the dialog panel. What we need to do now is capture this result in a variable so that we can start extracting some of those useful numbers, so immediately underneath this line, add:

set x to the result

set x to the result

Step 6: In order to understand what follows, temporarily add the following two log lines:

log word 1 of x

Now run the script. Run it once with the power supply connected, then again with the machine running on battery power and compare the output in the ‘Replies’ field after you’ve hit the “OK” button.

The output of the log lines is shown in the Replies field between

(* *)

and they tell you the values of the variables. “Word 1″ is the first text item in the result (exactly what delimits text items in a script depends on a built-in AppleScript variable called text item delimiters, which you can read about here).

If the AC Power is connected, word 1 should be “AC”, otherwise, it should be “No”. Similarly, word 2 should be either “charging” or “not” (sometimes the battery doesn’t charge due to a poor connection or if its more than 95% full). If AC is not connected, Word 2 should be “AC” (Word 1 and 2 together, in this case read “No AC”). However, different macs may have different power management options, so do some tests and check that you get the same results. If you don’t, you’ll need to experiment logging different words to find out which words correspond to my ‘word 1′ and word 2′. Here’s a summary again of the word numbers you need to determine for each of the values, with those on my machine given in brackets:

AC connected: word (1)? = “AC”; word (2)? = “charging” or “Not”
On battery power: word (1)? = “No”; word (2)? = “AC”

If your machine gave different results, make a note of which word number corresponds to my word 1 and word 2, and wherever I mention ‘word 1′ and ‘word 2′ in the scripting below, substitute those for the correct word numbers you found in your tests.

That these words always appear in the same position on the same machine is a very handy fact that makes it easy for us to determine whether the mac is running on battery or mains power, and in the latter case whether the battery is charging or not.

In the next step we’ll now put this information to good use in our script. First, however, remove all the log messages from the script.

Step 7: It’s time to add some more code to our powerstats() handler. Add this conditional test to your script, remembering to substitute any differences in word number you found in your logging tests:

iconWarning

This code assumes the AC is connected and sets the variable ‘charger’ to display whether the battery is charging or not. However, we need to set that variable to an empty string if the mac is running on battery power, so immediately underneath add another conditional:

pwrsource

In the Display Dialog command, replace iconAC with pwrSource as indicated in the image above. This will allow the Display to change the image accordingly. At this point, compile and test your script, both with the power supply connected and disconnected, ensuring that the icon changes accordingly.

If that’s working as expected, add the variable _t to the Display Dialog command immediately after the iconTime variable. Don’t forget to add another ampersand along with it as shown:

_t
Again, compile and test your script, both on battery and AC Power.

Step 8: Time to do some math. You may remember we started the script by adding the returnNumbersInString(inputString) method, and now it’s time to use it. We want to extract all those numbers returned by the do shell script command, and currently stored as a text string in our variable, x. We’re going to need some of them as numbers because we’re going to perform some math on them to get the battery percentage health.

Start by adding the following line, which calls the handler and gets the numbers back as a list of integers:

numbersInString
Item 1 of nums should be the battery’s current charge. Test this by adding a temporary log statement immediately after the set nums line:

log "item 1 of nums is " & item 1 of nums

Run the script, hit “OK”, and examine the Replies panel. Compare the output of the do shell script statements, and it should be clear whether you’ve got back the battery percentage or not. If not, continue logging till you hit the right item number. I’m going to assume that you got item 1 (if you didn’t, replace my mention of ‘item 1′ with whatever yours was in the following lines), so let’s remove the log statement, and replace it with this:

set percentage to item 1 of nums & "%".

Now, down in the Display Dialog command, add the variable ‘percentage’ and another ampersand in the place shown:

Screen Shot 2014-08-25 at 21.24.08
Run the script and hopefully you should now see that your battery percentage is correctly shown:

show battery percentage
Looking at the display reveals we haven’t added in the Power Source variables to the Display Dialog which we defined earlier, so do that now:

pwr & charger

Step 9: The next step is to add the time, but this is tricky on several counts. First, if you examine the number returned by do shell script in the Replies panel, you’ll note the hours and minutes are colon-separated. As far as our list is concerned, that makes them two different items, so we have to get the hours and minutes separately (items 5 & 6 on my machine; use logging to check what they are on yours).

Secondly, if the minutes are between “00” and “09”, AppleScript will just return a single-digit between 1-9, cutting of the “0”. That’ll mean we’ll end up with a weird display for say “1:05″ as “1:5″. To counter that, we’ll have to test whether the minutes is less than 10 and add a “0” back in to the string if so. Also, we’ll have to add “hr”, “hrs” or “mins” depending on how much time is remaining or left to fill the charge.

As if that wasn’t enough, there’s a problem with the power manager: if you use Apple’s battery/power icon in the menu bar, you’ll notice that if you click on it straight after changing the power source, you’ll get a “Calculating Time till Full” or “Calculating Time Remaining…” message. That’s because it takes a minute or so for the power manager to update. The menu bar icon will update live, but we don’t have that luxury. Instead, we’ll add a warning later to alert users to this and ask them to run the script again after a short delay.

Woah. That’s a lot of conditions, so here goes. Add the following immediately above the Display Dialog command:

if item 5 of nums = 0 then
set hrmins to " mins"
else if item 5 of nums = 1 then
set hrmins to " hr"
else
set hrmins to " hrs"
end if
if item 5 of nums is greater than 4 then

if pwr is "AC" then
set t to "Calculating...try refresh in 2 mins"

end if

else
if item 6 of nums is less than 10 then
set theMins to item 6 of nums as string
set theMins to "0" & theMins as string
else
set theMins to item 6 of nums as integer
end if
set t to item 5 of nums & ":" & theMins & hrmins
end if

And for all that code, we only need to add one variable and an ampersand to our Display Dialog:

Step 9 v2


There is one remaining problem, which is that if you run the script immediately after changing the power source, although the message “Time to Full” or “Time Remaining” will change, the time itself may not. This is for the reason stated earlier: its inherent to the way the power manager works. We’ll do our best to help the user by adding a Refresh button later, but otherwise this is a shortcoming we’ll have to live with.

Step 10: It’s now time to get down to the real point of this script, which is to tell the user something that the battery meter in the status bar does not: the battery health and the battery cycles. The number of charge cycles the battery has been through is, naturally, given by the ‘Cycles’ figure. Battery health, however, is not data outputted natively by the power manager. Rather, it is a percentage of the Battery’s design capacity and its current ‘fully charged capacity’ or FCC. As you might expect, these two figures are represented in the do shell script output by “Design” and “FCC”, and it is largely because we need to do a mathematical operation on these that we needed the numbersInString handler.

To figure out the Battery health, we’ll divide the Design capacity by 100 to obtain 1%, then divide the FCC by this number to figure out how many percent it is of the Design capacity. That bit of math is represented by the function FCC/(design/100). In order to avoid a whole load of decimal places, we’ll also use AppleScript’s built-in round() handler to return a whole number. Finally, we’ll add the “%” sign to the string and add the ‘battHealth’ variable to the ‘Display Dialog’ command.

Here’s the code to be added, again after the last line and before the Display Dialog command (reminder: don’t forget to check using the logging technique I showed earlier that your item numbers are the same as mine, and to substitute your own for mine if they are different):

set FCC to item 3 of nums as integer
set designCap to item 4 of nums as integer
set battHealth to (FCC/(designCap/100))
set battHealth to round(battHealth)
set battHealth to battHealth & "%"

battHealth

Don’t forget to add the battHealth and ampersand to the Display Dialog, as shown above.

Step 11: Almost there. Let’s add the Cycles, which is fortunately a simple one liner:

Cycles
Does that say minus 3? Yes indeed it does! A little trick with AppleScript lists and strings is that you can count items backwards from the end using the minus sign,where -1 is the last item, -2 the item before it and so on (I thought I’d just throw that in as an extra since this command was so straightforward!). As always, check the position by using logging in your own script.

Step 12: If you run your script now you should find it’s complete. To wrap up, we want to go back to where we started, and that’s improving the look and functionality of our Display Dialog box. The first thing to do is fix the buttons. We don’t need a “Cancel” button, since the “OK” button does the job of dismissing the script, but we would like a “Refresh” button, so the user can run the script again from the dialog box. To add the the buttons, change the Display Dialog command and add a conditional statement after (not before this time) it. We’re also going to add a title for the box while we’re at it:

refresh button

final

Step 13: Your script is done, but to really finish it off, we should turn it into an app that we can run off the Dock, and to which we can add a custom icon. To create an app, choose “File > Export” and change the File Format to App. Give your script a name like “batteryPowerStat” and save it in your Applications folder.

Step 14: All you need now is an icon. You can either make your own, or you can download mine. Once you have an icns file, change its name to ‘applet.icns’ and add it to the Application bundle. To do that, control-click on your new app in the Finder, and choose ‘Show Package Contents’. Navigate to Contents > Resources, delete the file that currently exists there called ‘applet.icns’ and replace it with your custom icon.

You may need to log out and log in again before OS X flushes the old file from its memory and displays your new one.

Step 15: Only kidding! There is no step 15. :D I just wanted to stay “Congratulations”. If you made it this far, I hope you picked up a few AppleScript tricks along the way to creating your own battery health meter. If you need the complete code, you can find it on my Pastebin site here.

Enjoy! :)

FastTasks 2 update available 💥

I’ve just released an incremental update for FastTasks 2. Update 1.3 adds the ability to quickly see whether TRIM is currently on  or off for your SSD disks. Since TRIM support for non-Apple SSDs requires editing a kernel extension, TRIM is regularly disabled on non-Apple SSDs every time users update or upgrade OS X. FastTasks 2 v1.3 now lets you see TRIM status in the information section of the menu.

FastTasks 2 Trim

Get the latest release of FastTasks 2 by going directly to the FastTasks support page, or if you already have FastTasks 2 running, you can use the Preferences > Check for Update > Check now menu item. :)


UITableView doesn’t immediately reload data

awakeFromNib
Here’s a little problem and solution I ran into the other day while using UITableView. I wanted to have a master-detail set up in which the UITableView was segued to after an initial home screen.

The problem occurred whenever I added or deleted something in the UITableView, segued back to the home page and then returned to the table view. Sometimes the table would not update. Going out and back into the view a second time, however, would finally reload my data and show me the changes. Why was my app needing to load the view twice before the table would show any changes?

Logging showed me that something even weirder was going on: Every time I segued into the table view, the viewDidLoad method was being called not once, but twice. So basically, to get my updated data to show, I was actually calling viewDidLoad four times!

I worked through a whole bunch of stackexchange posts related to various problems and solutions with the reloadData method — adding delays, removing it from any edit- or insert- methods and so on, calling it on the main thread — but the problem stubbornly remained.

Then I noticed something else. In my awakeFromNib method, the call to super had somehow got pushed to the end of the method, after a bunch of other set up calls. I’m not sure how it got there, but I did remember seeing a WWDC 2014 Swift video pointing out that one difference between Objective-C and Swift was that calls to super need to be made after doing any initial set up in Swift’s case, but before for Objective-C. Since this was an Obj-C project, what was my call to super doing at the end of the method?

And as if by magic, moving [super awakeFromNib] to the beginning of my awakeFromNib method resulted in viewDidLoad only being called once, and my table view updating correctly.

Though I found quite a few threads with people having a similar problem with UITableView’s needing two calls before updating, I haven’t come across this particular solution to (or cause of) the problem. Hopefully, this post will save someone else a few hours of head scratching!

AppleScript: how to extract numbers from a string

Here’s a little handler I wrote in response to a query over on ASC, that will return all the numbers in a string of text. This could be really handy for all sorts of tasks, like extracting data from a text document in order to import the data into a spreadsheet or indexing page numbers from InDesign or Quark, for instance.

Here’s the handler:


on returnNumbersInString(inputString)
	set s to quoted form of inputString
	do shell script "sed s/[a-zA-Z\\']//g <<< " & s
	set dx to the result
	set numlist to {}
	repeat with i from 1 to count of words in dx
		set this_item to word i of dx
		try
			set this_item to this_item as number
			set the end of numlist to this_item
		end try
	end repeat
	return numlist
end returnNumbersInString

To use it , place the handler somewhere in your script (handlers usually go at the beginning or end of your script, but it’s up you; AppleScript doesn’t care where you put them!). Then call it like so:

set theNums to returnNumbersInString(“put your string with some numbers like $45.12, 20%, 12 months, and other assorted data here, or use a variable that points to your text “)



The handler does the work, and sets theNums to a list containing all the numbers in your text. In the example, you’ll see the result as {45.12, 20, 12}.

After that, you’re free to sort them or send them to another app or do whatever your script wants to do with numbers. :)





how to easily encrypt your files

EncryptMe

Keep the spooks and data thieves out of your personal data with this easy-to-use, drag-and-drop 128-bit AES encryption applet. It’s a simple 1-2-3 process:

 

1. Download EncryptMe, copy to your Applications folder and drag the icon to your Dock.

Download link…📀
Encrypt Me (small)

 





2. Select the files you want to encrypt and drop them onto EncryptMe’s Dock icon.

Add files


3. Choose a password and you’re done!

password

That’s really all there is to it, but let’s take a moment to go over the details of Step 2 and 3.

 

How does it all work?

First of all, note that EncryptMe is an Automator “droplet” app. That means you use it by dropping files on it, not by clicking or double-clicking the icon (which will just produce an error message). If you want to know how EncryptMe works (or make your own), just open up Automator.app and take a look a the ‘New Disk Image’ action. EncryptMe sizes the disk image to fit the files you drop on its icon as long as you have enough free space on your drive.

automator action

Secondly, take a moment to pause and think about the password options. You can use OS X’s built-in password generator or make one up of your own. However, be careful. This encryption won’t just keep the bad guys out; it’ll keep you out too if you forget the password!

For that reason, you’ll need to think carefully about whether you’re going to tick the ‘Remember password in my Keychain‘ checkbox or not. Doing so gives you far more insurance against losing the password. The flipside is that anyone will be able to access your encrypted files if they gain access to your computer while you’re logged in. Leaving the box unchecked is more secure: the password you set here will have to be supplied every time an attempt to open the files is made even when you’re logged in. The bad news? Forget the password, and you’ll be in the same boat as the spooks and the data thieves, locked out of your data forever. So choose carefully here.

pwd generator





Xcode: adding source control

source control main


If you’re not yet using source control with your Xcode projects, it’s something you want to seriously consider before a project you’re working on hits serious trouble. Setting up source control is easy when you create a new project (just tick the box in the project set up window), but figuring out how to add it to projects you’ve already created is a bit more challenging. In this post we’ll look at the ‘why’ and the ‘how’ of adding source control to an existing project.



Why?
In most normal applications, ‘Command-S’, Versions, Time Machine or other back up will save your hide when you either lose a document or realise a whole bunch of recent changes are something of a disaster. Recovering or reverting a document are mechanisms Apple has put a lot of time and effort into since Lion first appeared (changes I haven’t always been a fan of…).

However, these mechanisms do not work well with Xcode due to the complex and deep links between files in an Xcode build. If you’ve ever tried to go back to an earlier version of an Xcode project or undo some change from last week, and ended up with a headache, you’ll know what I’m talking about.

That’s what snapshots are for, you say? Yes, maybe. When they work. But in my experience snapshots themselves get lost, corrupted, or simply fail to restore.

Moreover, source control has other benefits aside from recovery and reversion that neither snapshots or any other mechanism provide. It’s primary purpose is to allow you to develop parallel but different versions of your project at the same time (a process known as ‘forking’). What if you want to experiment with adding some new feature, but don’t want to risk making changes right across your code that would be needed to try it out? What if you want to create one version of your project for one set of users and another one for others, or one version for an earlier OS X iteration and another for the current release?



How?
Let’s get down to the nitty gritty. Let’s assume you’re convinced you want to add source control to your current project. The first thing you’ll need to do is install git if you haven’t already. If you’re not sure, open Terminal and enter

git --version

If you get back a version number, continue on to the next step. If not, you’ll need to install git first. Follow the instructions for doing that here and then return to this post.

Once git is installed, here’s the steps for adding source control to your existing repository:

1. Locate the project folder
Select the project in the sidebar on the right, and click the little ‘Open in Finder’ arrow on the right.

locate parent folderl

Once you’ve got the parent folder open in ‘Finder’, quit Xcode.


2. Open Terminal and switch to the project’s parent folder
Click on the project’s parent folder icon in Finder and drag it to a Terminal.app window. Hit ‘control-A’ on your keyboard to move the cursor to the beginning of the line and type ‘cd’. Press ‘return’ to complete the command.

I always like to do a quick ‘ls’ to double check I’m in the folder I think I am, and that it contains what I think it does.

terminal 3


3. Initialize, Add, & Commit
Next, we’re going to hit a series of Terminal commands, one after the other. Press ‘return’ on your keyboard after each one:

git init
git add .
git commit -m "Initial commit"

Notice that there’s a period after a space on the end of the second command. Don’t forget to include it.


4. Confirm your local repository
Reopen Xcode, and hit the ‘Source Control’ menu. You should now see the options are active.

source control menu


Congratulations! You just added a local repository to your project. You can now go ahead and start creating branches (‘forking’) by choosing the Source Control > master > menu item.

You’ll notice that when you make changes in your Xcode project, an ‘M’ (‘modified) will appear next to the files that have been changed. When you’re happy that these are changes that you’re going to keep, use Source Control > Commit. Full documentation on how to use the various features of source control are available in Xcode’s documentation.


5. Add a remote repository
Local repositories are great, and may be enough for your needs, but for ultimate protection (such as against disk loss or failure), you might want to add remote back up. To do that, you’ll need an account with a service like GitHub or Bitbucket. My own personal preference is Bitbucket, largely because they allow you to have private repositories on a free account. Steps for adding your existing project to a remote repository can be found on your chosen service’s website.





how to remove Google’s secret update software from your mac

don'tbeevil

If you’ve ever downloaded Chrome, even for just a trial (guilty!), you might not be aware that Google have slipped a little bit of hidden software into your Library.

This software is called Google Updater, and it secretly “calls home” on a regular basis and downloads updates to your Google software without either asking before, or notifying you after, doing so. In Developer circles, this is considered very shady practice. Users should be asked for consent and informed when software makes changes to either itself or the user’s computer, and ideally those notifications should tell the user what has been changed and how the changes could impact them.

Before I beat this drum any harder, however, I owe you at least the other side of the story. If I worked for Google, I’d probably come up with this response: “Hey look, a major source of computer virus and malware infections is that users are often using out-of-date software that hasn’t been patched to combat newly-discovered exploits. No matter how much we tell users to keep ther software up-to-date, the truth is the majority don’t. We provide an automatic updater so that users don’t have to worry about it, and can be assured they’re always using the latest and safest version of our software”.

I’ve heard this argument so many times, I don’t doubt it’s something close to what Google would actually argue. My problem with this is that while automatic updates can be a good thing if they’re security related, it’s not at all clear why an app should be updating itself automatically for any other reason, or why it’s updating itself without providing notifications about when and what updates were made.

If an independent developer did that, they’d almost certainly find their software labelled as “suspicious” at best, and “dangerous” at worst. The fact that Google is a multinational, global enterprise with a stranglehold on the internet, and which is often tangling with the law in countries throughout the world, may make you feel more or less confident that they can be trusted more than independent developers, whose income depends very much on their reputation. I’ll leave that one for the reader to decide. ;)



Do I have Google Updater?
To see if you’ve got Google Updater hiding on your system, try this quick test in Terminal. Triple click the line of code below to highlight it.

defaults read com.google.Keystone.Agent

If you’ve previously installed my Terminal workflow, just hit control-opt-cmd-T or right/control click and choose “Services > Run in Terminal” from the contextual menu. Elsewise, manually copy and paste it into a Terminal window.

If the result comes back as

Domain com.google.Keystone.Agent does not exist

you’re fine. Google Updater has not found its way into your system. Anything else and you’re going to need to decide whether you want to remove it or not. If you’re a regular Chrome user, keeping Updater might prove convenient, though you’ll have to live with the idea that the app is updating itself in ways over which you have no control. If you rarely or never use Chrome, there’s no reason to have this hidden process regularly calling home to Google every time you’re connected to the net.



How do I remove it?
You have two options. You can either disarm it or you can nuke it. Disarming it is simplest, it’s a one-line Terminal command:

defaults write com.google.Keystone.Agent checkInterval 0

This command tells the Updater how often to “call home”. A value of 0 basically means ‘never’. Disarming it is probably better than nuking it if you still keep Chrome on your system and use it occasionally. You can temporarily set it back to something like ‘once a week’ from time to time to check for security updates with

defaults write com.google.Keystone.Agent checkInterval 604800

Nuking the Google Updater is a bit more complex. You’ll want to run some uninstaller commands, and then you’ll want to go and clear up the crud that is still left behind. And before you can do either of those, you need to find out where it’s hiding. So, we have a three-step process.

1. Locate Google Updater
Triple click the first of these two lines, and choose ‘Services > Reveal in Finder’ from the contextual menu (that’s another right-click or control-click on the selected line), and then repeat for the second line:

~/Library/Google
/Library/Google

You will likely get the error message “The operation can’t be completed because the item can’t be found” from one of these lines, but not the other. Note that the difference is all in the presence or absence of the tilde ~. Make a note of which one worked, and run the appropriate commands in step 2.

2. Run the uninstaller commands
Run these in Terminal (again, triple clicking to highlight and doing the usual trick afterwards with shortcut key or Services menu if you have my workflow installed), one at a time:

If the Updater was in your user library (with the tilde ~), then first do this (it’s all one line):

python ~/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/\
Contents/Resources/GoogleSoftwareUpdateAgent.app/Contents/Resources/\
install.py --uninstall

then this:

touch ~/Library/Google/GoogleSoftwareUpdate

If the Updater was in your domain library (no tilde ~), then first do this (it’s all one line):

sudo python /Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/\
Contents/Resources/GoogleSoftwareUpdateAgent.app/Contents/Resources/\
install.py --uninstall

and enter your Admin password (note that you won’t see any indication of your password being typed in the Terminal window). Then do this:

sudo touch /Library/Google/GoogleSoftwareUpdate

3. Clear up the crud
If the updater was in your user library, open that now and go to

~/Library/Google/

and delete the folder called ‘GoogleSoftwareUpdate’. If you don’t use any other Google software (I don’t), you can just delete the entire ‘Google’ parent folder.

If the updater was in your domain library, search for the same folder and send it to the trash. You will need to give Finder your admin password to authorise the move.

Next, let’s just check the uninstaller was successful. Look for the following. If you don’t find them, good (the installer did its job). If you do, help them on their way to oblivion by sending them to the trash:

~/Library/Caches/com.google.Keystone.Agent
~/Library/LaunchAgents/com.google.Keystone.agent.plist
~/Library/Preferences/com.google.Keystone.Agent.plist

If you’ve deleted Chrome from your Applications folder too, then you might as well hunt down and exterminate its prefs list while you’re at it:

~/Library/Preferences/com.google.Chrome.plist


The following sources were used in researching this post:
http://wireload.net/products/guu-google-update-uninstaller/

http://raamdev.com/2008/howto-remove-google-software-update-on-mac-os-x/

http://blog.slaunchaman.com/2010/06/30/google-earth-now-available-without-automatic-updates/

https://support.google.com/installer/answer/147176?hl=en

‘Don’t be evil’ picture was remediated from here.

FastTasks 2 – take the toil out of Terminal 💥

FastTasks 2.0 I’ve just released the first build of FastTasks 2 over on my software website Sqwarq.com.

FastTasks 2 is a menu-bar app that takes the toil out of Terminal and offers at-a-glance display of key system info, the ability to quickly toggle hidden files, free memory, remove login items and create a super-fast RAM disk.

All told, FastTasks 2 offers more than a dozen tasks that you can accomplish with little more than a click. Check out the screenshots below to get an overview of the main features.

When you’re ready, head on over to the FastTasks home page to download your free copy, and forget looking up tiresome Terminal commands – just click and the task is done! FastTasks 2 contains no adds, nags or in-app purchases and is currently on offer for free, so go get one now!

FastTasks 2 requires OS X 10.9 or higher.



Toggle system settings


FreeMemoryMonitorIP



RAMdisc

how to save and print email attachments

I was recently asked for a script that would automatically save and print all the pdfs from one particular client’s emails. Since this is quite a common use case (think invoices from a particular supplier, for example) and involves a fair bit of complexity, I thought I’d share the answer for any others out there that have the same need.

We’re going to need to do three things; install a script, set up a mail rule, and set up folder actions. Here we go!


Part 1: Install Script

Copy and paste the script you see below from here:

save mail attachmentsSave this script with a name like ‘CopyAttachments’ in

~/Library/Application Scripts/com.apple.mail

(note: ~/Library means your user library. You can find it by triple-clicking the path above, then control-click on the highlighted text and choose Services > Reveal in Finder)


Part 2: Set up Mail Rule

Open Mail.app. Click on your Inbox in the sidebar. Click ‘Mail > Preferences… > Rules > Add Rule’

Under ‘Description’ give the rule a name (e.g., ‘Copy attachments’)

Set ‘If ANY of the following conditions are met':

to

‘From contains’

and the email address of the person whose attachments you want to target.

(note: You can add more than one person’s email if you wish, but you do so by hitting the ‘+’ key and adding a new condition, not by adding more than one address in the text field. Each text field must contain only one condition, i.e., email address or keyword).

Next, set ‘Perform the following actions:’

to

‘Run AppleScript’

Click the ‘No Script Selected’ button and choose ‘CopyAttachments’

Click ‘OK” and in the following dialog click ‘Apply’.


3. Create & Set up a Folder Action

Open Automator.app. From the open panel choose ‘Folder Action’.

In the large, empty panel at the top you’ll see

‘Folder Action receives files and folders added to’ Choose folder

Click the Choose folder menu, choose Other. Select the folder you want the attachments to be saved in.

In the filter/search bar on the left of the Automator window, type ‘print images’. Drag the ‘Print Images’ selection from the results list into the middle of the empty workflow and release.

You can set some options here if you like (‘scale to fit’ might be useful).
You can choose either ‘Default Printer’ or click to select your actual printer. If your actual printer is the default, it won’t make any difference.

Press ‘command-S’ on your keyboard to save. Supply a name (e.g. Print PDFs) and hit ‘OK’. You do not choose a save location.

Quit Automator.

Open a Finder window and navigate to the folder where the attachments are going to be saved.

Hold down the ‘control’ key on your keyboard and click the attachments folder. From the contextual menu, go to Services > Folder Actions Setup… and click to open the dialog box.

Navigate down the list of scripts till you see the name of the Automator action you saved above and select it. Click ‘Attach’.

In the parent dialog box, check the box at the top that says ‘Enable Folder Actions’ and ensure that in the list on the left the attachments folder is listed and checked. Check that on the right, the ‘Print PDFs.workflow’ is checked.

If all is in order, close the dialog box. The procedure is complete and the workflow is installed.


Testing

It’d be wise to test the script as soon as possible. If it fails to work, double check that you’ve entered the correct path in the AppleScript as that’s the most likely point of failure. Let’s suppose your hard disk is called ‘Macintosh HD’, your user name is “Mack” and the folder you want to save the attachments in is “Invoices From Acme”, then the set attachmentsFolder line should look like this:

set attachmentsFolder to "Volumes:Macintosh HD:Users:Mack:Invoices From Acme:" as rich text

You must ensure you’ve already created the folder ‘Invoices From Acme’ before running the script. Also, be sure you don’t forget the trailing colon at the end of the path and that you have a matching pair of opening and closing quotes around the path name.

Any problems, drop me a comment below and I’ll try to help you out. Good luck and enjoy! :)


FastTasks version 1.18 released! 💥

FastTasks v.118

I’ve just posted an incremental update to my free system utility, FastTasks. The update fixes a bottleneck in the launch code that caused FastTasks to take excessively long to load. I’ve also added the System Uptime, which you can also refresh with the new keyboard shortcut, ‘command-U’.

FastTasks saves you having to role up your sleeves and get mired in the exotic world of Terminal’s command line for a number of common tasks. FastTasks v1.18 offers you system info down the left side of the panel, all of which can be updated by the shortcuts displayed on the panel, and access to some common Terminal commands on the right.

If you haven’t tried FastTasks yet (or got tired of the slow launch times with the old version), this is a great time to grab a free copy of v1.18 as I’ll soon be replacing the app by FastTasks 2.0, a paid-for app with a whole new interface and extra functions. Nevertheless, support for FastTasks 1 will continue and bug fixes will still be forthcoming as necessary. Grab it while you can, folks! :)

Download FastTasks v1.18 from here…

Note: FastTasks requires OS X 10.6.8 or higher


%d bloggers like this: