The “subl <some file>” command gives me a blank window

[Nate]

Another user originally reported this on the General forum.

I am having the same problem and I think it belongs here in Technical Support so (hopefully) the devs will see it.

The “subl” command doesn’t work for me unless I already have a ST2 window open.

If I issue “subl <anything>” and there is not an ST2 window open, I get a blank untitled window and a message like the following is logged:

Code: Select all

2/24/12 1:12:09.002 PM Sublime Text 2: *** -[NSMachPort handlePortMessage:]: dropping incoming DO message because the connection is invalid

Scenarios:

• App is not running. Type “subl <some file>”. Result: blank “untitled” window
• App is running but no windows are open. Type “subl <some file>”. Result: blank “untitled” window
• App is running and at least one window is open. Type “subl <some file>”. Result: success

Things I have tried:

• restarting
• rm'ing and re-creating my “~/bin/subl” symlink.
• deleting my “~/Library/Application Support/Sublime Text 2” folder (i.e., stock configuration)

I am using Lion 10.7.3 and ST 2 build 2181.

This old message on cocoa-dev (by Apple employee Chris Kane) indicates that errors of this kind can be caused by timing-specific race conditions that can vary between machines. So, in case it matters, my configuration is: MacBook Pro 15-Inch, Mid 2010, 2.66 GHz Core i7, 8 GB RAM, GeForce GT 330M 512 MB. 500 GB Hitachi HDD (not SSD).

[pdclark]

I had the same issue issue for months, but subl -a resolves it for me. To save on the extra typing, I added this to my ~/.bash_profile, then use sub instead of subl:

Code: Select all

alias sub="subl -a"

[UloPe]

Hi,

I have a very similar problem. For me the scenario is as follows:

• Sublime not running, subl <file/dir> -> opens as expected
• Sublime running, no windows open, subl <file/dir name> -> empty window with the above mentioned message in console
• Sublime running, at least one window open, subl <file/dir> -> opens as expected

The mentioned "subl -a" workaround doesn't change the situation for me (i.e. it still doesn't work).

Edit:
I'm running Mountain Lion 10.8.2 (but have had this problem at least since 10.8.0, not sure if it was present on 10.7.x)