I have two partitions on my mac: Mac OS X and Windows 7. I constantly switch between them so I started looking for a way to restart automatically into the other partition (without having to press Alt on restart). For Windows it is easy because the Boot Camp utilities provided by Apple has a quick menu for that. On Mac, though, I had to search and I found this code in Apple Script:
do shell script "bless --mount /Volumes/Windows/ --setBoot" with administrator privileges
do shell script "shutdown -r now" with administrator privileges
The problem is this doesn't work. When it restarts after running this script it goes to the Mac partition, instead of Windows.
The good thing about AppleScript is that I can save it into an app and run if from the Dock, but so far it hasn't worked. Any ideas?
For the bless command you should use an -legacy option as well do the command would be
do shell script "bless --mount /Volumes/BOOTCAMP/ --setBoot --legacy" with administrator privileges
As you can see my windows partition is named BOOTCAMP, fill in the exact path to the mounted windows volume. If the volume isn't mounted bless command won't work either.
I wouldn't use the shutdown command from the command line. It won't give you the ability to save unsaved documents. Use system events instead
tell application "System Events" to shut down
Related
I have an Automator 'Quick Action' which simply runs a shell script (using bash) which comprises of a single rsync command. I've assigned a keyboard shortcut to this from System Preferences > Keyboard > Shortcuts.
Since updating to Catalina, I'm getting a permissions problem like shown in the second last comment here: https://developer.apple.com/forums/thread/126497.
Basically, I can run my rsync command in Terminal and it'll work fine. I can also open the Automator file and run it from there and it'll work fine. But running it from a keyboard shortcut throws the permissions error.
I've granted full disk access to both rsync and my quick action file, but to no effect. The last comment in that link mentions that you need to also grant full disk access to the program that calls your program (in their case it was cron), but I don't know what the calling program is in my case.
Am trying to run a command file (which copy a file to /etc/dotnet folder which require admin privilege) from my application on Mac OS(Catalina). But when I am doing it ugly terminal comes up prompting for password to proceed. It kills my beautiful UI app.
In Windows I can run the application by right click and "Run as administrator" option so that application itself run with privilege. Is there any way to do the similar thing in Mac OS app?
Thanks in advance,
Raj
Open Terminal and execute the following command (let's assume adminuser is a user account with administrator privileges):
$ sudo chown adminuser path-to-the-command-file
$ sudo chmod u+s path-to-the-command-file
The first command will make adminuser the owner of the file.
The second command will ensure that the file will execute with the file owner's user ID, and not the user running it (note that this will still pop-up a dialog asking for the admin password.)
(Try exploring ways to not copy something to /etc/dotnet if you totally want to avoid such things).
I'm thinking of using the Mac's applescript to make a program that mutes the system when it is shutting down.
Though I'm new to applescript and I don't know how to use the IF-statement to determine if the system is shutting down. I've done some googling and I've found that the finder app is the app that is "controlling" the shutdown, but i don't know how to check if the state is "shut down". Can anybody assist me in this matter?
AppleScript has no direct mechanism for detecting a shutdown/logout.
It does have a mechanism for creating applications that can react to themselves being quit.
Thus, you can:
use AppleScript to create a stay-open application (.app bundle) with a standard on quit handler, in which you perform the desired action (
make sure that the application is launched on login - in the simpler case as a Login Item (via System Preferences, see below), or, with more flexibility but complexity, as a launch agent (see https://stackoverflow.com/a/22872222/45375).
Instructions:
Open Script Editor and open a new script window.
Paste the following code:
# This standard handler is called when the application quits.
on quit
# Mute the system volume.
# !! See caveat below.
set volume with output muted
continue quit # signal to the system that it's OK to quit
end quit
Save the script as a stay-open application:
with File Format Application
check Stay open after run handler
Open System Preferences > Users & Groups > Login Items, drag the newly saved *.app bundle into the list, and check the checkbox next to it, so as to make it launch hidden.
The final step is to hide the new application's Dock icon, as there's no reason for it to have one:
From Terminal, run the following:
defaults write /full/path/to/newApp.app/Contents/Info.plist LSUIElement 1
Note: You could use LSBackgroundOnly too, but the advantage of LSUIElement is that you can still display UI elements if you want to, such as for debugging.
Important: Substitute the full path of your new app for /full/path/to/newApp.app; the command will only work if you specify the full path to the Info.plist file.
To test, start the new app interactively, and make sure that no Dock icon appears. (You can quit the app via Activity Monitor).
CAVEAT: If the intent is to suppress the system startup sound, set volume with output muted has two drawbacks:
it will not work if headphones happened to be plugged at the time of shutdown
you will have to unmute the volume on startup (however, you could do that in an on on run handler in the same app).
Consider the alternative approach below, which requires admin privileges to set up and invokes nvram SystemAudioVolume=%80 with root privileges, which bypasses the above drawbacks.
You could run do shell script "nvram SystemAudioVolume=%80" user name "someAdminUsername" password "matchingAdminPassword" with administrator privileges from the above AppleScript app, but you'd have to hard-code the password, which is not advisable for security reasons.
Alternative approach, using a system-wide logout hook via com.apple.loginwindow.
There's a deprecated mechanism for running a script on logout that, however, still works as of OSX 10.10; given that there's no direct non-deprecated equivalent, it may continue to be supported.
Note that you do need admin privileges:
sudo defaults write com.apple.loginwindow LogoutHook <yourScript>
<yourScript> must be an executable, such as a shell script; note that the executable is run in the context of the root user.
In case you're thinking of muting the startup sound, invoke the following shell command from that script:
nvram SystemAudioVolume=%80 # to try this interactively, prepend `sudo `
This will mute sounds until after a reboot, effectively muting the startup sound, without keeping the sound muted.
Note that the nvram command requires root privileges, which are by definition in effect in a script run via the com.apple.loginwindow logout hook.; by contrast, to try the command interactively, use sudo nvram SystemAudioVolume=%80 - otherwise, you'll get the following, unhelpful error message: nvram: Error setting variable - 'SystemAudioVolume': (iokit/common) general error
Honestly, it is better to make a deterministic solution. What I mean is, is that you make a script that:
Mutes your computer.
Shuts it down.
Then you take your script and create an Automator service, that you can assign to some shortcut, to make it easier for you to use it. ctrl-opt-cmd-eject or something. :)
This is just how I would have solved it, if I have the need, it is short and sweet to make work, and should work reasonably well.
If you want to use the LogoutHook mentioned in #mklement0's answer.
You can use the normal Applescript command set volume with output muted.
You just need to add the osascript shebang to the top of the Applescript document
i.e
#!/usr/bin/osascript
set volume with output muted
And then save the file as applescript text file.
In the save dialogue use : file format: Text )
It will get the extension .applescript
Once it is saved, use Terminal.app to chmod the script as you would a normal shell script which in effect it is.
i.e
/bin/chmod +x foo.applescript
Then add it to the loginwindows LogoutHook.
sudo defaults write com.apple.loginwindow LogoutHook foo.applescript
I Know this is an old post but for anyone still looking how to do this(like I was) I have a simple method.
Before I started Scripting I created a new folder in my home folder called toolbar scripts.(this is optional)
With the desktop showing Finder click on Go >Utilities >Script Editor.
In the window that opens type in or copy and paste the code
set volume with output muted
tell application "finder"
shut down
end tell
Click on the last button above the script you added - it should be compile. If you cannot find that button then on the top click on Script >Compile
Click on File >Save in the save as I called mine shutdown and chose the script folder (this is optional)
Down the bottom of the dialog box at file format click on the arrow and change the format to application and click on save.
Open the folder you saved it in and drag the icon to the dock. Click on the icon you just put in the dock.
now if all is right this should mute the volume and shutdown the computer.
This will not shutdown the computer if you still have anything open.
Cheers
Peter
first, you should create a sound-off script (with terminal)
sudo nano /Library/Scripts/sound-off.sh
after filling it with these lines:
#!/bin/bash
osascript -e ‘set volume output muted 1’
and make a sound-on script like that
sudo nano /Library/Scripts/sound-on.sh
and fill it with:
#!/bin/bash
osascript -e ‘set volume 4’
then access them as executing files
sudo chmod u+x /Library/Scripts/sound-off.sh
sudo chmod u+x /Library/Scripts/sound-on.sh
and the last part is set them when the mac device is turn off and on:
sudo defaults write com.apple.loginwindow LogoutHook /Library/Scripts/sound-off.sh
sudo defaults write com.apple.loginwindow LoginHook /Library/Scripts/sound-on.sh
Here are my files:
launcher.applescript
tell application ":path:to:applescript:apps:shell-script-launcher.app" to launch
shell-script-launcher.app [AppleScript, saved as Application]
do shell script "say starting script"
Desired behavior:
Run "launcher.applescript" from AppleScript Editor
Listen for "starting script"
Actual behavior:
Running the "shell-script-launcher.app" by opening it manually in the finder yields expected behavior
Running the "launcher.applescript" opens the "shell-script-launcher.app" but it never executes the shell script.
I've tried saving the app as "Run Only" as well as "Stay Open". Still no progress. What do you recommend. The final result must be an Application instead of an Applescript.
Conceptually:
the run command launches and runs an application hidden
the activate command launches, runs, and activates the application (makes it the frontmost application)
launch, according to Apple, "Launches an application, if it is not already running, but does not send it a run command."
for AppleScript-based applications this should mean that they're loaded, but not executed (i.e., their - implicit or explicit - on run handler is NOT invoked), but in practice that is not true up to 10.9 - see below.
it is unclear (to me) what exactly that means for non-AppleScript-based applications
Here's how Apple thinks it works with AppleScript-based applications, which is only true starting with OSX 10.10 (Yosemite):
A script can send commands to a script application just as it can to other applications. To launch a non-stay-open application and run its script, use a launch command followed by a run command, like this:
launch application "NonStayOpen"
run application "NonStayOpen"
The launch command launches the script application without sending it an implicit run command. When the run command is sent to the script application, it processes the command, sends back a reply if necessary, and quits.
Broken behavior on OSX 10.8, 10.9 (fixed in OSX 10.10):
launch by itself is enough to run the application and is indeed the only command that works with AppleScript-based applications.
Any attempt to execute run or activate (whether in addition to launch or not) runs the application - even twice when run from AppleScript editor(!; just once with osascript) - but reports failure <appName> got an error: Connection is invalid.
This strikes me as bug.
Not sure how OSX versions <= 10.7 behave.
Note: I've witnessed the non-executing behavior with launch once, but every non-stay-open AppleScript-based test app I've created from scratch on OS X 10.9.2 and OS X 10.8.5 also executes the script with launch - contradicting what the documentation says.
Please let me know if your system behaves differently and/or how older versions behave. On what OSX version was the app that doesn't execute with launch created?
On OSX 10.10, behavior is consistent with the documentation, with one thing worth noting:
If the intent is to launch and run in one step, run application is sufficient - no need for a separate launch application command first.
Options
#user309603's pragmatic solution simply uses do shell script with the standard open utility to bypass the problem - this should work, regardless of whether the application is AppleScript-based or not:
do shell script "open " & ¬
quoted form of POSIX path of ¬
alias ":path:to:applescript:apps:shell-script-launcher.app"
If you know the type of application you're invoking up front:
to run an AppleScript-based app: best to use run script file, as #regulus6633 recommends - this has the added advantage that the invoked AppleScript-based application can return objects directly to the caller:
run script file ":path:to:applescript:apps:shell-script-launcher.app"
Note: There's also load script file, which indeed lets you merely load script code without executing it right away.
to run non-AppleScript apps: use run / activate to run the app hidden / frontmost:
run application ":path:to:applescript:apps:shell-script-launcher.app"
You could use run even with AppleScript-based applications and simply ignore errors with try ... end try, as #atonus suggests - the downside is that you won't be able to detect actual failure to invoke the application.
You can mitigate this by selectively ignoring only the specific Connection invalid error (which assumes this error would not legitimately occur) [no longer needed on OSX 10.10]:
try
run application "Macintosh HD:Applications:_Sandbox-AppleScript0.app"
on error number -609 # 'Connection is invalid' error that is spuriously reported
# simply ignore
end try
Finally, on OSX <= 10.9, you could try to simply use the launch command (though that didn't work for the OP, possibly due to working on a <= 10.7 OSX version):
launch application ":path:to:applescript:apps:shell-script-launcher.app"
However, that is not advisable for two reasons:
In OSX 10.10, Apple has fixed the launch behavior to no longer execute also, so your code will break when run there.
While non-AppleScript apps typically do run (hidden) when invoked with launch, the documentation says that AppleScript "does not send it a run command" and "allows you to open an application without performing its usual startup procedures, such as opening a new window" - what that exactly means is not clear and different applications seem to handle this differently.
Applescript has the "run script" command. It works on applescripts or applescript applications. So if I have your app on my desktop then this works...
set appPath to (path to desktop as text) & "shell-script-launcher.app"
run script file appPath
Have you tried open?
do shell script "open 'path/to/applescript/apps/shell-script-launcher.app' && say starting script"
Put it between "try" keywords.
try
tell application ":path:to:applescript:apps:shell-script-launcher.app" to activate
end try
Save your script as an application.
Add the desired script into the Script folder (see path below)
Run as follows, change per type of script you want to run...
property theApplicationPath : the path to me as text <br/>
property theShellScriptPath : theApplicationPath & "Contents:Resources:Scripts:test.command"<br/>
property theShellScript : the quoted form of POSIX path of theShellScriptPath<br/>
<br/>
tell application "Terminal" to (do shell script "/bin/bash " & theShellScript)
<br/>
Boom, Bob's your uncle! At least for me.
It is quite simple, you just have to use the normal do shell script, for example:
do shell script "open " & ¬
quoted form of POSIX path of ¬
alias ":path:to:applescript:apps:shell-script-launcher.app"
This may be helpful but I'm not an expert on this subject. I this case I found the double launching behaviour (on Yosemite, I haven't used any other version of OS X) very annoying and digging around I found one can check if it is already running.
This script is so I can launch a new terminal whenever I like.
if application "Terminal" is running then
tell application "Terminal"
activate
do script ""
end tell
else
tell application "Terminal" to activate
end if
Hello I'm using Mac OS X 10.6.8. How can I set some simple Terminal commands to run on start up as if I was opening up Terminal and putting those commands in myself? I basically need to start a few server daemons on start up. The commands I use in Terminal to manually start them look like sudo ruby myrubyserverscript_control.rb start. I apologize in advance if this is super obvious or already answered on here a million times in some way I don't know enough to recognize.
Here are two different things:
you want run a script after the system startup (boot), or
when you logging in
for run a script at boot, you should put one XML config file into /Library/LaunchDaemons (and the launchd process will run the script at the boot time)
for run a script after you logging in - see this: https://stackoverflow.com/a/6445525/632407
Open System Preferences and go to the Users and Groups / Login Items tab. You can add a scipt with the + button or drag it to the list of items. Usually scripts end in .command that are used in this context but they are just bash scripts. I suppose you could use any script that is executable and has the correct #! line.