Never really use the "Paste Line to Paste Bin" command, but after noticing the blog entry (and how much it's improved lately) I figured I'd give it a shot. Not working quite right, though--it looks like something is appending "1" to the URL for the paste.
I highlight some text, select the command, and whether I choose "Copy to Clipboard" or "Open in Browser," I get the same URL: <http:// pastie.caboo.se/15121>, rather than the correct <http:// pastie.caboo.se/1512>.
Any ideas?
-- Chris Biagini http://assortedgeekery.com/
On 19/6/2006, at 5:27, Christopher Biagini wrote:
[...] I highlight some text, select the command, and whether I choose "Copy to Clipboard" or "Open in Browser," I get the same URL: http://pastie.caboo.se/15121, rather than the correct http://pastie.caboo.se/1512.
Any ideas?
Nope, nothing I can reproduce. Has others experienced this?
On Jun 19, 2006, at 6:38 AM, Allan Odgaard wrote:
Nope, nothing I can reproduce. Has others experienced this?
I've figured *something* out, but what it means, I have no idea.
The call out to curl in paste_to_pastie.rb works perfectly when I execute it in Terminal. Further, when I store the output of that call to a variable, then write it to a file, the URL is, again, perfectly correct.
Still, somehow AppleScript is getting an extra "1" thrown in there, because it's there even if I immediately `display dialog` after the `do shell script` call to paste_to_pastie.rb.
But what fixes the problem, and this is the part I don't understand, is that if I store the output from curl, then print it after the calls to `File.unlink()`, then everything works perfectly, every time. (Which doesn't make sense to me, since if `File.unlink()` was somehow spitting out 1's, why isn't there a "1" at the *beginning* of the URL now?)
I even completely replaced the TM bundles with the latest from SVN and it still happens.
-- Christopher Biagini http://assortedgeekery.com/ puevf.ovntvav@tznvy.pbz (Rot13 to descramble)
On 20/6/2006, at 2:43, Christopher Biagini wrote:
On Jun 19, 2006, at 6:38 AM, Allan Odgaard wrote:
Nope, nothing I can reproduce. Has others experienced this?
I've figured *something* out, but what it means, I have no idea. [...]
Do you have Fink installed?
And, could you try to change the script to:
text_file, html_file = `/usr/bin/mktemp -t tm_paste && /usr/bin/ mktemp -t tm_paste`.split("\n")
[...] (Which doesn't make sense to me, since if `File.unlink()` was somehow spitting out 1's, why isn't there a "1" at the *beginning* of the URL now?)
The problem might be, that the last unlink fails, making the script fail (with error code 1) and AS then “reports” that.
Placing a print below the unlink would make the result from that, the result of the script, making it not fail.
So the question is, why unlink fails. We’ve had two cases of “my mktemp doesn’t work like the standard when given -t,” my thought is that you might be a victim of this, although this manifested itself differently for the user others, these got the problem in the actual shell part, but not in the ruby part -- however, this could be a difference in PATH, as the one has the bash PATH, the other the Finder PATH -- one could have the standard mktemp first in the path, the other last.
On Jun 19, 2006, at 9:03 PM, Allan Odgaard wrote:
Do you have Fink installed?
No, just DarwinPorts.
And, could you try to change the script to...
No change.
So the question is, why unlink fails...however, this could be a difference in PATH, as the one has the bash PATH, the other the Finder PATH -- one could have the standard mktemp first in the path, the other last.
Hm. "which mktemp" gives /usr/bin/mktemp in both Finder and TextMate.
Interestingly, I just noticed the command works fine on my PPC Mac (it fails on my MBP).
-- Christopher Biagini http://assortedgeekery.com/ puevf.ovntvav@tznvy.pbz (Rot13 to descramble)
On 20/6/2006, at 3:28, Christopher Biagini wrote:
Interestingly, I just noticed the command works fine on my PPC Mac (it fails on my MBP).
Could you try comment the two unlink’s and then instead do:
puts text_file, html_file
That should reveal which tmp files where created, then check if these exists, if they have a weird mode, and if you can delete them from shell.
On Jun 20, 2006, at 12:25 PM, Allan Odgaard wrote:
That should reveal which tmp files where created, then check if these exists, if they have a weird mode, and if you can delete them from shell.
$ pwd /tmp $ ll tm_paste.* -rw------- 1 chris wheel 7 Jun 20 23:46 tm_paste.2L9hKC8f -rw------- 1 chris wheel 188 Jun 20 23:46 tm_paste.yMZIOtLe $ rm tm_paste.* remove tm_paste.2L9hKC8f? y remove tm_paste.yMZIOtLe? y $
So they deleted just fine. Anything about the above jump out as strange?
Appreciate the troubleshooting effort, by the way.
-- Christopher Biagini http://assortedgeekery.com/ puevf.ovntvav@tznvy.pbz (Rot13 to descramble)
Okay, well, I feel pretty dumb now. Ran svn update on the Support folder and all is well. Never even crossed my mind until I noticed your suggestion to do so in another thread.
Sorry, Allan. Thanks for the help.
-- Christopher Biagini http://assortedgeekery.com/ puevf.ovntvav@tznvy.pbz (Rot13 to descramble)
-
Allan Odgaard -
Christopher Biagini -
James Edward Gray II