For months I’ve been plagued with a frustrating and inconsistent problem: drag & drop and copy/paste randomly decide to stop working in Rapid Weaver, with a cryptic error reported to the system log:
This issue has prevented me from being able to work on adding drag & drop file uploads / downloads to Convoy, and thwarted my attempts to work on secret project.
After fruitless research into the issue, I performed a clean install of Mountain Lion, and my initial testing made me think the issue was solved. Due to circumstances beyond my control, I did not get a chance to work on Convoy or secret project until recently.
The first thing I noticed tonight, when I did finally get started, was that the problem was back. Again, I failed to find a solution online. I considered the times that the broken functionality had worked, and those times that it didn’t. One difference came to mind – when didn’t work, I had opened Rapid Weaver from the terminal. Times I remember everything working; Rapid Weaver had been opened normally. Experimentation proved this. Eureka!
A Delicious Workaround
Finally able to start work, it struck me that I’d be developing without the golden joy that is having console output. I solved this issue by using
tail, and two
Terminal tabs . To do this, open Rapid Weaver in one tab :
$ nohup /Applications/RapidWeaver.app/Contents/MacOS/RapidWeaver > RW.log 2>&1
And in the second, follow the logfile:
$ tail -f RW.log
Whatever would normally be output into the first
tab is written to the log file, and will therefore be displayed in your second tab .
: after mentioning this issue on Twitter, @passcod noted that this sort of issue may arise when using
tmux instead of the basic shell (which I do use). Further experimentation proved him correct, but none of the suggested fixes that I tried from those suggested here: Unable to use pbcopy while in tmux session allowed me to use Rapid Weaver without problems when started from within a tmux session. I use a custom .zshrc file on computers I control, which automatically enters a tmux session when a Terminal opens, so instead of closing my tmux session before opening Rapid Weaver from the Terminal, I will continue to use the workaround described above.
And thus a frustrating issue that has irritated me for too long is wrapped in a workaround. Have you encountered a similar issue? How did you get around it in your situation?