I’ve got an installer script that installs a bunch of things.
It was very annoying that it wanted users to type in their password over and over. I couldn’t find any way to get Finder or System Events to run with higher privileges, so I switched file copies over to a “do shell script” “cp” command with administrator privileges.
Some of them work fine, but others still ask for a password…
Anyone know why, or if there’s a way to bypass this?
Thanks,
Tom.
tell application "Finder"
set multiPluginFilePOSIX to (POSIX path of (path to downloads folder as text)) & "/Optional Multiplugin.plugin"
try
(POSIX file multiPluginFilePOSIX) as alias
on error
error "Could not locate Optional Multiplugin.plugin at:" & return & multiPluginFilePOSIX
end try
set thePassword to display dialog "Please enter the Admin Password:" default answer ""
set currentPSapp to alias "Users:Shared:Shortcuts:Photoshop.app"
set PSfolder to (parent of currentPSapp as alias)
set currentPluginFolder to (folder "Plug-ins" of PSfolder)
set currentPluginFolderPOSIX to POSIX path of (currentPluginFolder as alias)
end tell
set shellLine to "cp -R " & (quoted form of multiPluginFilePOSIX) & " " & (quoted form of currentPluginFolderPOSIX)
do shell script shellLine password thePassword with administrator privileges
display dialog "Done! Changes will take effect after restarting Photoshop." buttons "OK" default button 1 giving up after 5
Some notes:
-
If I build an alias first and then use “POSIX path of” on the alias to get my POSIX paths, the directories have a trailing “/” in the POSIX path, and “cp” doesn’t seem to like that.
-
“Users:Shared:Shortcuts:Photoshop.app” is a symlink to the version of Photoshop the user is on, so we can target them specifically in code.
-
It still prompts for a password, and then you enter the identical password to the one already filled in on the Applescript prompt, and the file copy works fine.
What’s the point of the “with administrator privileges” and password, if it’s just going to ask for the identical password again, and that will suffice?
You are missing the username for the do shell script command
do shell script shellLine password thePassword user name theUsername with administrator privileges
Also the username/password combo must be from an administrator account
Hi. It’s possible your task may just need an admin account to be specified to avoid the dialog, as robertfern stated, but an issue in the code is that Finder has no idea what POSIX is, so such commands should not be scoped within its block.If specifying the account works, then do that, but an alternate may be to go the superuser route.
#do whatever Finder stuff may be necessary to arrive at currentPluginFolder
#do standard addition stuff here
set {theAccount, thePassword} to {(display dialog "Please enter an Admin Account:" default answer "")'s text returned, (display dialog "Please enter the Admin Password:" default answer "")'s text returned} --no error trapping for cancellation
do shell script "cp -R " & (my (path to downloads folder as text) & "Optional Multiplugin.plugin")'s POSIX path's quoted form & space & (currentPluginFolder as text)'s POSIX path's quoted form user name theAccount password thePassword with administrator privileges
–OR (major escalation with potential security implications):
do shell script "printf " & my (display dialog "Input an Admin password" default answer "check yourself")'s text returned's quoted form & " | sudo -S cp -R " & (my (path to downloads folder as text) & "Optional Multiplugin.plugin")'s POSIX path's quoted form & space & my (path to desktop)'s POSIX path's quoted form
robertfern - thank you! That was it. I’d simply quickly googled up bad syntax on that.
I’m surprised it simply performs the shell script without administrator privileges when you specify “with administrator privileges” and the password, rather than throwing an error.
Marc Anthony - it works fine with the username added. I’ve never had an issue with using “POSIX path of” or “as POSIX file” inside Finder tells. I’ve used a lot of them. But I’ll keep it in mind.
Incorrectly scoped code can cause a script to be inefficient, even if the base functionality may happen to still be there. The current arrangement seems precarious to me; you’re sending a list for a password, so the shell must be interpreting the text.