I have this shell script Test.sh:
#! /bin/bash
FILE_TO_CHECK="/Users/test/start.txt"
EXIT=0
while [ $EXIT -eq 0 ]; do
if [ -f "$FILE_TO_CHECK" ]
then
/usr/bin/java -jar myapp.jar
EXIT=1
else
sleep 30
fi
done
I need to start this script automatically after login.
So I put it inside a folder Test in /System/Library/StartupItems/
When I reboot the Mac, nothing happens after I log in.
Any clue?
I also tried Automator, but with the same result: the java program is not running.
Ivan Kovacevic's pointers, especially the superuser.com link, are helpful; since at least OS X 10.9.2, your options for creating run-at-login scripts are:
Note: The methods are annotated with respect to whether they are:
specific to a given user ("[user-SPECIFIC]"); i.e., the installation must be performed for each user, if desired; scripts are typically stored in a user-specific location, and root (administrative) privileges are NOT required for installation.
effective for ALL users ("[ALL users]"); i.e., the installation takes effect for ALL users; scripts are typically stored in a shared location and root (administrative) privileges ARE required for installation.
The scripts themselves will run invisibly, but - with the exception of the com.apple.loginwindow login-hook method - you can open applications visibly from them; things to note:
There is no guarantee that any such application will be frontmost, so it may be obscured by other windows opened during login.
If you want to run another shell script visibly, simply use open /path/to/your-script, which will open it in Terminal.app; however, the Terminal window will automatically close when your script terminates.
Automator [user-SPECIFIC]:
File > New, type Application
Add a Run Shell Script action, which adds an embedded bash script, and either paste your script code there or add a command that invokes an existing script from there.
Save the *.app bundle and add it to the Login Items list in System Preferences > User & Groups > Login Items.
Note:
The embedded script runs with the default "C" locale.
$PATH is fixed to /usr/bin:/bin:/usr/sbin:/sbin, which notably does NOT include /usr/local/bin
The working dir. is the current user's home directory.
com.apple.loginwindowlogin hook [ALL users - DEPRECATED, but still works]:
If you have admin privileges, this is the easiest method, but it is DEPRECATED, for a variety of reasons (security, limited to a single, shared script, synchronous execution); Apple especially cautions against use of this mechanism as part of a software product.
Place your script, e.g., Test.sh, in a shared location - e.g., /Users/Shared - and make sure it is executable (chmod +x /Users/Shared/Test.sh).
From Terminal.app, run the following:
sudo defaults write com.apple.loginwindow LoginHook /Users/Shared/Test.sh
Note:
The script will run as the root user, so exercise due caution.
Among the methods listed here, this is the only way to run a script as root.
There's only one system-wide login hook.
Note that there's also a log-OUT hook, LogoutHook, which provides run-at-logout functionality - unlike the other approaches.
The login-hook script runs synchronously before other login actions, and should therefore be kept short.
Notably, it runs before the desktop is displayed; you cannot launch applications from the script, but you can create simple interactions via osascript and AppleScript snippets (e.g., osascript -e 'display dialog "Proceed?"'); however, any interactions block the login process.
The script runs in the context of the root user and he username of the user logging on is passed as the 1st argument to the script.
The script runs with the default "C" locale.
$PATH is fixed to /usr/bin:/bin:/usr/sbin:/sbin, which notably does NOT include /usr/local/bin
The working dir. is /.
launchd agents:
launchd-agent-executed scripts can be installed for a SPECIFIC user OR for ALL users - the latter requires administrative privileges.
While using launchd is Apple's preferred method, it's also the most cumbersome, as it requires creating a separate *.plist configuration file.
On the upside, you can install multiple scripts independently.
Note:
No specific timing or sequencing of launchd scripts is guaranteed; loosely speaking, they "run at the same time at login"; there is even no guaranteed timing between the user-specific and the all-user tasks.
The script runs with the default "C" locale.
$PATH is fixed to /usr/bin:/bin:/usr/sbin:/sbin, which notably does NOT include /usr/local/bin
The working dir. is / by default, but you can configure it via the .plist file - see below.
The script-file path must be specified as a full, literal path (e.g., /Users/jdoe/script.sh; notably , ~-prefixed paths do not work.
For a description of all keys that can be used in *.plist configuration files, see man launchd.plist.
Both user-specific and all-users tasks run as the current user (the user logging on).
launchd [user-SPECIFIC]:
Note: Lingon 3 ($5 as of early 2014) is a GUI application that facilitates the process below, but only for user-specific scripts.
Place your script, e.g., Test.sh, in your home folder, e.g., /Users/jdoe
Create a file with extension .plist in ~/Library/LaunchAgents, e.g., ~/Library/LaunchAgents/LoginScripts.Test.plist, by running the following in Terminal.app:
touch ~/Library/LaunchAgents/LoginScripts.Test.plist
Open the file and save it with the following content:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<!-- YOUR SELF-CHOSEN *UNIQUE* LABEL (TASK ID) HERE -->
<string>LoginScripts.Test.sh</string>
<key>ProgramArguments</key>
<array>
<!-- YOUR *FULL, LITERAL* SCRIPT PATH HERE -->
<string>/Users/jdoe/Test.sh</string>
</array>
<key>RunAtLoad</key>
<true/>
</dict>
</plist>
The <!-- ... --> comments indicate the places to customize; you're free to choose a label, but it should be unique - ditto for the .plist filename; for simplicity, keep the label and the filename root the same.
From Terminal.app, run the following:
launchctl load ~/Library/LaunchAgents/LoginScripts.Test.plist
Note that, as a side effect, the script will execute right away. From that point on, the script will execute whenever the CURRENT user logs on.
It is not strictly necessary to run launchctl load -- since, by virtue of the file's location, it will be picked up automatically on next login -- but it's helpful for verifying that the file loads correctly.
launchd [ALL users]
Place your script, e.g., Test.sh, in a SHARED location, e.g., /Users/Shared
Create a file with extension .plist in /Library/LaunchAgents (requires admin privileges), e.g., /Library/LaunchAgents/LoginScripts.Test.plist, by running the following in Terminal.app:
sudo touch /Library/LaunchAgents/LoginScripts.Test.plist
Open the file and save it with the following content (make sure your text editor prompts for admin privileges on demand; alternatively, use sudo nano /Library/LaunchAgents/LoginScripts.Test.plist):
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<!-- YOUR SELF-CHOSEN *UNIQUE* LABEL (TASK ID) HERE -->
<string>LoginScripts.Test.sh</string>
<key>ProgramArguments</key>
<array>
<!-- YOUR *FULL, LITERAL* SCRIPT PATH HERE -->
<string>/Users/Shared/Test.sh</string>
</array>
<key>RunAtLoad</key>
<true/>
</dict>
</plist>
The <!-- ... --> comments indicate the places to customize; you're free to choose a label, but it should be unique - ditto for the .plist filename; for simplicity, keep the label and the filename root the same.
From Terminal.app, run the following:
sudo chown root /Library/LaunchAgents/LoginScripts.Test.plist
sudo launchctl load /Library/LaunchAgents/LoginScripts.Test.plist
Note that, as a side effect, the script will execute right away. From that point on, the script will execute whenever ANY user logs on.
It is not strictly necessary to run launchctl load -- since, by virtue of the file's location, it will be picked up automatically on next login -- but it's helpful for verifying that the file loads correctly.
You can't just place plain scripts in that folder. You need a "specialized bundle" how Apple calls it, basically a folder with your executable, and a .plist configuration. And you should put it in /Library/StartupItems since /System/Library/StartupItems/ is reserved for the operating system. Read all about it here:
https://developer.apple.com/library/mac/documentation/macosx/conceptual/bpsystemstartup/chapters/StartupItems.html
Also note that the whole stuff is marked as deprecated technology. And that Apple is suggesting the use of launchd. There is an example how to set it up here:
https://superuser.com/questions/229773/run-command-on-startup-login-mac-os-x
launchd-oneshot is used to install script as a launchd job to run on login, with
brew install cybertk/formulae/launchd-oneshot
sudo launchd-oneshot Test.sh --on-login
Disclosure: I am the author of this package.
When i use the new Chromium Portable browser it always shows "Google API keys are missing.Some functionality of Chromium Portable will be disabled" after starting up.
How do i get rid of this warning message and what does it mean?.
To get rid of the message...
...on Windows, you can use the command prompt to set the following environment variables to "no":
setx GOOGLE_API_KEY "no"
setx GOOGLE_DEFAULT_CLIENT_ID "no"
setx GOOGLE_DEFAULT_CLIENT_SECRET "no"
Windows' environment variables can also be set from the "Advanced System Settings" tab of the "System" control panel. After setx ... relaunching the browser should no longer have the message. Setting the variables through the "Advanced System Settings" tab may require a log-out before it takes effect.
... on Linux you can use the terminal to set the environment variables to "no" in the bash shell:
export GOOGLE_API_KEY="no"
export GOOGLE_DEFAULT_CLIENT_ID="no"
export GOOGLE_DEFAULT_CLIENT_SECRET="no"
A subsequent launch of the browser from the terminal will not show the missing API key message. To make this setting permanent and to cover invocations from clicking on an icon, follow the directions here for setting environment variables that affect terminal as well as graphical logins.
...on macOS, you can add the following key-value pairs to the LSEnvironment dictionary in Chromium.app > Contents > Info.plist:
<key>LSEnvironment</key>
<dict>
<key>GOOGLE_API_KEY</key>
<string>no</string>
<key>GOOGLE_DEFAULT_CLIENT_ID</key>
<string>no</string>
<key>GOOGLE_DEFAULT_CLIENT_SECRET</key>
<string>no</string>
</dict>
(Note that macOS may have cached the existing Info.plist file, so changes may not take effect immediately. See this answer for some ways around that.)
As for the meaning, I think Dragomir Goranov's answer gives sufficient information.
I needed to get rid of this message too, so I just took what mormegil suggested but applied it to a batch script that launches Chromium.
My below sample batch file will launch Chromium into KIOSK mode but you can just remove the --kiosk if you don't need that.
set GOOGLE_API_KEY="no"
set GOOGLE_DEFAULT_CLIENT_ID="no"
set GOOGLE_DEFAULT_CLIENT_SECRET="no"
"C:\chromium\ChromiumPortable_49.0.2593.0.paf\App\Chromium\32\chrome.exe" --kiosk
I did it this way since I don't want to set those environment variables to affect other instances of Chromium but rather just the one that I'm launching with my batch script.
It means that some functionality will not work. For example "Chrome Sync API" requires API keys.
For more information you can check this URL: http://www.chromium.org/developers/how-tos/api-keys
If something is not clear to you after you read the provided information, please specify exactly what.
Disabling API Key will disable functionality like SYNC. A better solution is to use Google API Keys that LINUX Chromium Browser comes with.
Paste the following into command window on Windows:
setx GOOGLE_API_KEY "AIzaSyCkfPOPZXDKNn8hhgu3JrA62wIgC93d44k"
setx GOOGLE_DEFAULT_CLIENT_ID "811574891467.apps.googleusercontent.com"
setx GOOGLE_DEFAULT_CLIENT_SECRET "kdloedMFGdGla2P1zacGjAQh"
on Linux:
export GOOGLE_API_KEY="AIzaSyCkfPOPZXDKNn8hhgu3JrA62wIgC93d44k"
export GOOGLE_DEFAULT_CLIENT_ID="811574891467.apps.googleusercontent.com"
export GOOGLE_DEFAULT_CLIENT_SECRET="kdloedMFGdGla2P1zacGjAQh"
Restart Chromium, and you are all set.
On macOS another (simpler) solution is:
/usr/bin/env GOOGLE_API_KEY="no" GOOGLE_DEFAULT_CLIENT_ID="no" GOOGLE_DEFAULT_CLIENT_SECRET="no" /usr/bin/open -a chromium
as open passed existing environment variable to the launched application (see man open).
PS: I would have preferred to add that as a comment... but I can't as stackoverflow told me that I don't have enough reputation.
For LINUX users, for some reason if you want to use the raw build straight out of a compile without packaging, add these lines (on top) to the chrome-wrapper file present in the directory.
export GOOGLE_API_KEY="no"
export GOOGLE_DEFAULT_CLIENT_ID="no"
export GOOGLE_DEFAULT_CLIENT_SECRET="no"
and execute chrome by cd to the directory and ./chrome-wrapper and not ./chrome
Make sure you make the necessary changes in the chromium-devel.desktop which maybe in ~/.local/share/applications/ so as to run from the bash script and not from the executable.
I need to start and stop a small server with automator but my knoledge is very limited. I can't manage to set the path where the file is and I don't know how to stop the server.
So far I have this:
on run
set r to display dialog "Start or stop the NINJAM server ?" buttons {"Stop", "Start"}
if button returned of r is "Start" then
#tell application "Terminal"
# activate
do shell script "cd \"/Applications/ MUSIC/ Utilities/Audio IP/NINJAM/NINJAM/NinjamOSXServer ./ninjamsrv Server.cfg\""
#end tell
else
do shell script "Stop"
end if
end run
Any help is really apprectated. Thanks in advance.
NOTE that I'm using my own path here -- I put the ninjam server folder in the top level of my Applications folder.
I had to create a 'term' file, which is a text file with this in it:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>WindowSettings</key>
<array>
<dict>
<key>ExecutionString</key>
<string>cd /Applications/NinjamOSXServer/;./ninjamsrv config.cfg</string>
</dict>
</array>
</dict>
</plist>
I saved this as LaunchNinjamSrvr.term and put it in the same folder as the ninjamsrvr. Then the script to use is:
set r to display dialog "Start or stop the NINJAM server ?" buttons {"Stop", "Start"}
if button returned of r is "Start" then
do shell script "open /Applications/NinjamOSXServer/LaunchNinjamSrvr.term"
else
do shell script "killall -INT -v ninjamsrv"
end if
[Occurs to me that I should give some explanation. Directly using the full path with the " config.cfg" parameter makes 'do shell script' choke. Splitting into two commands (but still using do shell script), like you see in the .term file, works to launch ninjamsrv, but makes the script editor (I use Smile) freeze. So that is (presumably -- I didn't want to test it by other means [script app, etc.]) a problem, and why I resorted to using the .term file. It used to be that you could, from the File menu in Terminal (as I recall), save a .term file directly, but that seems to have fallen by the way-side. So, at this point, I have a template that I use and just paste commands into the appropriate line. (But see http://discussions.apple.com/thread/3139585?start=0&tstart=0 -- wherein the technique of exporting Terminal Preference file is explained). I'm being a bit lazy in that the new form is .terminal, not .term ... anyway ...
So now all that is left is doing the actual AS script. 'open' is a basic command line command which is just like opening or double-clicking in the Finder. If, for some reason your file opens in the wrong app or doesn't open, you might need to map it to Terminal.app (in the get info window) and/or change the extension to the more up--to-date '.terminal'.
killall is like kill, designed to kill processes in various ways. I chose -INT because this is essentially like doing a control-c to interrupt the process.]
I am trying to set a preference for Firefox to open in 32bit mode on 130 macs via Apple Remote Desktop. The easiest way to do this usually is with defaults write unfortunately I havent found any documention on this, and I cant figure out the syntax for writing a string thats not at the root level.
The file is ~/Library/Preferences/com.apple.LaunchServices.plist
I need to change the string x86_64 to i386
<dict>
<key>LSArchitecturesForX86_64v2</key>
<dict>
<key>org.mozilla.firefox</key>
<array>
<data>
Ym9va2QCAAAAAAQQMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAYAEAAAwAAAABAQAAQXBwbGljYXRpb25zCwAAAAEB
AABGaXJlZm94LmFwcAAIAAAAAQYAAAQAAAAYAAAACAAAAAQDAABq
ix4BAAAAAAgAAAAEAwAAWYNjAQAAAAAIAAAAAQYAADwAAABMAAAA
CAAAAAAEAABBtfgZbgAAABgAAAABAgAAAgAAAAAAAAAPAAAAAAAA
AAAAAAAAAAAAAAAAAAEFAAAMAAAAAQEAAE1hY2ludG9zaCBIRAgA
AAAEAwAAAICcregAAAAIAAAAAAQAAEG0QBQYAAAAJAAAAAEBAAA0
NkFGNUYyOC1DNTExLTM0MEMtQkU1RS1DREYzMTgyQThFOTIYAAAA
AQIAAIEAAAABAAgA7z8AAAEACAAAAAAAAQAAAAEAAAABAQAALwAA
AAQAAAADAwAAAAAAIBkAAAABAQAAL0FwcGxpY2F0aW9ucy9GaXJl
Zm94LmFwcAAAAMwAAAD+////AQAAAAAAAAAQAAAABBAAACwAAAAA
AAAABRAAAFwAAAAAAAAAEBAAAHwAAAAAAAAAIBAAABgAAAAAAAAA
MBAAAEwAAAAAAAAAQBAAAGwAAAAAAAAAAiAAACQBAAAAAAAAECAA
AKQAAAAAAAAAESAAANgAAAAAAAAAEiAAALgAAAAAAAAAEyAAAMgA
AAAAAAAAICAAAAQBAAAAAAAAMCAAAJwAAAAAAAAAAdAAAJwAAAAA
AAAAENAAADABAAAAAAAAAP8AADwBAAAAAAAA
</data>
<string>x86_64</string>
</array>
</dict>
I don't think there's a way to do this with defaults (well, there is, but it involves dumping the entire LSArchitecturesForX86_64v2 dictionary, editing it, then reimporting). But PlistBuddy can do the job:
/usr/libexec/PlistBuddy -c "set :LSArchitecturesForX86_64v2:org.mozilla.firefox:1 i386" ~/Library/Preferences/com.apple.LaunchServices.plist
And the usual caveats before deploying anything to 130 computers: test this first (I tried it, once...), and have it back up the relevant file on each computer so if something does go sideways you can roll it back.
Because it was such a mission to get this simple bit of info I've decided to post it for others:
In terminal execute: mkdir ~/.MacOSX
In terminal execute: touch ~/.MacOSX/environment.plist
Browse to the file and open.
Paste:
<key>DISPLAY</key>
<string>:0.0</string>
<key>PYTHONPATH</key>
<string>/full/path/ofyour/favorite/script/dir:/full/path/of/another/script/dir:
Edit to what you need and save.
Here is the documented way to do it with Property List Editor.
Note that you should use caution when setting environment variables this way as they apply to launched GUI applications which might not be expecting them. For setting default environment variables when working in a terminal shell, the conventional UNIX way of using shell profile commands, like .profile or .bash_profile is preferred and less likely to break things.
In terminal execute: mkdir ~/.MacOSX
In terminal execute: touch ~/.MacOSX/environment.plist
Browse to the file and open.
Paste:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>DISPLAY</key>
<string>:0.0</string>
<key>PYTHONPATH</key>
<string>/full/path/ofyour/favorite/script/dir:/full/path/of/another/script/dir:</string>
</dict>
</plist>
Edit to what you need and save.
(This was written by the original poster as part of the question. Reposted as community wiki because I didn't write it, just cleaned up the formatting.)