It will create and keep a running log file (called ‘log.txt’) on your Desktop indicating which apps have been in focus on your machine and for how long each time. This could be ideal if you want to keep track of how long you spend working on a particular project either for billing a client or just for checking your own productivity.
How to use:
Open AppleScript Editor and paste the text below into the Editor window. Click the ‘run’ button. When you’ve had enough click the ‘stop’ button. It would be possible to automate running and stopping this, but I’ll leave that for the comments or maybe a later post.
*Note: be sure to click out of the app you’re using and activate Finder before you put the machine to sleep, otherwise the log will include the sleep time in the app’s duration
--start of script
set front_app to (path to frontmost application as text)
set _start to current date
set current_app to (path to frontmost application as text)
if current_app is not equal to front_app then
set _stop to current date
do shell script "echo " & front_app & " was active from " & _start & " until " & _stop & " >> ~/Desktop/log.txt"
set front_app to current_app
set _start to current date
--end of script
You will see the log looks something like this:
Seagate DP1:Applications:Utilities:AppleScript Editor.app: was active from Monday, 17 June 2013 17:20:30 until Monday, 17 June 2013 17:20:35
Seagate DP1:Applications:Adobe InDesign CS6:Adobe InDesign CS6.app: was active from Monday, 17 June 2013 17:20:35 until Monday, 17 June 2013 17:21:15
Seagate DP1:Applications:TextWrangler.app: was active from Monday, 17 June 2013 17:21:15 until Monday, 17 June 2013 17:21:25
Seagate DP1:Applications:Adobe InDesign CS6:Adobe InDesign CS6.app: was active from Monday, 17 June 2013 17:21:25 until Monday, 17 June 2013 17:24:46
Seagate DP1:Applications:TextEdit.app: was active from Monday, 17 June 2013 17:24:46 until Monday, 17 June 2013 17:26:26
Seagate DP1:Applications:Safari.app: was active from Monday, 17 June 2013 17:26:26 until Monday, 17 June 2013 17:45:03
Seagate DP1:Applications:Adobe InDesign CS6:Adobe InDesign CS6.app: was active from Monday, 17 June 2013 17:45:03 until Monday, 17 June 2013 17:46:03
Seagate DP1:Applications:TextEdit.app: was active from Monday, 17 June 2013 17:46:03 until Monday, 17 June 2013 17:46:13
On subsequent runs, you can keep the same log (the script will continue to add to the log on each run) or roll it over by renaming the log.txt on the Desktop and saving it off to somewhere else. If you rename or move the log.txt, then the next time you run the script, it will create a fresh log.txt on your Desktop automatically.
Featured picture: My Work Desk by ~RianGonzales
1. Run ‘Repair System Permissions‘ in Disk Utility.
Repairing system level permissions won’t solve the kext cache problem, but you’ll want to make sure they are all in order first. There is no need to repair ACL permissions for this procedure.
2. Open Terminal.app
Copy and paste the following:
sudo chown root:admin /
Hit ‘return’ and type in your admin password. This step ensures that the admin user has ownership permissions for everything on the startup disk.
3. Fix the kext cache permissions
Paste the following code into Terminal.app, hitting ‘return’ again and supplying the password if requested (if you do this shortly after step 2 you may not be asked for the password again):
sudo touch /System/Library/Extensions
4. Clear Console log and restart
The next two steps aren’t strictly necessary, but are good practice. Open Console.app, click ‘All Messages’ in the sidebar and hit the ‘Clear Display’ button in the Tool bar. Now, restart your mac.
5. Check for the problem
See if the procedure was successful by opening Console.app again, choosing ‘All messages’ in the sidebar and typing
in the filter/search bar over on the right. If you carried out the procedure above correctly, it shouldn’t return any ‘can’t create kext cache / user isn’t root’ messages since the restart time.
Featured picture: I’m not a balloon owner anymore by ~starwink
If you find it annoying that in Pages and other Apple apps, there’s no easy way to remove rich text formatting when you copy and paste from websites and other rich text sources, this could be just the tip for you.
The video begins with a demonstration and then shows you how to create the shortcut shown. If you don’t see captions at the bottom of the video, be sure to press the ‘CC’ button in the YouTube video controller bar at the bottom of the screen.
The procedure is fairly straightforward:
1. Open Automator.app and create a new service by clicking on the gear/cog.
2. Change the ‘Service receives’ menu to ‘no input’.
3. Type ‘Apples’ in the Action filter bar, and drag a ‘Run AppleScript’ action into the main pane.
4. Clear the default text, and copy/paste this into the window:
set the clipboard to «class ktxt» of ((the clipboard as text) as record)
5. Click the hammer icon to compile the code, and then ‘command-S’ to save it (you don’t need to choose a save location).
6. The service will now appear in your Services menu (eg. Pages > Services > plainTxt).
Whenever you copy some formatted text, just click on the plainTxt item in the Services menu before you paste, and you’ll get plain text instead.
7. Follow the second half of the video if you want to make a global shortcut.
Ever wondered if a link you clicked sneakily downloaded and installed some unwanted software on your mac? Or have you suddenly found your mac behaving weirdly, a situation that is often a result of installing new software that conflicts with something else on the system, but can’t remember what you recently installed? In these sorts of scenarios, what you need to do is check your install logs.
I’ll tell you how to do that in a moment – in a number of ways – but first let’s just make a few notes. Firstly, chances are you’ll find more than one install log in your logs folder. The most recent one is simply called
install.log, older ones will have a filename ending with
.bz2, indicating a compressed file. Secondly, the reason you may have more than one install log is that OS X creates new install logs every time the log file gets to around 1MB in size. It then compresses and keeps the old logs, typically up to five logs prior to the current one.
Pro Tip No.1: if you’re a Terminal whizz and you want to change how many old logs are kept or at what size the log file gets turned over, you can edit the
/etc/newsyslog.conffile, but be sure to read the
Typically, we’re only going to be interested in examining the most recent log file if troubleshooting new problems, but the process that I’m going to describe here can also be used to view the older logs, too. Apple buries the logs deep into parts of OS X that ordinary users typically don’t reach, but fortunately, there’s numerous ways to get at your install logs, and though some of them may be unfamiliar, none of them are particularly difficult or dangerous.
1. View only recently installed items
Open the Terminal.app (Utilities/Terminal.app) and copy and paste this command:
grep 'Installed' /private/var/log/install.log
This will return a list of every item successfully installed since the new log file was created. If there’s nothing of interest there, but you think there should be, then you’re going to need to see a bit more of the log file, and perhaps find out when it was ‘rotated’ or ‘turned over’ (i.e., the last time the system archived the install.log and created a new one).
2. View the entire install log
If you’d like to see the whole log for this reason, or perhaps you want to see whether something failed to install, it’s probably best having the log displayed in TextEdit rather than Terminal, so copy and paste this command into the Terminal window:
cat /private/var/log/install.log | open -f
You’ll see at the beginning of the file it’ll tell you when the file was turned over. Don’t forget you can use TextEdit’s search facility (Command-F) to search for particular instances or items you’re interested in finding. When you’re finished viewing this file, you can simply close TextEdit and discard it. It isn’t the actual log file, but rather a local copy of it.
3. Using Console
Alternatively,, if you don’t feel comfortable in Terminal, you can view all your install logs in the Console.app. You can open Console either through Finder by navigating to /Applications/Utilities/Console.app or just by typing ‘cons’ in either Spotlight or Launchpad. Once Console is open, scroll down the sidebar, looking for /var/log. Click the disclosure triangle if it’s not already pointing downwards and look for install.log. Click on that, and then in the filter bar in the main window, type installed (unlike the grep command I gave you above, this one is not case sensitive and will return both ‘Installed’ and ‘installed’).
Notice in the screenshot above, I’m examining a turned over log, not the current one. As this particular install of Mountain Lion was only done on May 3rd, there’s only one turned over log file.
Pro Tip No.2: You can force the system to turn over all the log files, including install.log even if they haven’t reached their maximum size. As it says in the
newsyslog, this can be “useful for diagnosing system problems by providing you with fresh logs that contain only the problems.”
To force all log files to be turned over, simply enter
sudo newsyslog -Finto Terminal. Hit ‘return’ and supply your password, as always with the
4. Using Finder
If Console is a bit too off-territory for you, there’s nothing wrong with viewing your logs in Finder and TextEdit. To do that, click on the Finder, then hit ‘shift-command-G’ on the keyboard (or click ‘Go’ in the menu bar and choose ‘Go to Folder’). Type or paste this into the dialogue box:
and hit the ‘Go’ button.
Right-click on any of the logs you want to open and choose ‘open with’ from the contextual menu. Choose ‘TextEdit’ or your favourite plain text editor app. If none of your text editors show up in the menu, click ‘Other’ and change the ‘Enable’ menu to ‘All Applications’. You will now be able to choose TextEdit or some other editor if you have one. Note that unlike Step 2 above when we used a Terminal command to open a copy of the install log in TextEdit, here you are viewing the actual files rather than a copy of them. Although the log files are not important to the running of your system and can be deleted or altered without causing any consequences, they do provide useful records for troubleshooting so its always good practice to keep them in tact if you can.
And that, in a nutshell, is how you view your install logs!
Featured picture: Rectangleum by *Eccoton
If you’ve installed a MAMP dev environment and have found the instructions you’ve read elsewhere for setting up a virtual host on port :80 aren’t working, the following should get you sorted.
1. First of all, make sure Mountain Lion’s not running Apache separately from MAMP. To do so, open Terminal.app, and copy/paste this into the Terminal window:
sudo launchctl unload -w /System/Library/LaunchDaemons/org.apache.httpd.plist
(that’s all one line!)
Enter your admin password when prompted. Be aware that it will be invisible as you type, so type carefully. If you get an error message that says “Sorry, try again”, then indeed, try again. Only type more carefully this time! . On the other hand, if Terminal just returns the prompt after you hit ‘return’ or reports ‘Nothing to unload’ then you’re good to go to Step 2.
2. Assuming that you want to call your virtual host site ‘mytest’, then add to the last line of the /etc/hosts file:
3. That’s the easy part! Next, add to the end of the /Applications/MAMP/conf/apache/httpd.conf file the following text:
Note that there are quote marks around both
DocumentRoot filepaths. Also, be sure to change the items highlighted in red to reflect your own shortuser name and site name.
4. Go into your Home folder in the Finder, and create a folder called ~/Sites/mytest/ (before creating the ‘mytest’ folder, you may need to create the parent folder ‘Sites’ if it doesn’t already exist).
5. Create an ‘index.html’ file inside ~/Sites/mytest/ that looks something like this:
<p>My virtual host site is up!</p>
6. Finally, be sure to restart the MAMP servers and you should be up and running!
For further help with MAMP, please see the documentation here.
If you have multiple accounts on your mac, you may sometimes wish to log out one or more of those accounts without actually having to sign in to them first via the fast user switching menu. There’s a couple of ways to do this. First, if the issue is just that you want to shutdown the computer, you can log out all users by entering an Admin user name and password when this dialogue automatically appears after hitting ‘Shutdown’ (it won’t appear if no other users are logged on):
However, there are times when you may just want a quick way to log out users without shutting down and without wasting time logging in to their accounts first. Be aware that in killing a user’s process without logging in to the account first, any data in that user’s account that is not already saved (or autosaved) will be lost. If you’re sure that’s not a problem, then follow this short procedure:
1. Open up Activity Monitor (/Applications/Utilities/Activity Monitor.app)
2. Use the drop down menu in the Task bar to change the menu to ‘Other User Processes’ (note: you can use ‘All Processes’ in the menu if you wish, but that is less safe as it makes it possible to accidentally click on your own user process in step 4 below!).
3. In the filter bar, type
4. From the list of users that show up, for each one that you wish to log out:
- click on its row in the Activity Monitor pane to highlight the process
- press the ‘Quit Process’ icon in the Task bar above
- from the resulting dialogue window, click ‘Force Quit’
- supply an Admin password if requested.
Repeat for any further accounts that you wish to quit. (Tip: If you want to kill the ‘Guest User Account’, you’ll need to switch back to ‘All Processes’ and kill the loginwindow assigned to the ‘root’ user).
And that’s it. Your unwanted users are now logged out!
This is something I’ve been thinking about for a while. I have a pretty long Reading List and Spotlight often fails to find things in it. For that reason I came up with this little script which you might find useful.
1. Open up Automator by typing
auto in Spotlight.
4. In the small filter bar to the left, type ‘run app’. You should see an action called ‘Run AppleScript’ in the second column. Drag it to the big pane on the right.
5. Select all the purple text inside the window and delete it. You don’t need any of it.
7. Hit ‘Command-S’ and give it a name like ‘Search Safari Reading List’. Click ‘Save’ (note: you do not specify a location for the save as it will automatically be saved in your ~/Library/Services folder).
10. If you want to assign a universal shortcut key like mine in the screenshot from Step 8, do so by going to > System Preferences > Keyboard > Keyboard shortcuts. Look in Services for the name you gave it and add the shortcut by clicking in the empty space to the far right of the name.
A note on usage:
The reading list is really just a list of special bookmarks, with one difference: they contain short snippets or previews from each page. This has an impact on the way my script works in the following way: if the search string is in the preview snippet but isn’t in the URL, you’ll get back the line from the snippet but you won’t get the URL. It might be possible to code round that, but I haven’t had time to figure it out yet. If that’s a feature you want, send me a nag mail and I’ll put it on my list of things to do! . Otherwise it appears to function quite well as a workaround for the lack of a proper search facility.
If you’re new to Mac, you’re probably thinking that it’s a no-brainer that you need some kind of anti-virus app. Once you start looking around the web for reviews, it’s inevitable that you’re going to come across the Great Mac AntiVirus Debate: in the one corner, those who say Mac users who forego antivirus protection are arrogant and just setting themselves up for a fall, and in the other those who’ve used Macs for umpteen years, never had or heard of any real threat, and consequently say AV software is a waste of time.
You can read round this debate for years and never come to a satisfying conclusion, largely because its as much about what you ‘ought’ to do as it is about what is the case. Just because you’ve never had any viruses, doesn’t mean you won’t get one tomorrow. And yet, there are NO viruses in the wild known to affect macs, and so when one does arrive, it will be unknown to your AV scanner. Hence, an AV Scanner is just a waste of system resources (and possibly money, if you paid for it). Yikes! What do I do!!
What you do is sidestep the whole debate and stop thinking only about virus scanners, which after all deal with only a small subset of all the possible attack vectors in the internet age, and start thinking in terms of vulnerability scanners. Unlike a simple virus scanner, a vulnerability scanner examines your system not only for malware but also for any vulnerabilities in commercial software, plug ins, your system setup (including network and other sharing settings) and other installed items. The scanner will not only explain the threat and its severity but also tell you what, if anything, you need to do, recommend patches and guide you to links for more info where available.
You can use something like Nessus for free if you are a home user, which will give you a far better insight into the possible attacks someone could implement on your system (and it will check your system against almost all of the major virus scanner databases like Symantec, etc).
Even better, a vulnerability scanner like Nessus won’t just examine your machine, it’ll look at everything else (and all the installed apps) of anything on your home network including phones (any platform), other computer systems (any OS), and even your router.