I’ve struggled with a long-standing bug that causes the Sublime Text 2 command-line launcher to fail sporadically. In order to use the command-line launcher, the documentation directs you to create a symbolic link to the command-line utility stored in the application bundle:
Then, assuming you have a bin directory in your home directory, and it’s in your path, you can open files in ST2 from the command line:
The problem is that the
subl command is buggy. If ST2 isn’t running, or if it is running and
there’s an open window, everything works well. The file is opened and it appears in a new tab.
But, if ST2 is running and doesn’t have any open windows, the
subl command will silently fail.
ST2 will open a blank window with no tabs and no content.
There’s a simple hack that gives you 90% of what you want from the
subl command. You can create
an alternate command that works 100% of the time to open files. Create a one-line shell script
that looks like this:
Save it wherever you like and use that script to open files. This isn’t a replacement for the
subl command. That command supports command-line arguments like ‘-w’ to allow ST2 to be used
as an editor for Git and other tools. This script is purely for opening files from the
Alfred 2 will be coming out soon. It’s big new feature is the ability to easily create “workflows”, plug-ins that extend Alfred’s capabilities.
I’ve been having a lot of fun creating new workflows and extending the work of others. The workflows are in my GitHub account for anyone interested in forking or examining them.
I needed to create a small, self-contained web application that could be run from the command-line. I’ve been using Grails a lot lately so I looked into the plugins available. There were two that fit the bill, the Jetty standalone plugin and the Standalone App Runner plugin.
Initially I used the Jetty plugin simply because I found it first. It works but has a significant drawback, Jetty unpacks the entire WAR file before running the application. On the Windows box it was being used on this takes several minutes before the application starts. In addition, once I upgraded the application to Grails 2.0.1, the Jetty plugin broke. So I looked into alternatives.
The Standalone App Runner plugin uses Tomcat 7 as an embedded application server. It bundles your application into a standard WAR file and then builds a jar file that contains embedded Tomcat and your application’s WAR file. Unfortunately, the plugin isn’t working correctly. Your application will start cleanly but the first time a web page is accessed you’ll see this error:
The problem is that the tomcat-embed-logging-juli dependency isn’t present in the embedded Tomcat wrapper. Luckily the fix is easy.
After upgrading to Lion from Snow Leopard, I ran into an immediate problem running unit tests for an application that uses JasperReports. JasperReports makes use of AWT and Swing regardless of whether the application calling it has a GUI interface. Normally this isn’t a problem, and it wasn’t a problem in Snow Leopard, but it has become one on Lion.
The error I received was:
The issue is that when the unit tests run, JasperReports tries to instantiate a Swing control and the Java run-time tries to initialize the default Apple Look-and-Feel. I’m not sure whether Lion has secured access to that (preventing unsigned applications from using it) or whether there’s another configuration issue in Lion. Regardless, the fix is simple for my purposes.
The Java default look-and-feel can be overridden at the command-line using a Java property:
That will switch the Java instance from using the Apple Look-and-Feel to using Metal. BTW, running “headless” won’t fix the problem. Headless means telling the Java runtime not to make use of the GUI.
If you’re using Maven you might find that your unit tests still aren’t working, in that case, you need to tell Maven to pass the properties down to sub-processes:
And, in case you’re wondering why you would want to run headless, it keeps macOS from treating your command-line app as a GUI app if it uses AWT or Swing. The property to trigger headless operation is:
Once upon a time, I did all my development in Linux. It was quite nice: I did my editing in vim and sometimes Eclipse, I typed commands into a terminal window, and managed my software using apt. I was fairly happy with this setup.
With time though, I started to feel the pain of dealing with Windows and its users. I needed to use Microsoft Office for 100% compatibility, suspend and restore reliably, access Exchange without issues and use software that didn’t look like it’s UI was designed by a kindergartner.
So, I abandoned Linux and tried to make Windows work. The command-line was hell, the development tools stunted and broken and it looked even worse then Linux. But I could get Office, and my Exchange issues were gone.
When the pain became unbearable, I went off the reservation and decided to try using macOS. At first it was a complete pain. The copy and paste keys were different! That’s just change for change sake, right? Until the first time I did a copy and paste in a terminal window and realized the keys didn’t conflict with Ctrl-C.
The window handling just worked. I wasn’t playing around with the window manager du jour and thanks to excellent text editors like TextMate and BBEdit, I didn’t have to deal with vim anymore. And, even better, Terminal.app was pretty good. And if I didn’t like it, there was iTerm and now iTerm 2.
I needed a very simple mechanism to perform a gender sanity check on a first name to promote error checking on data entry. After some quick Google searches I compiled a consolidated list of first names and the probable gender of the person with that first name.
This method is obviously error prone. It is not intended to be a 100% validation of a gender based on the first name, it’s intended to be used as a red flag when checking a given gender against a given first name.