I am trying to do a proof of concept for my notes on how to copy using the shell and cp from Applescript.
When I run the code in Example A, it fails…but Example B, which does not use a variable for the do shell command works fine.
What am I missing?
***** Example A *****
try
set mySource to "/Users/myuser/Desktop/tmp/test.txt"
set myDestination to "/Users/myuser/Desktop/"
set myCopy to "\"sudo cp -v '" & mySource & "' '" & myDestination & "'\" "
set myAnswer to do shell script myCopy user name "myuser" password "dodadoda" with administrator privileges
on error
set myAnswer to "Could not copy file"
end try
display dialog myAnswer
***** Example B *****
try
--set mySource to "/Users/myuser/Desktop/tmp/test.txt"
--set myDestination to "/Users/myuser/Desktop/"
--set myCopy to "\"sudo cp -v '" & mySource & "' '" & myDestination & "'\" "
set myAnswer to do shell script "sudo cp -v '/Users/myuser/Desktop/tmp/test.txt' '/Users/myuser/Desktop/'" user name "myuser" password "dodadoda" with administrator privileges
on error
set myAnswer to "Could not copy file"
end try
display dialog myAnswer
The problem is not the variables, but the extra double quotes that you are throwing around the command.
“"sudo cp -v '” & mySource & “’ '” & myDestination & "'" " results in the following literal string (underlined) “sudo cp -v ‘/Users/myuser/Desktop/tmp/test.txt’ ‘/Users/myuser/Desktop/’” (including the trailing space). If you typed this in Terminal it would fail too. The double quotes make the shell interpret the entire string (except for the trailing space) as a single ‘word’. Since this is the first ‘word’, the shell looks for a binary (program executable) with that exact name. It is extremely unlikely to find one with that name.
Drop the extra double quotes you are adding.
Do not use sudo with with administrator privileges (TN 2065 “How do I get administrator privileges for a command?”).
Let quoted form of quote your variable arguments (it will do things like properly quote embedded single quotes”this is especially important for security reasons (SQL injection vulnerabilities are a result of a similar problem in SQL)).
try
set mySource to "/Users/myuser/Desktop/tmp/test.txt"
set myDestination to "/Users/myuser/Desktop/"
set myCopy to "cp -v " & quoted form of mySource & " " & quoted form of myDestination
set myAnswer to do shell script myCopy user name "myuser" password "dodadoda" with administrator privileges
on error
set myAnswer to "Could not copy file"
end try
display dialog myAnswer