macOS and scripting

Apple to Deprecate Scripting Languages in Future Versions of macOS - TidBITS

Apple says future versions of macOS won’t include a number of open-source scripting languages. The impact of this change will vary depending on the audience, but it will affect more people than you might think.

My visceral reaction was “WTF!! What the bloody f**k”. When I calm down, I’ll hopefully post a more reasoned response. For now, I’ll include some links and some quotes from around the web.

Before removing these scripting languages from macOS, Apple will need to address its own reliance on them. Xcode includes many libraries in all three of the mentioned languages, but it should be trivial for Apple to add the runtimes to Xcode’s already enormous install. iMovie includes a lone Perl script, and it wouldn’t surprise me if Apple’s pro apps like Final Cut Pro X and Logic Pro X also contain some.

In addition to Apple’s apps, macOS 10.14 Mojave contains over 175 scripts outside the folders devoted to Perl, Python, and Ruby. Some are a part of the language, just in a different place, but the rest serve varied purposes. Once I realized how many there were, it seemed much less likely that all three languages would be removed in the macOS version after Catalina. Curtis Wilcox

Could removing scripting languages from macOS hinder others from being interested in and learning to programme?

Are we going to ask that person to figure out how to install Ruby? If there are one-click installers out there, are we going to ask them to figure out which one is actually reputable and safe?

Curiosity like this is one of the ways new developers are made. I worry that the less the Mac is tinkerable out-of-the-box, the fewer developers we’ll get.

Or: we’ll only get certain kinds of developers — the ones of the right age and background who can go get a CS degree.Brent Simmons

Why is Apple making this change? Is this because Apple doesn’t like the restriction in the open-source GNU Public licenses compared to the MIT license? Is it because Apple sucks at security?

So the question is why? I can’t wrap my head around any real benefit to Apple’s line of reasoning on this. They’ve not been great about keeping the runtimes up to date, but that’s actually been a boon, requiring less effort to keep scripts working with every OS release. These runtimes were even touted as a selling point in the past, and Microsoft is just now starting to add tools like this to the default Windows install. And they’re including a sexy Terminal. So why is Apple moving in the opposite direction?

My only guess is that it’s directly related to the iOS-ification of macOS. iOS is based on Unix, just like macOS, but scripting runtimes have never been included (nor are they installable without bundling). So, security? A higher wall on the garden, one more easily controlled? It can’t be about file size, nor complexity for the everyday user. It doesn’t affect either in any measurable way. I don’t have an answer to this question yet, and I don’t know that we’ll ever really get one.Brett Terpstra

UPDATE: I have had some time to consider this for a cyber-security perspective. Apple's decision to remove deprecated versions of scripting language and other *NIX tools will make macOS more secure. Users who need these tools can install them. It's part of the learning for the system. If a user is curious and confident enough to launch Terminal and poke around the macOS system, that user can figure out how to install Homebrew.

HDR photography with Raspberry Pi and gPhoto2 - Revision 2

This project allows you to create bracketed images for HDR photography using the Raspberry Pi, a supported DSLR camera connected via USB, and the gphoto2 Unix tool.

Project Overview

Last August, I initiated a project aimed at using a Raspberry Pi for bracketed image capture, intended for High Dynamic Range (HDR) photography with my Nikon D40. The initial version had limitations: it necessitated manually connecting the Raspberry Pi and waiting for the script execution to complete.

After rigorous testing, I have developed a more refined, Perl-based solution. This work is an amalgamation of several other projects and contributions, including those mentioned in the comments of my previous post.


I gained valuable insights from Zach Dwiel's gphoto2-timelapse project, which is written in Python. I adopted the startup script and usbreset methodologies from his work.

For understanding Raspberry Pi's GPIO functionalities, WiringPi was instrumental. Additional help came from this diagram and code on the TNET Raspberry Pi site, as well as information found on the RPi low-level peripherals page.

Technical Details

The project uses a Raspberry Pi, a supported DSLR camera, and the gphoto2 software. My Perl script refines an earlier BASH version to simplify the process.

  1. Compile WiringPi to control the GPIO pins.
  2. Install usbutils to get lsusb, a utility for monitoring USB connections.
  3. Compile usbreset to manage the camera's USB interface effectively.

Running the Script

After fulfilling the requirements, you'll need to adjust the script for your camera specifics. Use lsusb to identify the USB ID for your camera and locate appropriate gphoto2 parameters. Then, initiate the Perl script using perl

There's also an rc script for auto-starting the HDR script when the Raspberry Pi is powered on.

Final Thoughts

The script comprises one main loop and four functions. While the system is operational, there are still some inefficiencies; notably, gphoto2 takes about 5 seconds to initialise. Potential improvements could involve creating Perl bindings for the gphoto2 library or rewriting the program in C, although I generally avoid strongly typed languages.

By sharing this project, I hope to contribute to the broader discourse on Raspberry Pi and HDR photography, while also opening the door for collaborative problem-solving and further refinements.

You can find all the code on GitHub.