I’ve got some data I’m trying to get off my Newton and writing a bit of Newton code to bridge some gaps seems like my best bet at this point, so I found myself setting up a Newton dev environment… again. An old Mac still seems like the best dev environment after all these years (with the most documentation, examples, and other resources, anyway). I have literal piles of old Macs, but neither the time nor space to set one up for such a task right now. The quickest route was to re-install & configure BasiliskII (a great 68k Mac emulator), incl. installing MacOS 7.x and the Newton dev tools (innumerable thanks to everyone who contributed to the excellent NewtonDev disk image).
Back in 2013, I hacked together (and silently released to GitHub) a set of command line utilities for working with OS X file ACLs (Access Control Lists) and ACEs (Access Control Entries), collectively named acl-tools-osx. Included are three utilities written in bash:
It’s amazing how quickly the years flow by and that it’s been nearly 25 of them since the introduction of Apple’s Newton. Actually, it has been a full quarter century since John Scully, then CEO at Apple, was pitched the concept of a smaller, handheld device by Michael Tchao and decided to make it a reality. This week marks the 23rd anniversary of the MessagePad’s release on August 3rd, 1993, at MacWorld Expo in Boston, which Scully had initially previewed to press at CES in Chicago, back on May 29th of 1992. Crazier still, the release of the Newton came less than a decade after that of the Macintosh. Sadly, it never really got the chance to see its full potential.
Now that I’m independent and posting more frequently, I’ve joined the iTunes Affiliate Program to help the site earn its own keep. I host this site on Textattern, an excellent, light weight, and very flexible CMS (Content Management System) and—wanting to work smarter, not harder—decided to write a plug-in that could automatically rewrite any iTunes/iBooks/App Store affiliate URL I post in an articles using my iTunes Affiliate Program ID. This will make it easier to just copy links to music, books, or apps from the appropriate store and not have to run them through a different tool to appropriately tag them to hopefully earn a little commission.
After nearly thirteen years, many months of agonizing personal deliberation, and three further months of attempting to wrap up projects as cleanly as possible, June 1st marked my departure from Small Dog Electronics. Finding myself in utter burnout was not an easy reality to come to grips with, and deciding to make such a large change was downright scary, but everyone stood by me and I believe we’re all going to better off for it.
thedailyjaws referenced the “Jaws” movie crew having nicknamed the prop sharks “Bruce”. Upon reading that, it suddenly hit me that it must be the reason that the great white shark in Pixar’s Finding Nemo was named “Bruce.” Or another reason, anyway. I had always assumed that it was just because it’s a stereotypically Australian name.
As you probably now know, Google is shutting down Google Code in less than a year and are encouraging users to switch to other open source hosting platforms such as GitHub. They have a handy Export to GitHub tool, which is easy, if a bit slow. I had a couple stale projects on Google Code that I hadn’t moved to GitHub yet, so I gave the tool a shot.
When I last touched on my Twitter badge’s future, I noted that Twitter was giving us roughly six months before they shuttered v1.0 of their API which was all that was keeping my Twitter Statuses JavaScript Badge alive. They actually gave us eight months, but finally completed the API v1 retirement on June 11th 2013 and my Twitter Statuses Badge functionality ceased along with it.
In mid-August, Twitter announced there would be big changes coming in v1.1 of their API which they then released at the beginning of September (officially deprecating the v1.0 of their API). Well, three days ago my Twitter Statuses JavaScript Badge stopped working on all my sites and everyone else’s that uses it too.
I’ve been playing with NewtonScript a bit in what little spare time I have, hence the previous posts on the subject. The eventual plan, of course, is to put together a few new packages for my MessagePad 2100, maybe even something useful to others, but in the meantime I just want to get comfortable with the language. For that, I’ve found playing with NEWT/0 to be the easiest, but, while the core is there, a number of the built-in functions are still missing.
Shortly after my recent post of a realpath implementation in bash my friend David Kendal suggested a C implementation would be preferable. I have to admit, it’s far simpler code, it wraps around the actual realpath() so no work to make it functionally equivalent, and it’ll be immensely faster (although I haven’t benchmarked it). See his example implementation. I really can’t agree more.
I was recently informed of an issue with the in-development version of trash (one of the utilities in tools-osx) that required using an absolute path internally instead of a relative path. In most languages one can just run a path through realpath() to get the absolute path for a relative path, but bash (which trash was developed in) doesn’t have an equivalent. Many people suggest readlink, but it’s generally only included in Linux distributions, so BSD-based operating systems (incl. Mac OS X) are a bit out of luck.
To expand upon my previous post demonstrating how to access command line arguments (ARGV) in NewtonScript in NEWT/0, I’ll demonstrate how to access environment variables. Command line arguments are only the beginning for writing command line tools as you often need to access environment variables as well. In some situations, like running a script as a CGI in your favorite HTTP server software, environment variables are really your only way to receive input from the outside world.
Still being a daily Newton user as well as a developer, I’ve always wanted to learn NewtonScript. I’ve got a PowerMac 9500 that’s been configured for Newton OS development for quite some time and I’ve got a couple projects in mind, but I just never seem to get around it.
Or, this should’ve been done nine months ago.
I’ve updated my collection of Mac OS X command line tools with improvements to the trash tool:
I’ve got a very minor update to the sde_newsletter Textpattern plug-in. v0.5 word-wraps HTML & text content in message/part bodies to 78 characters (if possible) to prevent hard wrapping at 998 characters which tends to badly break HTML content.
There’s been a small addition to my collection of Mac OS X command line tools:
I’ve been doing a lot of early morning coding in bed, and have found that the only way I can do so without killing my eyes is to select “Use grayscale” as well as “White on Black” in the Universal Access preferences pane in System Preferences. This gives me a far more comfortable, inverted grayscale display. Unfortunately, it’s annoying and painful to initially set when my eyes are at their most sensitive.
I’ve got a new release of my collection of Mac OS X command line tools for you, including:
I’ve just released Twitter Statuses JavaScript Badge v0.7 which includes the following improvements:
While cleaning up some old bash code and preparing tools-osx for release, I happened across a very useful bit of information: bash does support regular expressions! Well, at least bash 3.0 and newer do.
Ever since Mac OS X was released, I’ve found myself working via the command line more and more every year. While there are some native commands like open, pbcopy, and pbpaste with NeXTSTEP roots which help one switch back and forth between the CLI & GUI, I’ve always found a few gaping holes.
As usual, a couple days after the latest release of my Twitter Statuses JavaScript Badge and I’ve already discovered important changes that need to be released. Unlike last time, I’m not going to wait another year.
