Am I having encoding trouble with this script?

Question

Level 1

0 points

Am I having encoding trouble with this script?

G'day,

I have a simple applescript, intended to get the title and url from current webpage in order to log to a text-based journaling app called Day One:

set out_file to "/Users/home/.tmp_dayone"  

tell application "Safari"           
     set current_tab to current tab of front window           
     set tab_name to name of current_tab as Unicode text           
     set get_url to URL of current_tab as Unicode text 
end tell  


set text_out to "Read on the Web:  " & tab_name & " " & get_url & " " as Unicode text
set out_file_ref to open for access POSIX file out_file with write permission 
try   
     write text_out to out_file_ref 
end try 
close access out_file_ref  


try           
     do shell script "usr/local/bin/dayone new < " & out_file 
end try  


delay 0.3  

try   
     do shell script "rm " & out_file 
end try

The script is obviously not very robust but mostly works. However...

...At this page http://www.ppowgallery.com/selected_work.php?artist=25 the

name of current_tab

returns this title:

"P·P·O·W | The Estate of Martin Wong | Selected Text"

Saving this to a text file and asking a shell subprocess to write a new DayOne entry from the .txt, only creates a blank entry in the journal. And I can't figure out why!

If I use less at the terminal I can see that the ' · ' character is written as '<E1>' in the .txt. Is this what is causing the problem? If I enter

file -I .tmp_dayone

at the terminal the response says the file is ISO-8859-1 encoded. I don't know if any of this is relevant; I am an amateur at all of this stuff.

Why wouldn't applescript be writing to a file as 'UTF-8" ?

Cheers!

MacBook Pro, OS X Mountain Lion (10.8.3)

Posted on Apr 23, 2013 6:15 AM

Reply

Answer 1

Apr 23, 2013 7:17 AM in response to Wagringo

Is this a transcription errror or is that really the path for thr command?

try

     do shell script "usr/local/bin/dayone new < " & out_file

end try

If the path is wrong having it in a try block with no on error part is just eating the error.

Reply

Answer 2

Wagringo Author

Level 1

0 points

Apr 23, 2013 7:19 AM in response to Frank Caggiano

The path is correct.

The script works for most pages I have tried so far, just not the one linked to above.

Reply

Answer 3

Apr 23, 2013 7:26 AM in response to Wagringo

Bizarre so the dayone program is not in /usr/local/bin (the usr directory at the root of the drive) but in usr/local/bin? And where is usr/local/bin?

Also having the command in a try block with no error part is a problem.

Actualy loking at it all your try blocks have no error part. Why? if a command fails the error is eaten and the script continues wiht no indication that something happened.

Reply

Answer 4

Wagringo Author

Level 1

0 points

Apr 23, 2013 7:34 AM in response to Frank Caggiano

Sorry Frank, I missed the leading '/' there! The script has the correct path, and I have edited this block:

try
          do shell script "/usr/local/bin/dayone new < " & out_file
on error
          display dialog "Couldnt write to Day One"
end try

This hasn't had any effect that I can see though...

Also:

I should point out that there is an entry being created in the journal, it is just blank

Reply

Answer 5

Apr 23, 2013 7:34 AM in response to Wagringo

Have you tried "quoted form of"?

write quoted form of text_out to out_file_ref

I wonder if the pipe characters are interfering.

Reply

Answer 6

Wagringo Author

Level 1

0 points

Apr 23, 2013 7:42 AM in response to Cole Tierney

I thought the same and used a test .txt file with pipes, but it seemed to work fine from the terminal (using the "dayone new < test.txt" command).

I just tried your suggestion, but to no avail!

Does anyone think it's likely to be an encoding problem?

Cheers

Reply

Answer 7

Apr 23, 2013 7:44 AM in response to Wagringo

Ah ok that makes sense now.

And not to be to picky here but I'd add on error's to the other try blocks just to be safe. Maybe somehting is happening when you process this one page. Better safe then sorry.

Reply

Answer 8

Wagringo Author

Level 1

0 points

Apr 23, 2013 7:54 AM in response to Frank Caggiano

Fair enough! I just added on errors in...

I am suspicious of the ' · ' characters. Do you think they are a likely source of the problem?

Here is the script now:

tell application "Safari"
          set current_tab to current tab of front window
          set tab_name to name of current_tab as Unicode text
          set get_url to URL of current_tab as Unicode text
end tell

set text_out to "Read on the Web:

" & tab_name & "
" & get_url & "
"

set out_file to "/Users/css/.tmp_dayone"

set out_file_ref to open for access POSIX file out_file with write permission
try
  write quoted form of text_out to out_file_ref
on error
          display dialog "Couldnt write to tmp file"
end try
close access out_file_ref

try
          do shell script "/usr/local/bin/dayone new < " & out_file
on error
          display dialog "shell couldnt write to Day One"
end try

delay 0.3

try
  do shell script "rm " & out_file
on error
          display dialog "shell couldnt remove tmp file"
end try

Reply

Answer 9

Tom Gewecke

Level 10

115,848 points

Apr 23, 2013 7:53 AM in response to Wagringo

Wagringo wrote:

I am suspicious of the ' · ' characters. Do you think they are a likely source of the problem?

One thing about that: Middle dot is E1 in MacRoman encoding, not ISO-8859-1. In the latter it is B7. In UTF-8 it is C2 B7. But I don't know whether this matters for your problem...

Reply

Answer 10

twtwtw

Level 5

4,936 points

Apr 23, 2013 7:57 AM in response to Wagringo

Most likely this is a problem with html entities - specially encoded characters used in html strings - not text encoding per se. html entities don't usually work well in normal text contexts. Unfortunately applescript doesn't have a built-in method for converting html entities to their text equivalents. Maybe there's a perl script?

I'd have to look at the actual webpage before I could say more.

Reply