The Robservatory

Robservations on everything…

 

Terminal

Easily see any app’s bundle identifier

Rob Griffiths
Jun 12 '18
[Mac OS X Hints, Terminal, Unix]
1 Comment

I occasionally need to help one of our customers get the bundle identifier for a given app, for some purpose with one of our apps. While the task isn’t complicated—the value is stored in a file named Info.plist within each app bundle—it’s not something that’s necessarily easy to explain to someone who doesn’t have a lot of Mac experience.

I figured there must be a less-complicated solution, and I was right, though it’s probably higher on the geek factor. After some searching, I found this thread at Super User, which offers a number of solutions. The simplest—and always working, in my experience—was the very first one: Open Terminal and run this command:

osascript -e 'id of app "Name of App"'

The "Name of App" is replaced with the name of the app as it appears when hovering over its Dock icon. For Excel, for example, it’d be:

osascript -e 'id of app "Microsoft Excel"'

Run that command, and it returns com.microsoft.Excel, which is just what I need—I just have the customer copy the output and email it back to me.

View app-specific log messages in Terminal

Rob Griffiths
Mar 30 '18
[Mac OS X Hints, macOS, Terminal]
1 Comment

March 29 2018 Update:

When this tip was first posted, it didn’t work right: The log command ignored the --start, --end, and --last parameters. Regardless of what you listed for parameters, you’d always get the entire contents of the log file. I’m happy to note that this has been resolved in macOS 10.13.4, as log now functions as expected:

$ log show --last 20s --predicate 'processImagePath CONTAINS[c] "Twitter"'
Filtering the log data using "processImagePath CONTAINS[c] "Twitter""
Skipping info and debug messages, pass --info and/or --debug to include.
Timestamp                       Thread     Type        Activity             PID    TTL  
2018-03-30 09:26:15.357714-0700 0xc88a8    Default     0x0                  5075   0    Twitterrific: (CFNetwork) Task <9AD0920A-7AE7-4313-A727-6D34F4BBE38F>.<250> now using Connection 142
2018-03-30 09:26:15.357742-0700 0xc8d7a    Default     0x0                  5075   0    Twitterrific: (CFNetwork) Task <9AD0920A-7AE7-4313-A727-6D34F4BBE38F>.<250> sent request, body N
2018-03-30 09:26:15.420242-0700 0xc88a8    Default     0x0                  5075   0    Twitterrific: (CFNetwork) Task <9AD0920A-7AE7-4313-A727-6D34F4BBE38F>.<250> received response, status 200 content K
2018-03-30 09:26:15.420406-0700 0xc8d7a    Default     0x0                  5075   0    Twitterrific: (CFNetwork) Task <9AD0920A-7AE7-4313-A727-6D34F4BBE38F>.<250> response ended
 --------------------------------------------------------------------------------------------------------------------
Log      - Default:          4, Info:                0, Debug:             0, Error:          0, Fault:          0
Activity - Create:           0, Transition:          0, Actions:           0
$

This makes it really easy to get just the time slice you need from the overly-long log files. You can use s for seconds, m for minutes, h for hours, and d for days as arguments to these parameters.

This article provides a nice overview on interacting with log and predicates to filter the output—there’s a lot you can do to help figure out what might be causing a problem.

And now, here’s the rest of the original post…

(more…)

See how long an app has been running

Rob Griffiths
Sep 19 '17
[Mac OS X Hints, Terminal, Unix]
2 Comments

For a recent customer support question, I needed to know how long our app Witch had been running. There are probably many ways to find this out, but I couldn’t think of one. A quick web search found the solution, via ps and the etime flag.

You need the process ID (pid), which you can find via ps ax | grep [a]ppname.1That [s]quare brackets around the first letter are there so grep won’t find itself—and thus list itself in the output. In my case, Witch runs a background task called witchdaemon, so I did it this way…

$ ps -ax | grep [w]itchd
  774 ??        26:40.73 /Users/robg/Library/PreferencePanes...[trimmed]

With the pid, the command to find that process’ uptime is:

$ ps -o etime= -p "774"
11-03:17:12

The elapsed time readout is in the form of dd-hh:mm:ss, so Witch had been running for 11 days and a few hours and minutes. Note that you can combine these steps, getting the process ID and using it in the ps command all at once:

ps -o etime= -p "`ps -ax | grep [a]ppname | cut -d ' ' -f 1`"

It’s messy looking, but this form saves time and typing.

June 2018 Addendum: If you add the lstart flag, you can see the exact start date and time for the process. For example:

$ ps -o lstart= -o etime= -p "16866"
Tue Jun  5 05:49:19 2018     09-06:11:25

Selective pruning of old rsync backups

Rob Griffiths
May 2 '17
[Mac OS X Hints, Terminal, Unix]
1 Comment

In yesterday’s post, I described a couple rsync oddities, and how they’d led me to this modified command for pruning old (older than four days) backups:

find /path/to/backups/ -d 1 -type d -Bmin +$((60*4*24)) -maxdepth 1 -exec rm -r {} +

After getting this working, though, I wondered if it’d be possible to keep my backups from the first day of each month, even while clearing out the other dates. After some digging in the rsync man page, and testing in Terminal, it appears it’s possible, with some help from regex.

My backup folders are named with a trailing date and time stamp, like this:

back-2017-05-01_2230
back-2017-05-02_0534
back-2017-05-02_1002

To keep any backups made on the first of any month, for my folder naming schema, the modified find command would look like this:

find /path/to/backups/ -d 1 -type d -Bmin +$((60*4*24)) -maxdepth 1 -not -regex ".*-01_.*" -exec rm -r {} +

The new bits, -not -regex ".*-01_.*" basically say “find only files that do not contain anything surrounding a string that is ‘hyphen 01 underscore.’ And because only backups made on the first of the month will contain that pattern, they’re the only ones that will be left out of the purge.

This may be of interest to maybe two people out there; I’m documenting it so I remember how it works!

How to not accidentally delete all your rsync backups

Rob Griffiths
May 1 '17
[Mac OS X Hints, Terminal, Unix]
5 Comments

With my Time Machine-like rsync backups running well, I decided it was time to migrate over the cleanup portion of my old script—namely, the bit that removes older backups. Soon after I added this bit to my new script, though, I had a surprise: All of my backups, save the most recent, vanished.

In investigating why this happened, I stumbled across two rsync/macOS behaviors that I wasn’t aware of…and if you’re using rsync for backup, they may be of interest to you, too.

(more…)

How to burn an ISO file to a USB stick

Rob Griffiths
Apr 27 '17
[Mac OS X Hints, macOS, Terminal, Unix]
1 Comment

I wanted to install Linux on a hard drive in Frankenmac, as Clover is a multi-boot utility—it lets you choose from any OS it sees during power up. (I’ll add Windows, too, eventually.) To do this, you need to get Linux onto a USB stick. I’ve done this in the past, and my vague recollection of the process was download the ISO, convert to an image file, write image file to USB stick. However, as it’d been a few years, I went searching for references to make sure I had all the commands correct.

I found a lot of pages with a general summary of the process, and few with the specific steps. I tried one of those, but my USB stick didn’t work. The other specific pages contained the same basic process, so I was stuck. Until I found this page, which contained a critical step I was missing: Formatting the USB stick before copying the image file.

For future reference, here’s the precise process to follow if you want to burn an ISO file onto a USB stick…

(more…)

How to install ruby gems in Terminal

Rob Griffiths
Apr 26 '17
[Mac OS X Hints, Terminal, Unix]
3 Comments

In yesterday’s tip, See sensor stats in Terminal, I implied that installation of the iStats ruby gem was a simple one-line command. As a commenter pointed out, that’s only true if you already have the prerequisites installed. The prerequisites in this case are the Xcode command line tools. Thankfully, you can install those without installing the full 5GB Xcode development environment.

(Rather than starting from scratch, I’m just going to borrow this bit from my detailed instructions for installing the transcode-video tools, because the Xcode command line tools are required there, too.)

Here’s how to install the command line tools. Open Terminal, paste the following line, and press Return:

xcode-select --install

When you hit Return, you’ll see a single line in response to your command:

$ xcode-select --install
xcode-select: note: install requested for command line developer tools

At this point, macOS will pop up a dialog, which is somewhat surprising as you’re working in the decidedly non-GUI Terminal:

Do not click Get Xcode, unless you want to wait while 5GB of data downloads and installs on your Mac. Instead, click the Install button, which will display an onscreen license agreement. Click Agree, then let the install finish—it’ll only take a couple of minutes.

If you’re curious as to what just happened, the installer created a folder structure in the top-level Library folder (/Library > Developer > CommandLineTools), and installed a slew of programs in the usr folder within the CommandLineTools folder.

(more…)

See sensor stats in Terminal

Rob Griffiths
Apr 25 '17
[Mac OS X Hints, macOS, Macs, Terminal, Unix]
14 Comments

Someone—perhaps it was Kirk—pointed me at this nifty Ruby gem to read and display your Mac’s sensors in Terminal: iStats — not to be confused with iStat Menus, a GUI tool that does similar things.

Installation is sinmple, via sudo gem install iStats. After a few minutes, iStats will be ready to use. In its simplest form, call istats by itself with no parameters. Normally I’d list the Terminal output here, but istats (by default, can be disabled) presents informatiomn with neat little inline bar graphs, so here’s a screenshot:

This tool is especially useful on a laptop, as it provides an easy-to-read battery summary.

(more…)

Create Time Machine-like backups via rsync

Rob Griffiths
Apr 19 '17
[Mac OS X Hints, macOS, Terminal, Unix]
6 Comments

Taking a break from the recent Frankenmac posts, here’s a little trick for creating “Time Machine like” backups of anything you’d care to back up1I don’t know how well this might work for Mac files, as opposed to Unix files. But Mac files can be saved to the real Time Machine.. In my case, it’s the HTML files off of my web sites, both personal and work. I used to simply back these up, but then realized it’d be better to have versions rather than totally overwriting the backup each day (which is what I had been doing).

Once you’ve got it set up and working, you’ll have a folder structure similar to the one at right, with one folder for each backup, and a “current” link that takes you to the newest backup.

I get zero credit for this one; my buddy James explained that he’d been using this method for a year without any troubles, and pointed me to this great guide that explains the process.

I used that guide and added the following to my backup script to create my own customized Time Machine for the files from here, robservatory.com:

/usr/local/bin/rsync -aP \
  --link-dest=/path/to/quasi/TM_backup/current user@host:/path/to/files/on/server/ \
  --exclude "errors.csv" \
  --delete --delete-excluded \
  /path/to/quasi/TM_backup/back-$newtime
rm -f /path/to/quasi/TM_backup/current
ln -s /path/to/quasi/TM_backup/back-$newtime /path/to/quasi/TM_backup/current

And that’s all there is to it. Note that you may need a newer version of rsync than what comes with macOS now (2.6.9)—I use version 3.1.2 from Homebrew, so I can’t say for sure that this script works with the stock version.

I’ve only been using this for a couple weeks, but it’s working well for me so far.

Adjusting for the oddities of ctime

Rob Griffiths
Apr 13 '17
[Mac OS X Hints, macOS, Terminal, Unix]
Comments

In the shell script I use to back up my web sites (I really should update that, they’re much different now), I include a line that trims the backup folder of older compressed backups of the actual WordPress databases. That line used to look like this:

find path/to/sqlfiles/backups -ctime +5 -delete

I thought this should delete all backups in that folder that are at least five days old, via the ctime +5 bit.1Footnote: I know now I should have been using mtime, though it would have had the same issue I had with ctime. But it turns out I thought wrong. The above will delete all files that are at least six days old. Why? I don’t know why it works this way, but it’s mostly explained in the man page for find (my emphasis added):

-ctime n[smhdw]

       If no units are specified, this primary evaluates to true if the difference between the time of last change of file status information and the time find was started, rounded up to the next full 24-hour period, is n 24-hour periods.

       If units are specified, this primary evaluates to true if the difference between the time of last change of file status information and the time find was started is exactly n units. Please refer to the -atime primary description for information on supported time units.

To make find do what I wanted it to do, I just needed to change +5 to +5d. Simple enough…but while figuring this out, I stumbled across this page, which has an alternative solution with more flexibility:

find path/to/sqlfiles/backups -mmin +$((60*24*5)) -delete

The mmin parameter is much more precise than ctime:

-mmin n

       True if the difference between the file last modification time and the time find was started, rounded up to the next full minute, is n minutes.

By using mmin, I can be really precise. As shown, 60*24*5 gets me the same five-day interval as ctime +5d. (And yes, I could have used 7200 instead of 60*24*5, but I find it clearer to leave it in its expanded form.)

But I could instead delete backups that were older than 3.25 days (60*24*3.25 or 5040), or for any other arbitrary time period. I like the flexibility this offers over ctime, so I’ve switched my script over to this form.

The Robservatory © 2018 • Privacy Policy Built from the Frontier theme