AppleScript Problem

Unless I'm missing something, your script should never have worked.

Your script defines:

set textFile to (("Macintosh HD:Users:clusterflux:Documents:") & "DOG.txt")

so the variable textFile is a text object. Not a file.

Therefore the subsequent line:

	write newText1 to textFile

will fail 100% of the time. Theoretically, regardless of what OS version you're running. You can't write a value to a text variable. You need to coerce textFile to a file object first.

Additionally, you should be using open for access to get a file handle to the file, and directing your writes to that.

set textFilePath to (("Macintosh HD:Users:clusterflux:Documents:") & "DOG.txt")
set textFile to open for access textFilePath with write permission
...
-- write data to the file
write someData to textFile
...
-- and close the file when you're done
close access textFile

Writing to it via a shell script is also doomed to fail:

	do shell script "echo  " & quoted form of newText2 & " >>  " & quoted form of textFile

because shell commands require POSIX paths, not MacOS (colon-delimited) paths.

> From the top of my head though, I ran into problems setting open for access because it returned some sort of error that I can't recall right now but from what you wrote I didn't call it correctly

I will concur that file handling within AppleScript is a bit of a mess and even experienced AppleScripters trip up and forget exactly which form of file/path/alias to use, and which commands will automatically coerce one to another..

The other thing to learn about is the path to command which will find a number of common locations at runtime (i.e.. without you having to know the full path to the current user's home directory, for example).

A number of seemingly-valid paths can trip up due to typos, or some minor difference between systems and path to can avoid a lot of them.

In general, here is the robust logic for writing to a file on the desktop that should work for any system:

-- define the file path using 'path to desktop' to find the dynamic/current user desktop folder
set myFilePath to (path to desktop as text) & "my.txt"

-- open the file (this will create it if needed)
set myFile to open for access myFilePath with write permission

-- optionally reset the file contents (if any)
set eof myFile to 0

-- write some data to the file
write "blah " & return to myFile
-- you can have multiple write statements
write "more data here" & return to myFile

-- close the file when done
close access myFile

Just make sure you open for access before you reference the file, and close access at the end of your script.

I'm on High Sierra to avoid problems like these.

I've read you need to go to security panel and give applescript permission to do these sorts of things.

Robert

Lots of information missing here.

When you say you "can't create a text file...", what do you mean?

Do you mean the script runs, but no file is created?

Do you mean the script throws an error? What is that error message?

Are you able to create files in other locations, or is it just the Desktop that's affected?

and how are you running the script? as a script app? from within Script Editor?

What about new scripts? are they able to create files? Can you recompile/save the old scripts and make them work?

The answers to these questions may help identify where the problem is. It is entirely likely that it's related to new security protocols, but that's not to say it can't be done at all.

Yes, I seem to remember even on Mavericks I had to delve into some Preference setting and add permission to let various scripts to run. I can't imagine what it must be like with Big Sur. Not only are things sandboxed, they're on different planets.

It wouldn't surprise me at all if it was Big Sur. I haven't used it but when I had problems with text files and Applescripts after upgrading to a higher OS I discovered Apple's ever-increasing security messages prevented old scripts from doing things with text files. I can't really help on the issue though, sorry. Those were transitions from OS 10.4 to OS 10.9 and I am sure things have gotten a lot worse with the security features of the past 6 releases.

Don't want to be negative. We were in your position before. I forget things about applescript all the time. When writing computer code precision is important in the code and in the question.

All of a sudden, I can't create a text file that generates on the desktop.

This statement confused me. I assumed the same code was working before and it is not now. I should not have assume: *** of u & me.

Writing to files in applescript have been nightmare for me. Figure out out which reference to use to access a file has been an endless hassle for me: classic macos, modern macOS and Unix

Good luck with your new adventure.

These days, I put a "print" line about after every line of code.

(* 


It is easier to diagnose problems with debug information. I suggest adding log statements to your script to see what is going on.  Here is an example.




	Author: rccharles
	
	For testing, run in the Script Editor.
	  1) Click on the Event Log tab to see the output from the log statement
	  2) Click on Run


 *)




on run
	-- Write a message into the event log.
	log "  --- Starting on " & ((current date) as string) & " --- "
	--  debug lines
	set desktopPath to (path to desktop) as string
	log "desktopPath = " & desktopPath
end run

Robert

Why don't you post the code. Could you just widdle the code down, so you only post the failing code. I think I have big sur running in some vm or partion.

Robert

I seem to remember in the day, you had to turn on assistive device setting or some-such-setting to get automation to work in applescript. It was something along the lines to let applescript to send keystrokes to the apple applications. I have no proof, but encryption is for honest people I feel.

Now, apple send boxes all apps. You need to give them permission to *art. I got enough problems surfing the web to add to my headaches with more security.

I learned a long time ago the only secure computer is in a locked room. I follow this policy. It works for me. My harddrive failed for me in the late 90's and the backup floppy with all my passwords failed too. It was encrypted, so I could not recover the good sectors. I changed my strategy to kiss with multiple backups. It's a risk.

R