On Jun 1, 2009, at 12:17 PM, Scott Haneda wrote:
Thanks for all the data, very helpful. So let me test case this, as I still have issues, on the most basic of a test.
On Jun 1, 2009, at 11:58 AM, Damien Sorresso wrote:
On Jun 1, 2009, at 11:29 AM, Scott Haneda wrote:
Hello, first post, I have done my best to hit up nabble archives and see if there are any answers, so far, no luck. I am on 10.5.
Where does one draw the line from stuffing a command into a plist versus having a simple command call a more complicated script, even if the script to be called is not that complicated?
Example: <dict> <key>ProgramArguments</key> <array> <string>/bin/bash /Users/me/Library/Application\ Support/dir/ script</string> </array> </dict> </plist>
The structure of ProgramArguments dictates that you specify one argument per array element. While what you have works, it's only because the shell you're targeting understands it. In other words, don't get in the habit. It's a one-time cost to structure your plist appropriately, and Property List Editor makes it easy.
My bad, sorry, that was a hand typed example, and I would have usually put arg/array correctly.
* How important is it to use full paths to binaries like `echo` and `ls`, as long as I am sure that I have not mucked with the environment variables to them? Are environment variables cleared in launchd, or do user launchd plists need to have care taken to make sure an alias bash alias will get in the way?
I have never been able to get that to work. syslog tells me Jun 1 11:02:47 host com.apple.launchd[155] (com.me.foo[19809]): posix_spawnp("/Users/me/Library/Application Support/dir/ script", ...): No such file or directory Jun 1 11:02:47 host com.apple.launchd[155] (com.me.ALARM[19809]): Exited with exit code: 1
launchd uses posix_spawn(2), which will search _PATH_DEFPATH, which is specified as "/usr/bin:/bin". Personally, I try to always use the full path to an executable. It's just good practice.
Ok, thank you, test case so far is: $cat ~/Library/Application\ Support/launchd-test/tester #!/bin/bash echo `date` >> /Users/me/Desktop/launchdtest.txt echo "this is working" >> /Users/me/Desktop/launchdtest.txt
./tester $cat ~/Desktop/launchdtest.txt Mon Jun 1 12:07:41 PDT 2009 this is working
It works, run interactively at least. I make a launchd item for it. Stored in ~/Library/LaunchAgents/ -rw-r--r-- 1 me staff 479 Jun 1 12:11 com.me.test.foo.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.$ <plist version="1.0"> <dict> <key>Label</key> <string>com.me.test.foo</string> <key>ProgramArguments</key> <array> <string>/bin/bash</string> <string>/Users/me/Library/Application\ Support/ launchd-test/tester</string> </array> <key>RunAtLoad</key> <true/> <key>StartInterval</key> <integer>10</integer> </dict> </plist>
Now, tail the log file, nothing, look at the syslog, every 10 seconds: Jun 1 12:15:11 macbook com.me.test.foo[1010]: /bin/bash: /Users/me/ Library/Application\ Support/launchd-test/tester: No such file or directory Jun 1 12:15:11 macbook com.apple.launchd[123] (com.me.test.foo [1010]): Exited with exit code: 127
I will look into the "WorkingDirectory" now, but I am stumped as to why this should not work as is. Thanks again for the pointers.
You're still escaping the space in "Application Support" unnecessarily. launchd is not a shell interpreter, and the contents of each element of ProgramArgument is passed directly to posix_spawn(2), so you don't need to escape anything. Use this instead:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs /PropertyList-1.0.$ <plist version="1.0"> <dict> <key>Label</key> <string>com.me.test.foo</string> <key>ProgramArguments</key> <array> <string>/bin/bash</string> <string>/Users/me/Library/Application Support/launchd- test/tester</string> </array> <key>RunAtLoad</key> <true/> <key>StartInterval</key> <integer>10</integer> </dict> </plist> -- Damien Sorresso BSD Engineering Apple Inc.