Where is 'missing value' coming from in this repeat block? - applescript

Question

I am creating a text file and looping through every Safari window, every tab, and pasting each link into the .txt file. However I am getting an extra missing value written to the .txt file. I know I can explicitly check for missing values but I don't understand where is the "empty" window/value?
on run {input, parameters}
(* create text file to hold links *)
tell application "Finder" to make file at desktop with properties {name:"links_0"}
set classicPath to (((path to desktop folder) as string) & "links_0")
(* get links of all windows *)
tell application "Safari"
repeat with this_window in windows
set the_URLs to ""
repeat with this_tab in tabs of this_window
set the_URLs to the_URLs & URL of this_tab & return
end repeat
do shell script "echo " & quoted form of the_URLs & " >> " & POSIX path of (classicPath)
do shell script "echo >> " & POSIX path of (classicPath)
end repeat
end tell
return input
end run
sample output (2 windows, each with 2 tabs):
https://discussions.apple.com/thread/64896
https://discussions.apple.com/thread/22543
https://discussions.apple.com/thread/25140
https://discussions.apple.com/thread/22546
missing value

Answer 1

An easier way to do this would be:
set my text item delimiters to linefeed
set fp to POSIX path of (path to desktop folder) & "links_0.txt"
close access (open for access fp) -- Create the file if it doesn't exist
# set eof of fp to 0 -- Erase any existing contents in the file
tell application id "com.apple.Safari" to tell every tab of every window ¬
to tell (the URL as text) & linefeed to continue write it to fp ¬
starting at eof
This currently appends URLs to the end of the file. To overwrite the file, uncomment this line:
# set eof of fp to 0
by removing the hash symbol.
Note: There's potential for confusion having read the comment left by #user3439894, where he states:
"It also shows code missing from CJK's answer in which a file should be closed after being written to. It also wraps relevant code in a try statement so if there is an error it attempts to close the file."
I would take what you read at the provided link with a pinch of salt. Sadly, a lot of the AppleScript documentation from Apple contains code that is poorly written and is part of the reason a lot of bad AppleScript persists so pervasively on the internet. Some of the documentation provided by Apple is also flat out wrong, which makes it very difficult for people to learn from and to know whose advice to take.
The code I have provided above, I assure you, is very much complete. Read on for a pretty boring explanation that I wish I didn't have to give, but now have to:
You'll see a lot of people do this:
set fh to open for access filepath with write permission
write somedata to fh
close access fh
It's not wrong, per se, but it's a pretty draconian way of using these read/write commands, which persists among many simply because they've always done it that way, and only seen it done that way. It's cumbersome and completely unnecessary1.
#user3439894 alluded to a try statement, which would, indeed, be needed for this method. open for access opens a file handle that was necessary in order to write out to a file. However, if an error in the script occurs during the write process, then the file handle is left dangling because the script terminates before being able to close access to the file. The way around this would be to use a try statement whose purpose was to catch an error, and ensure the close access command still gets executed:
try
set fh to open for access filepath with write permission
write somedata to fh
close access fh
on error
close access fh
end try
open for access and close access are redundant. There's no need to use them, and in fact, their use is only creating a potential problem that then needs a workaround in order to solve.
write--and read--are safe and advisable to use on their own, and they don't need a try block to catch potential errors. So why do the two commands I just called redundant appear in my script at all ?
close access (open for access fp)
One nifty side effect of the open for access command is that it will create a file at the specified path if one doesn't already exist. This is really useful because it negates the need to call out to System Events or (shudder) Finder to do this for you. It also has seems to have a wider scope for creating files at locations that other AppleScript applications don't have permission to access if they're sandboxed, etc.
Once open for access has created the file--or opened one that already exists--it returns a reference to the file handle. Then close access is used to immediately destroy file handle, because we don't actually have any use for it, but also don't want it left open. There's also no need for a try block: any error that could possibly arise would do so during the creation of the file handle, which would mean that the file handle won't be created, and so cannot be left open.
1The way the data gets written out now is fundamentally different to how it was written out when these commands were first introduced, and previously, write would not be able to access a file without first explicitly opening a file handle to it and declaring the need for writing permissions. Now, everything gets handled within the write command itself, including clean up.