create a text file with an arbitrary name in a given user space folder
ask wether I want to open it in TextEdit
open it if yes.
Note: the file has an .eml extension. Basically I’m writing a mail draft in TextEdit because I don’t want to have to bother with Mail at that particular time.
On the first run, macOS asks me if I want to grant access to my files to this script. I agree.
The issues comes when I OK the opening. The OS tells me that I don’t have access to that file and that I should check its properties.
Of course, when I check the properties, I have full access right to it. I can even right-click on it and select TextEdit to open it.
So, how to I manage to grant access to that particular file from within the script ?
use AppleScript version "2.4" -- Yosemite (10.10) or later
use scripting additions
# create file in Finder
tell application "Finder"
try
set myFolder to (the target of the front Finder window) as alias
on error
beep
end try
set myFileName to name of myFolder
display dialog ¬
"New text file name:" default answer myFileName & ".txt" buttons {"Cancel", "Create"} ¬
default button 2
set myFileName to text returned of result
if exists file myFileName of myFolder then
display alert ¬
"A file named ‘" & myFileName & "’ already exists in this folder." as informational
return
end if
set myPath to ((POSIX path of myFolder) & myFileName)
do shell script "touch " & quoted form of myPath
#open file in TextEdit
display dialog ¬
"Open file with TextEdit?" buttons {"Yes", "Cancel"} ¬
default button 1
if button returned of result is "Yes" then
try
tell application "TextEdit" to open myPath
end try
end if
end tell
activate application "TextEdit"
Jean. Try the following, which worked on my Sonoma computer. I made the following changes:
Set the file being opened by TextEdit to a file object, which was the reason for the error statement.
Moved the location of the end of the Finder tell statement.
Edited the try statement to stop the script on error. Just as a matter of personal preference, I would add a dialog or notification at this point.
use AppleScript version "2.4" -- Yosemite (10.10) or later
use scripting additions
# create file in Finder
tell application "Finder"
try
set myFolder to (the target of the front Finder window) as alias
on error
beep
return
end try
set myFileName to name of myFolder
display dialog ¬
"New text file name:" default answer myFileName & ".txt" buttons {"Cancel", "Create"} ¬
default button 2
set myFileName to text returned of result
if exists file myFileName of myFolder then
display alert ¬
"A file named ‘" & myFileName & "’ already exists in this folder." as informational
return
end if
end tell
set myPath to ((POSIX path of myFolder) & myFileName)
do shell script "touch " & quoted form of myPath
#open file in TextEdit
display dialog ¬
"Open file with TextEdit?" buttons {"Yes", "Cancel"} ¬
default button 1
if button returned of result is "Yes" then
try
set theFile to POSIX file myPath
tell application "TextEdit" to open theFile
end try
end if
activate application "TextEdit"
The point of the script is that I need it to create a file anywhere in my user space. My download folder is just an example, but I don’t see why I could not be able to create files in there. Also, a similar script I have for Emacs that does exactly the same thing (create and then open) does not have this issue.
The main difference is that I ask Emacs to open the file from the command line (because it is not Applescriptable, not because I fancy command line instructions):
set myCommand to myEmacsclient & " -n -e \"(find-file " & "\\\"" & selectedFile & "\\\"" & ")\""
do shell script myCommand
I guess I could use open -e or open -a. But the fact is that after the file is created, I don’t have a problem opening it by otherwise “normal” means. Regardless of the location.
Thank you. I ALWAY get mixed up with file types. File handling is THE major wall I bump into when I go back to AppleScript. I’ll need to write myself a tutorial one of these days.
It works now.
Nice. I always try to keep my tell blocks as short as possible. I totally missed this one.
Nice. The only case when that try block would error is basically when there is no parent folder, which is limited to places where I would not want to write files (the disk root, or a smart search window, etc.). I think I have a dialog in another script that uses the same trick to identify the user facing folder. Thank you for the reminder.
I wrote that the file had an .eml extension, which is not the case in the script. That script was a prototype to write that “quickly draft that email” script that I still have in mind.
As you might know, a standard mail is a text file with this structure:
Subject:
Basically a Subject: header and a line, under which the body will be written.
So, it’s pretty trivial to use a script that creates a mail draft, with the eml extension, so that you don’t have to bother having Mail.app opened all day. And when you want to deal with your mails, you just double-click them, it opens Mail.app and you do your thing.
Obviously, a mail draft can have more default content, which you can complete with appropriate dialogs from your script.
Subject:
To:
And it works for any utf-8 (multilingual) content.
