Parsing date strings in Shortcuts

I didn’t realize until today that Shortcuts has a date parser. It doesn’t call itself a date parser, and the documentation doesn’t explain what kinds of text strings it can parse, but it’s Shortcuts, so what would you expect?

I found it more or less by accident as I was writing a shortcut similar to this one from a few months ago. Last year, I switched from monthly contact lenses to semi-monthly. They’re thinner, more comfortable, and settle in place almost immediately.1 But without a big, obvious change in the calendar, I’ve found it harder to remember to change them in the middle of the month. On the plus side, I’ve inadvertently learned that I can wear them much longer than 15–16 days with no ill effects.

Based on this experience, I’ve decided I should switch them out every three weeks. Again, this is not a schedule I’m going to remember on my own, so I built a shortcut to run on the night I throw a set of lenses away. It adds an event to my personal calendar to remind me to throw the next set away in three weeks.

I expect to run the shortcut at any time of day, possibly even the next morning when I open up a new set of contacts. But I want the event—and the alert associated with it—to be at a particular time in the evening. This means I can’t get the date and time of the event by just adding three weeks to the date and time at which I run the shortcut. And I certainly wasn’t going to force myself to use those idiotic spinners to set the time—the time is fixed and the shortcut should handle it automatically.

StepActionComment
1 Get the date I threw away the last set of contacts. This should be the current date, but I allow an adjustment in case I run this the next morning.
2 Create a text string with the date from Step 1 and a time of 9:00 pm. The format of Provided Input is shown later in the post.
3 Here’s the parsing step. It turns the date string from Step 1 into a date/time combo.
4 This is the date/time for the calendar event. The magic variable for this step is called End Date.
5 If I throw the contacts away on the date set in Step 1, I start wearing a new set a day later. This magic variable is called Start Date.
6 Here we create a new calendar event for throwing away the next set of contacts. There’s an alarm and some information in the Notes field.

Here’s how the Provided Input date is formatted:

As I said at the top, I don’t know all the formats the step can parse, but I figured yyyy-mm-dd HH:MM:SS would work, and it does.

Most scripting languages I’ve used have a way to change some date/time fields while leaving the others untouched, but Shortcuts apparently doesn’t. I was searching and scrolling, trying to find such a command, when I ran across . It does the job.

Why don’t I just set up an event that repeats every three weeks? Mainly because of my poor experience with doing that for switching out my CPAP supplies: the real world often intervenes, forcing you to change your carefully planned schedule. I find it easier to run a shortcut than to reset a recurring event. If I find that my contact lens schedule doesn’t change after several months of using this, I’ll switch to a long-running recurring event.

Update Sep 12, 2020 7:27 AM  An updated shortcut, with a different way of setting the time and a workaround for a Shortcuts bug, is here.

1. I have astigmatism, so my contacts aren’t axisymmetric; they have to be oriented a particular way to work. They’re weighted to help them spin around to the right angle. When I was wearing monthlies, the right contact would usually take at least five minutes to rotate to the correct position and sometimes wouldn’t settle in for half an hour or so.

A battery BitBar bonanza

I started reading this thread on the Keyboard Maestro forum because I’ve been interested in the Stream Deck (yes, that’s an affiliate link) for a while and will probably be getting one soon. I kept reading because TJ Luoma’s answer made me realize I didn’t need the Stream Deck to use the ideas in his solution; it would work just as well with BitBar.

The idea is to use the output of ioreg to get the battery levels of the keyboard, trackpad, and mouse, and to then use that information to tell the user it’s time to recharge. You may be thinking, “isn’t that what the low battery notifications are for?” Yes, but the problem is those notifications always seem to appear when you’re in the middle of work and don’t want to be interrupted. The idea behind a notice on your Stream Deck or in your menu bar is that you don’t need to dismiss it to get back to work, and it’s still there to remind you when you have time to plug in or change batteries.

As a practical matter, I couldn’t just tweak TJ’s solution to make it work with BitBar. TJ is a shell scripting wizard, and his script is strong evidence of that. Although I can follow the logic of what he’s doing, I would never feel comfortable trying to adjust it to my needs. So I took his ideas, rewrote them in Python, and added the parts necessary to drive BitBar.

The script, or plugin, as BitBar likes to call it, is batteries.1h.py, and it gives me a menu bar item that looks like this:1

When one of the input devices gets low on battery, the menu bar icon changes from a battery,🔋, to a plug, 🔌, to tell me its time to plug in. And if I ever connect an I/O device that isn’t a keyboard, trackpad, or mouse, the icon will change to a joystick, 🕹.

Here’s the source code of batteries.1h.py

python:
1:  #!/usr/bin/python3
2:
3:  import subprocess
4:  import re
5:
6:  # Initialize
7:  limits = {'keyboard': 20, 'trackpad': 15, 'mouse': 15}
8:  deviceTypes = limits.keys()
9:  anyLow = False
10:  anyOdd = False
12:
13:  # Regexes for capturing product names and battery percentages
14:  productRE = re.compile(r'Product" = "(.+?)"')
15:  batteryRE = re.compile(r'"BatteryPercent" = (\d+)')
16:
17:  # Capture the output of ioreg. Remarkably, the output is
18:  # encoded in MacRoman, which will rear its ugly head if a
19:  # device has a name like Drang’s Mouse (w/ curly apostrophe).
20:  cmd = 'ioreg -r -k BatteryPercent'.split()
21:  ioreg = subprocess.check_output(cmd).decode('macroman')
22:
23:  # The ioreg output is a series of paragraphs, one for each
24:  # product. Go through each, looking for low batteries and
26:  # printed in red; weird results, like unknown devices and
27:  # missing battery percentages, are printed in purple.
28:  for p in ioreg.split('\n\n'):
29:    productMatch = productRE.search(p)
30:    batteryMatch = batteryRE.search(p)
31:    if productMatch and batteryMatch:
32:      name = productMatch.group(1)
33:      battery = int(batteryMatch.group(1))
34:      device = ''
35:      for d in deviceTypes:
36:        if d in name.lower():
37:          device = d
38:          break
39:      if device:
40:        if battery < limits[device]:
42:          anyLow = True
43:        else:
45:      else:
47:        anyOdd = True
48:
49:  # BitBar output
50:  if anyLow:
51:    print('🔌')
52:  elif anyOdd:
53:    print('🕹')
54:  else:
55:    print('🔋')


The key to this was the recognition that the output of

ioreg -r -k BatteryPercent


can be thought of as a series of paragraphs, one for each I/O device with an entry named BatteryPercent. The script captures the output of this command in Line 21, splits it into paragraphs on Line 28, and extracts the product name and battery level for each device. This information is used to construct the multiline text output in Lines 50–56 that BitBar parses to assemble the menu.

One weird thing I found while writing this script is that ioreg uses the old MacRoman text encoding for its output. Both of my devices used possessives in their product names, e.g., “Dr. Drang’s Trackpad,” and the curly apostrophe has a byte value (in hex) of 0xD5. When I first started looking through ioreg’s output, I saw that this was rendered in my terminal as “Dr. DrangÕs Trackpad,” because 0xD5 is Õ in UTF-8 (and Latin-1). Thus the call to decode('macroman') in Line 21. I realize updatingioreg is not one of Apple’s most pressing concerns, but it’s been two decades, Craig. None of Apple’s command line utilities should be spitting out MacRoman anymore.

I must note that TJ’s script is more tolerant of unusual output from ioreg than mine is and handles it in a more granular way. I flatly ignore certain useless outputs, because I just don’t think they’ll ever show up. It’s part of my devil-may-care personality.

Anyway, this was a fun exercise, and I now have another potentially useful item in my menu bar. It’ll be months before I know whether I take heed of this warning, but one thing I do know is that I’ve been dismissing low battery notifications for years; a warning in the menu bar has to be better than that.

1. Yes, I’m also using the air quality BitBar plugin that Jason Snell wrote a few days ago.

RSS and the pleasure of not thinking

I listened to the recent Mac Power Users episode on RSS while on a long walk the other day, and I really enjoyed it. Partly, of course, because I just like listening to Stephen and David, but mainly because I didn’t feel I had any stake in it.

As I’ve mentioned here several times, I have a homemade system for reading RSS feeds. And although I am willing to switch to a different setup, that different setup would have to be a tremendous improvement. Here are the advantages of what I have:

• On the reader side, it looks the way I want it to look because it’s just an HTML page that I wrote. There are no buttons or toolbars on-screen except the ones I want.
• It always gives me up-to-date articles. In my experience,1 some RSS aggregator services don’t poll sites often enough (or use WebSub) to keep up with edited articles. So what you get from the aggregator may not be what the article currently says. My system updates every 20 minutes, so I don’t miss edits unless they’re very recent.
• I don’t have to think about moving to a new aggregator because the one I’m currently using just went out of business or decided to increase its subscription fee. Or because an aggregator I’m not using just reduced its fee.
• I don’t have to think about switching readers for all those same reasons.

Honestly, it’s the “not thinking” part that’s the best. Over the 35 years I’ve been a computer user, way too much of my time has been spent thinking about the “right” software to buy. Some of this has been forced on me—when an app or service stops working, there’s no way to avoid thinking about the alternatives—but a lot has been self-inflicted. It’s nice to have one part of my computing life that’s stable and should continue to be stable for years to come.2

In some ways, I suppose, listening to Stephen and David talk about RSS was akin to schadenfreude. I could walk along, smug in the knowledge that I wouldn’t be balancing the upsides and downsides. I could just turn off my mind, relax, and float downstream.

1. My experience is, admittedly, now well out of date, as I haven’t looked into aggregators in several years. I suspect stale articles aren’t much of a problem if you use one of the big, popular aggregators.

2. Was the time I spent writing my RSS scripts more than the time I would now spend thinking about the “best” RSS aggregator and reader? Doesn’t matter. I enjoyed writing the scripts. I learned new things and got satisfaction out of seeing them run correctly. I get nothing like that out of comparing apps and services.

A new old Python

You may have noticed something new in yesterday’s scripts: the shebang lines were

#!/usr/bin/python3


I’ve been using Python 3 for quite a while, but it’s been a version installed through Anaconda, not one that came from Apple. The reasons are

1. Apple didn’t provide a Python 3 until Catalina; and
2. I didn’t install Catalina on either of my Macs until this past month.

I intend to keep using the Anaconda-installed version as my regular Python because its environment has all the tools I regularly use in my work: NumPy, SciPy, Pandas, and Matplotlib. But the BitBar scripts were a good way to try out Apple’s Python 3; they needed Python 3’s UTF-8 support1 and didn’t need any of those math/science libraries.

While I said above that Apple provides Python 3 in Catalina, that may be stretching the definition of “provide.” If you look in /usr/bin, you’ll find something called python3, but that something may be just a placeholder. If you haven’t installed the Command Line Developer Tools, trying to execute a script via /usr/bin/python3 will get you an error message about an “invalid active developer path.” This happened to me on one of my Macs; presumably, the CLDTs had already been installed on the other Mac and were updated when I switched to Catalina.

If you need to install the CLDTs, this explanation by Flavio Copes of how to do so via the xcode-select command is clear and concise. Once you’ve done so, you can test your new Python 3 by running

/usr/bin/python3 --version


at the command line. You should get Python 3.7.3 as the response. This was the version released over a year ago, which means its remarkably fresh for an Apple-supplied command-line tool.

If you need to install third-party libraries, as I did with the Mechanize and BeautifulSoup libraries used in my library BitBar script, you’ll have to run the Python 3 version of pip like this:

/usr/bin/pip3 install mechanize


You’ll probably get a warning that your version of pip isn’t up to date. As with Python 3 itself, the pip` that comes from Apple is over a year old. It’ll still work.

As I said earlier, I don’t expect to be using Apple’s Python 3 in the future, but it’s nice to see that Mac users can use a modern Python without resort to third-party systems like Homebrew or Anaconda.

1. OK, they didn’t need UTF-8 support, but I did. I’m too old to keep doing the encode/decode dance