applescript: file & folder handlers

Screen Shot 2016-07-26 at 17.06.40

Here’s a few of
the AppleScript handlers I use for getting contents of folders (examples 1 & 2), or for getting the text of a file (example 3).

In all three cases, you give the handler a path string in POSIX form, e.g, ~/Desktop or (for example 3), ~/Desktop/sometext.txt.

In example 1, what you get back is a list of the item names in the folder. It doesn’t include hidden or invisible files.

In example 2, what you get back is a record of all the items and their properties. This can be an immensely useful and powerful handler.

In example 3, what you get back is a text variable whose value is the complete text of the file.

Hope these come in as handy for you folks as they have for me!

Click here to get the handlers from my pastebin.

Enjoy!:)

Note: The getFileContents() handler requires OSX 10.10 or higher.

Using Handlers Pt1

Using Cocoa in AppleScript

applescript: easiest way to GUI script

 

Script Debugger is third-party software available from here.

Disclaimer: I have no financial or any other compensatory connection with the developers.

Script Debugger 6: the complete review

SD Shot 2



It feels like cheating. When you’ve spent pretty much your entire AppleScripting life behind the wheel of Apple’s austere Script Editor application, taking Script Debugger 6 out for a 20-day spin feels like someone’s let you in on a secret you’re not supposed to know. Hurdles you’ve taught yourself to clear – through considerable effort, frustration and no small amount of bloody-minded tenacity – are removed before you get to them; obstacles you’ve habitually steered around or avoided have disappeared, and dark holes of AppleScript mystery appear, in the light shone on them by SD6, to be not the menacing entities you once feared but new friends that offer ways to do things faster and more effectively. The secret that Script Debugger seems to lay bare is that AppleScripting doesn’t have to be as painful as we’ve been conditioned to believe. And that does feel like a cheat. Read the full review…


learning the Terminal: Part Three

Screen Shot 2016-07-02 at 15.24.53
It’s been a while since we last posted about Terminal tips and tricks, but a question popped up today about how to discover what tools are available on the command line.

Most of the tools you use in Terminal are located in /usr/bin, and we can use a nifty little tool from there to find out about all its friends. The whatis tool gives you a one-liner description of what a tool does. If it looks interesting, you can find out more about the tool by typing man and the tool’s name on the command line to see its help manual.

On my current machine, there’s over 1000 tools in /usr/bin, and life is just too short to go through them all doing whatis on each and every one, so we’ll combine a bit of command line power with some AppleScript magic, and produce a nice, easy-to-scroll output of all the summaries like the one in the screenshot above.

Copy the script below (or from my pastebin here) and paste it into the Script Editor (/Applications/Utilities/Script Editor.app). Click the ▶︎ button to run it.

This script took about 1m 30 seconds to run on my machine, but you only need to run it once then save the output. Browse or search through it at your own convenience.:)

The script will choose TextWrangler for display if you have it installed; if not, it’ll default to TextEdit. The display is much nicer in TextWrangler, but if you’re stuck with TextEdit, turning off ‘Check Spelling’ in TextEdit will aid readability.

# start 

(* 

This script produces a summary of all the CLI tools 

in /usr/bin and displays it in a text document 

*)

set noDocsList to {}

on extractDescription(aText)

repeat with i from 1 to count of items in aText

set this_item to item i of aText

if this_item contains "NNAAMMEE" then

set r to item (i + 1) of aText

try

set o to offset of "" in r

set short_r to text (o + 1) thru -1 of r

set r to short_r

end try

return r

end if

end repeat

end extractDescription

set theDescriptions to return & return & "**********************************" & return & "SUMMARY OF CLI TOOLS (Version 2)" & return & "**********************************" & return & return & return

tell application "System Events"

set theItems to name of every file of folder "bin" of folder "usr" of startup disk

end tell

repeat with i from 1 to count of theItems

set this_item to item i of theItems

set n_item to length of this_item

try

set what_is to do shell script "whatis " & this_item

if text 1 thru n_item of what_is is this_item and what_is does not contain "nothing appropriate" then

set theDescriptions to theDescriptions & return & what_is & return

else

try

set getMan to paragraphs of (do shell script "man " & this_item)

set desc to extractDescription(getMan)

set what_is to this_item & tab & tab & tab & tab & desc

set theDescriptions to theDescriptions & return & what_is & return

on error

set end of my noDocsList to this_item & return

end try

end if

end try

end repeat

set theApp to "TextEdit"

tell application "Finder"

if exists POSIX file "/Applications/TextWrangler.app" then

set theApp to "TextWrangler"

end if

end tell

set theDescriptions to theDescriptions & return & return & return & "The following tools do not have any documentation: " & return & return & noDocsList

tell application theApp

activate

make new document

set front document's text to my theDescriptions

end tell

# EOF 


WWDC: get it for free (OSXClock)

Screen Shot 2016-06-13 at 20.31.55

Apple’s WWDC 2016 conference is about to start. Is it the end of OSX? Rumours are widespread that the venerable old operating system is about to change its name to macOS.

Right or wrong, commiserate or celebrate, we thought we’d mark the occasion by giving away free copies of the full-paid version of our OSXClock.app.

The offer is already up and live and will continue to be available until WWDC 2016 closes on the 17th.

We’ve also just released an update to OSXClock yesterday adding world time zones, so there’s no better time to take advantage of this giveaway.

Enjoy!:)

how to find anything on your mac

top shot
 
With the release of FT2 2.13 comes a new SuperSearch function. You can use this to find anything on your mac or connected drives, open folders (including hidden ones) and launch apps. You can open SuperSearch quickly by holding down the shift key when you click the F2 icon in the status bar.

If you’re familiar with EasyFind and Spotlight, you can think of SuperSearch as sort of a ‘Spotlight on Steroids’ (use the ‘Faster’ option’) combined with an ‘EasyFind without the overhead’ (use the ‘Deeper’ option). SuperSearch supports using the spacebar to open Quick Look and double-clicking to reveal an item in the Finder.

For the most part, you’ll want to use the options ‘Faster’, ‘String’ and alternate between ‘Name’ (for files) or ‘Content’ (for text within files). Choose to include case sensitivity, emails and web history as needed. However, there’s a lot of different ways you can use SuperSearch. Here’s a few examples:

Find hidden files
(use ‘Deeper’, ‘Name’, ‘String’)
 
first shot

Find files by bundle identifier
(use ‘Deeper’, ‘Name’, ‘String’)
 
Screen Shot 2016-06-05 at 17.16.32

Open folders in the Finder
(just type the path and hit return; use ~/ to target the home folder; the options are not relevant)
 
second shot
 
Search for text in files
(use ‘Faster’, ‘Content’, ‘String’ for speed, or use ‘Deeper’ if you want to target a particular drive or directory, or if you want to search for content within hidden files and packages, too).

When you use ‘Deeper’ to search for content, the item name includes a hit count of the number of occurrences of the search term in that file:
 
shot three

Launch applications
(prefix the app name with ` (that’s the key directly above the ‘tab’ key) to tell SuperSearch you want to open it rather than find it. The options are not relevant).
 
shot four

:)
 

keep an eye on Console with ConsoleSpy

icon_512x512

ConsoleSpy is a simple but powerful little app that offers a window into system.log and which can trap incoming messages meeting user-defined search criteria. It’s aimed at software testers, bug hunters, security researchers and anyone who needs to do analytical troubleshooting work on a mac.

Minimum system requirements: OS X 10.11. ConsoleSpy is currently free.

Here’s an intro to its features and how you can use ConsoleSpy to aid in analysing your mac and your software.

Screen Shot 2016-05-22 at 13.22.36

What does it do?
The best way to illustrate the use case for ConsoleSpy is to consider a couple of ‘based on a true story’ user problems I’ve encountered recently.

Case 1: In one case, a user was concerned that an attacker was logging into her computer remotely. Unaware of how that might be happening, the user searched the Console.app and found a number of suspicious remote login attempts. However, these always seemed to occur at times she wasn’t at the computer and sometimes weeks apart. It became a laborious job and anxious routine for her both to remember and to search through the Console logs every morning to see if anything suspicious had occurred.

Case 2: In the second case, a user realised that the Time Machine backups she’d been relying on had been silently failing to pass verification checks. There was no indication from Time Machine itself, and she only discovered the problem, weeks after it had began, by a fortuitous glance at the Console.app where she discovered multiple ‘Backup verification failed’ messages.

In both these cases, ConsoleSpy could have alerted the user to the problem as soon as it had occurred. ConsoleSpy allows you to set search terms to trap incoming messages. Both a Dock badge and a visual indicator in ConsoleSpy’s display indicate when a message has been trapped. By using the search term ‘sharing,’, our user worried about remote hacking would have instantly been able to see if a log in had been attempted and when. Our user with the failed backup problem would have likewise been alerted instantly the first time the problem occurred by using ‘backup,’ or ‘backup verification,’ (if she had only wanted to trap specific verification messages) as Alert strings.

Screen Shot 2016-05-22 at 11.24.57

ConsoleSpy becomes more useful the more accurately you know what you’re looking for. For bug hunters and software developers, simply setting an alert on your app or process id name will immediately funnel all incoming messages into ConsoleSpy’s ‘Alerts received’ box, allowing you to exercise your app in various conditions and immediately see the results. You can get as specific or as general as you want, but do see the help on Alert string syntax.

How do I use it?
After launching ConsoleSpy, you’ll be presented with an ‘always on top’ display of the most recent message into the Console. You can move the display around by clicking anywhere in the black part of the display and dragging. The four buttons on the right hand side offer you access to all of ConsoleSpy’s main functions, clockwise from top left:

Screen Shot 2016-05-22 at 13.49.17

Display
i. Freeze the display: in the event that you see something interesting and want more time to read it before the next message comes in, you can lock the display by clicking the little padlock button. When locked, the text in the display changes colour and a padlock appears at the end of the text. Note that when the display is locked, the View buttons in the Preferences window (See below) will have no effect. Click the padlock again to unlock the display.

ii. Hide ConsoleSpy: click the orange button to hide ConsoleSpy. Often, you won’t want the display visible but you will want ConsoleSpy to keep watching for alerts. You can also hide the app with ‘Command-H’.

iii. Open Console.app: the little ‘eye’ button immediately opens Console and takes you to the most recent message in system.log.

iv. Preferences: this is a toggle button that opens or closes the Preferences drawer. We’ll get to that next.

Screen Shot 2016-05-22 at 13.24.10

 

Preferences
The controls on the far left should be self-explanatory, but a couple of notes are in order.

View: As mentioned above the ‘View’ buttons are disabled when the display is locked, but otherwise they toggle the length of the display. The ‘Long’ view is particularly useful when reading multiple messages in the ‘Alerts received’ box.

Frequency: this controls the frequency at which ConsoleSpy updates the display. Note that ConsoleSpy continues to scan for messages that meet your Alert string criteria even between polls regardless of whether the app is visible or hidden, or the display is locked (see above). ConsoleSpy’s buffer can handle up to 40 messages between polls. If ConsoleSpy’s buffer is flooded with more than that, the display will show a ‘Flood’ warning. flood3 For more information see ‘The Hoary Gory’ section below.

Alert Strings: this is the most important field you’re going to want to manage. When you first launch ConsoleSpy, you’ll see some default search strings are already included by way of example. You can remove or add to them by clicking the ‘Edit’ button at the bottom left of the text box. Search string syntax is fairly basic, but allows you to be as specific or as general as you wish. Ensure that each term is comma-separated and the entire list is comma-terminated (i.e, there should be a comma after the last search term in the list, too). Click the ‘?’ button to go to the support page giving examples of search string syntax. Drop us a line in the Comments if you need help or contact Sqwarq support.

Alerts received: this is the main display for your results. You can select and copy all or parts of the message to search in Console.app if you want to see the message in context. Using the date string without the seconds is a particularly useful way to search for messages in Console if you want to see what else was happening around the same time.

You can clear the ‘Alerts received’ box (and the Dock badge and the display alert symbol) by clicking the ‘-‘ minus button at the bottom left of the text box. We suggest regularly and promptly removing messages from the Alerts received box once you’ve read them as the messages are already archived in Console.app.

The Hoary Gory
ConsoleSpy polls the system log every 1, 2 or 5 seconds according to the Frequency setting in the Preferences, and displays the most recent message. Unless the system log is being flooded with more than 40 messages since the last poll, ConsoleSpy won’t miss a thing and you’ll get an alert if any message meets your search criteria, even if it wasn’t displayed in ConsoleSpy’s display. If ConsoleSpy’s buffer is flooded, a small ‘flooding’ alert symbol shows in the display. The start and end flood times can be displayed in the Alerts Received box by setting an alert string for ‘flood,’.

If you experience a lot of flood warnings (entirely possible in scenarios where you are beta testing software or even the operating system itself), try using a faster frequency (i.e, 1 sec). While this may seem counterintuitive, it is a consequence of ConsoleSpy’s fixed buffer size. The buffer can hold up to 40 new messages since the last poll, so the amount of messages ConsoleSpy can search between each poll is 40/(frequency). As we develop the app, we plan to include a choice of larger buffer sizes. The current buffer size is a conservative choice designed to ensure the app is usable even on smaller, less powerful macs.

If you’re already using the fastest poll time of 1 sec and flood warnings are occurring constantly, this is a good sign that some software is not behaving as intended. Of course, when testing beta software, especially a beta OS, there may be so many deliberate logs to the system log that ConsoleSpy reports flooding almost all the time. This is not a problem for ConsoleSpy; indeed, having ConsoleSpy alert you of flooding is one of its intended functions, so that you can see just when and how often something is happening. The main thing to be aware of during times of repeated or constant flooding is that ConsoleSpy may not be able to search every single message received against your search terms. You can, of course, turn Alerts off during such times, but a better solution is to leave Alerts on (ConsoleSpy will still return most if not all search hits, depending on how severe the flooding) and simply use the Console.app itself to do an historical search to see if any crucial messages you would have expected but which did not get spotted by ConsoleSpy are in the log.

Note that while Alert string searches begin as soon as ConsoleSpy is launched, flood detection is not enabled until 30 seconds after launch. This is due to the fact that ConsoleSpy’s buffer needs to be full before it can determine the rate of incoming messages.

That about rounds up our introduction to ConsoleSpy. We hope you find it useful, and if you have any questions, drop us a comment or email us at Sqwarq support.

Download ConsoleSpy

how to see what Time Machine has and will backup

Screen Shot 2016-05-13 at 21.57.25
If you find Time Machine’s taciturn silence on what it has and will do a bit frustrating at times, the command line utility tmutil can offer you a bit more insight.

In particular, if you’d like to see what Time Machine is going to back up just before it’s about to run, execute the following command in the Terminal:

tmutil compare

That will compare the machine as it is now against the last backup (See the man page for more options on the output). It took about 5 minutes on my mac, but I have a small hard drive. It could take somewhat longer depending on how much data you’ve got to trawl through. Remember that you’re doing a diff on a moving target, so the less you can use the machine for other tasks while this command is running the faster it’ll complete.

On the other hand, you might want to know more about what Time Machine has just done after a backup. Which files did, or did not, get changed, added or removed?

You can find out what got backed up after the task finishes by comparing the most recent snapshot (the one that’s just completed), with the previous one (this is much faster, took about 35 seconds here). You can do that in Terminal, too, but the syntax can be a bit tricky. To make it easier, here’s a handy AppleScript that will do it for you. Just pop it into the (Apple)Script Editor.app and hit the ‘Run’ ▶︎ button.


# This script compares the most recent backup to the previous one
# indicating what was changed, added or removed

set backupList to paragraphs of (do shell script "tmutil listbackups")
if (count of backupList) < 2 then
display dialog "Sorry, couldn't find anything to compare. Try again after the next backup"
else
set path1 to quoted form of item -2 of backupList
set path2 to quoted form of item -1 of backupList
do shell script "tmutil compare " & path1 & " " & path2 & " | open -f"
end if

%d bloggers like this: