0

I'm trying to write some text into an xml file situated in a subfolder of the main library/Application Support folder using a shell script do shell script "echo '" & theText & "' > " & thePath.

Without a password, I get a "sh: /Library/Application: Permission denied" which is perfectly logical. Adding user name and password, as shown in the code below, I no longer get any error, but no text is written to the file. If I put a wrong user name or password, it gives me "The user name and password were incorrect", which shows that the password is indeed being taken into account. Am I trying to do something impossible, or is my code missing something ?

set thePath to POSIX path of ("/Library/Application Support/MyApp/Stuff/test.xml" as text)

set theText to "<ProductSpecific><Visibility type=\"Number\">3</Visibility></ProductSpecific>"

set theScript to "echo '" & theText & "' > " & thePath

do shell script theScript user name "myshortusername" password "mypassword" with administrator privileges

I should get theText written to /Library/Application Support/MyApp/Stuff/test.xml but nothing is written although I don't get an error message either ! Oh, and if I move the file to the desktop and change the path, it all works fine !!

Fred
  • 33
  • 5
  • You really should be writing to: `~/Library/Application Support/..` – user3439894 Sep 08 '19 at 00:09
  • agree with @user3439894 — unless this is a system with multiple accounts and you're trying to update something for all users, there's no need to write to /Library; ~/Library should work fine and save you headaches. Are you running this script from an administrator account or a normal user account? – Ted Wrigley Sep 08 '19 at 00:47
  • Sorry guys but the xml files I want to modify are created by another application in the main library folder, so that's where I need to write. This is not about best practices, but about where I need to work ;) Thanks for your answers though :) – Fred Sep 08 '19 at 18:07
  • Oh yes… and I am running the script from an admin account… – Fred Sep 08 '19 at 20:50
  • I'm wondering if Mojave sandboxing isn't in it for something. It does seem to be upsetting AppleScript here and there as in the "Not authorized to send Apple events to Image Events. (error -1743)" error :( – Fred Sep 09 '19 at 00:50

1 Answers1

0

The reason of the error is the space character in Application Support. You have to escape the entire path.

It's highly recommended to use always quoted form of

set theScript to "echo " & quoted form of theText & " > " & quoted form of thePath

Side note:

The string path is already a POSIX path (and it's already text) so you can omit both

set thePath to "/Library/Application Support/MyApp/Stuff/test.xml"
vadian
  • 274,689
  • 30
  • 353
  • 361
  • Thanks for your answer. I'll see if that changes anything, but the path is not the issue here, it's the access permissions. I'll be back… – Fred Sep 08 '19 at 18:10
  • The path is not really an issue. But `POSIX path` and `as text` are redundant. – vadian Sep 08 '19 at 18:12
  • OK. I made the changes, but it hasn't fixed anything unfortunately :( I'm beginning to think this isn't possible. Even if I give a file read an write permissions to anyone, before running the script, I still get permissions denied error. This works just fine elsewhere… – Fred Sep 08 '19 at 22:30
  • It should be possible using `with administrator privileges` and admin credentials. – vadian Sep 09 '19 at 06:21
  • @user1251047 - perhaps you're using MacOS Mojave which has stricter security policies. See the section named _"MacOS Mojave Restrictions"_ at the end of my answer [here](https://stackoverflow.com/questions/56517403/how-to-create-and-manage-macos-safari-bookmarks-programmatically/56663577#56663577). Maybe you need to grant the _Terminal.app_ (and/or the AppleScript `.app`) permission to access to your whole disk. – RobC Sep 09 '19 at 08:04
  • @vadian - Thanks again for your reply, but the "myshortusername" and"mypassword" were for an admin account and were still giving permission denied. I think what user1251047 commented, holds some truth to the problem, as I said in one of my comments above. – Fred Sep 09 '19 at 13:59
  • RobC - I am indeed using Mojave, and this is a trail I'm following at present. I have seen that one possible solution is to wrap the AppleScript in an Xcode project and to modify the info.plist to add "Privacy - AppleEvents…" "This script needs to control other applications to run.". This forces the app to ask for permissions when it runs, and has fixed the problem for me in another project I was working on. Haven't tried it in this one yet, but I will and I'll post my findings here. Thanks for your comment. – Fred Sep 09 '19 at 14:06