osascript - Page 2

porkchop_d_clown · 04-26-2002, 03:19 PM

Well, I will admit that I'm stumped. I can't even figure out how to get the Mac to execute a script when you log in - putting a shell script or even a "run time only" applescript in the login preferences will only cause an editor window to pop up the next time you log in.

Manually set the environment in the cron job to match the terminal environment. No effect. Tried using su -l to simulate a log in, no effect.

The weirdest part is that running the script completely disconnected from a Terminal still works; and so does logging into the iBook from a remote machine (over ssh) and executing the script!

Could it have something to do with cron running as root?

porkchop_d_clown · 04-26-2002, 03:54 PM

Okay....

In the previous message I said that if you ran an apple script from a remote login it could contact the Finder. But, after I rebooted my machine (for another problem) and tried the test again, I got the same error message you get when you run
from cron!

Quote:


	ssh ibook [ibook:~] mheinz% random_background execution error: Finder got an error: Application isn't running (-600)

At least this provides some useful data. I wish I knew what the IPC mechanism is that Applescript uses to communicate with different applications. This makes it sound like the problem is related to process groups or process parents, but I really don't know.

mervTormel · 04-26-2002, 05:40 PM

Quote:


	Originally posted by porkchop_d_clown What is a "headless" application? I know about background apps, foreground apps, daemons, nohup and kernelspace, but I've never run into a "headless" application.

a headless process is one that has no controlling terminal or user interface; no notion of a 'desktop'. an example is a daemon. it's got no head (monitor).

for example:

Code:

$ ps x -U root
  PID  TT  STAT      TIME COMMAND
    1  ??  SLs    0:00.57 /sbin/init     
    2  ??  SL     0:06.13 /sbin/mach_init        
   41  ??  Ss     0:00.00 kextd
   71  ??  Ss     0:15.96 update
...

honestpuck · 04-26-2002, 09:40 PM

Quote:


	Originally posted by porkchop_d_clown What is a "headless" application? I know about background apps, foreground apps, daemons, nohup and kernelspace, but I've never run into a "headless" application.

OK. I use the term from my days back writing for XWindows. A "headless" app is one that doesn't expose itself to the GUI interface. Most of what we consider terminal commands are headless apps, but we usually run them from inside an app with a "head" or GUI front end - namely Terminal.

From that we can see that a "daemon" is a headless app that is designed never to terminate and communicates with the outside world through some other I/O method than the GUI (such as Apache). A "background" app is a headless app that we have disengaged from the terminal, the best example on my computer would be the OS X setiathome client.

That's the way we used to define the terms back in the eighties on Unix systems.

You then run into a problem when a headless application that is designed to run exposed to the memory and/or process parenthood of the GUI, i.e. by being run inside an application with a head, is run outside it - it can't communicate with stuff inside the GUI.

When you mentioned that cron "doesn't load the user's environment when it executes" you're getting close. It's not so much that it doesn't load the user environment (it loads bits of it - get cron to run a shell script that just pipes the output of 'set' to a text file and you'll see), it's that it doesn't provide a chain of process parenthood back to the GUI. So I think Apple is using some method of IPC in osascript that relies on that common ancestry. That's also where my knowledge starts getting ragged - I don't know enough about how the various IPC methods are designed and implemented to come up with a good solution.

I'm thinking about it. I've also started talking to some heavyweight Unix folks. This is a really interesting problem. One of the solutions proposed to me by an older and wiser XWindows programmer was to have the GUI launch an application at startup that then acts as an osascript launcher. How you would communicate with that is another question but ICMP was the suggestion.

Tony

honestpuck · 04-26-2002, 09:53 PM

Quote:


	Originally posted by porkchop_d_clown Well, I will admit that I'm stumped. I can't even figure out how to get the Mac to execute a script when you log in - putting a shell script or even a "run time only" applescript in the login preferences will only cause an editor window to pop up the next time you log in.

Porkchop,

For AppleScripts save them as an application and they'll run from the login preferences no problems. For shell scripts you can either put a call to them in ~/.login if you only want them running at terminal login or put the call to them in /etc/rc.local for running at system startup.

Tony

wayneyoung · 04-27-2002, 10:28 AM

I can confirm this works when used in cron. Based on this thread http://forums.macosxhints.com/showth...&threadid=2440 adding open ~/picset to my crontab, where the applescript application "picset" is do shell script "/Users/wayne/timepictures.pl" I got the desired results, picset runs every five minutes.

Wayne

honestpuck · 04-27-2002, 10:39 AM

Quote:


	Originally posted by wayneyoung I can confirm this works when used in cron. Based on this thread http://forums.macosxhints.com/showth...&threadid=2440 adding open ~/picset to my crontab, where the applescript application "picset" is do shell script "/Users/wayne/timepictures.pl" I got the desired results, picset runs every five minutes. Wayne

To which I give a massive cheer.

Glad I could help you solve that one, Wayne. Now I just need 48 of your pictures of Waikiki so I can run it every half hour on my Mac.

BTW - How intrusive do you find the picset application?

Tony

wayneyoung · 04-27-2002, 10:45 AM

Thank you Tony. For my application being intrusive, I would say for me it is no big deal. I see the Applescript icon pop up in my dock every five minutes, then the picture changes. Some might find that annoying, but I can accept it.

bakaDeshi · 04-27-2002, 11:49 AM

Quote:


	Originally posted by honestpuck ...<snip> method of IPC in osascript that relies on that common ancestry. That's also where my knowledge starts getting ragged - I don't know enough about how the various IPC methods are designed and implemented to come up with a good solution. I'm thinking about it. I've also started talking to some heavyweight Unix folks. This is a really interesting problem. One of the solutions proposed to me by an older and wiser XWindows programmer was to have the GUI launch an application at startup that then acts as an osascript launcher. How you would communicate with that is another question but ICMP was the suggestion. Tony

Tony,

IPC? ICMP? What do they stand for? I'm getting pretty good at unix but one of the big difficulties is the high learning curve and the excessive use of acronyms and the assumption that you know what they are. Please explain. I'm sure I'm not the only one who said huh?

Thanks.

p.s. Interesting problem.

-chris

honestpuck · 04-27-2002, 01:40 PM

Quote:


	Originally posted by bakaDeshi Tony, IPC? ICMP? What do they stand for? I'm getting pretty good at unix but one of the big difficulties is the high learning curve and the excessive use of acronyms and the assumption that you know what they are. Please explain. I'm sure I'm not the only one who said huh? Thanks. p.s. Interesting problem. -chris

IPC = Inter Process Communications.

ICMP = Internet Control Message Prolocol.

ICMP is an extension to IP defined in RFC 792.

The best place for any of this sort of stuff is http://www.webopedia.com/ and you can find the RFCs for those who really like the technical stuff at http://www.faqs.org/rfcs/

Tony

porkchop_d_clown · 04-27-2002, 10:52 PM

tony,

"Headless" - Ah. I've been working on Unix boxes for 20 years now, I never ran into that term before - we always just called it "running in the background".

As for putting things in .login - unfortunately, it looks like .login gets run everytime you open a terminal window; dunno why - but if I add a line to ~/Library/init/tcsh/login.mine it will get processed for every Terminal window.

Heh. This shouldn't be this hard! When I started looking at it I thought I'd find an answer in 10 minutes or so...

mervTormel · 04-27-2002, 11:39 PM

it's true, every new terminal app window runs login (foolishly ? the court's still out)

one of the robust things code should do is to not assume anything about its environment.

porkchop, one thing you can do is leave evidence that your task has completed via the first login to terminal, then wrap your call in some 'error handling' scriptage that checks this evidence and skips it if evidence is found.

then, of course, you have to cleanup the evidence somehow. but there are some tricks.

--
if it was easy, we wouldn't call it code.

porkchop_d_clown · 04-27-2002, 11:46 PM

I thought about using some kind of flashed-up semaphore thing (a lock file or similar) to prevent multiple executions; I just don't like it - I want an elegant solution, darn it!

:-P

grepping through the process table for yourself is another approach; but it still seems harder than needed.

I wonder if there's any documentation on Applescript in multi-user environments....

honestpuck · 04-28-2002, 12:47 AM

Quote:


	Originally posted by porkchop_d_clown I thought about using some kind of flashed-up semaphore thing (a lock file or similar) to prevent multiple executions; I just don't like it - I want an elegant solution, darn it! :-P grepping through the process table for yourself is another approach; but it still seems harder than needed. I wonder if there's any documentation on Applescript in multi-user environments....

Well if you only want to run a shell script when you log into the box, not every time you open a terminal window there is an easy hack. Create an empty file called ".boxlogin" in everyone's home directory and then create an Applescript application that does a 'do shell script ~/.boxlogin' call to that shell script. Now add that to your login items preferences. Anyone who wants to run a shell command only when they log into the box just adds it to ".boxlogin" If you set the boxlogin AS application to "Hide" in login items then people won't even know it has been run. It will just silently do it's work once for every login.

You might want to put ~/.boxlogin at one remove by getting the AS to call another script that calls ~/.boxlogin using nohup and background it so that the AS can return quickly and never hang if it gets some bad process in a users ~/boxlogin file. Or you could test to see if the "do shell script" call will support "/bin/sh nohup nice -10 ~/.boxlogin 2&> ~/.boxlogin.out &"

Tony

bluehz · 04-28-2002, 09:26 AM

This works great - but I was wondering if there is a way to prevent the front-end Applescript app from taking over and coming to the front when it is run. In other words a TRUE background app.

Any ideas?

Quote:


	Originally posted by wayneyoung I can confirm this works when used in cron. Based on this thread http://forums.macosxhints.com/showth...&threadid=2440 adding open ~/picset to my crontab, where the applescript application "picset" is do shell script "/Users/wayne/timepictures.pl" I got the desired results, picset runs every five minutes. Wayne

honestpuck · 04-29-2002, 06:40 AM

bluehz,

I'm working on it, I'm working on it. I thought I could maybe build a "fake" terminal using expect, but that failed too. It really does look like I'm going to have to figure out how to write a background application in C to fix this problem - of course Apple fixing osascript would be ideal

At least anything you run at box logon should be OK as you can specify "hide" and it should never appear. I haven't tested it, though - are you saying that it still appears? That would be a MAJOR disappointment.

Tony

porkchop_d_clown · 04-29-2002, 09:31 AM

Tony,

What about a small C program that read a list of script names and forked off a background process for each one?

bluehz · 04-29-2002, 09:34 AM

The technique works great in terms of functionality - the sh is firing through cron and all is well. My only complaint is purely aesthetic. For example lets say I am typing in a text editor and the cron job fires - the "headless" AS app launches and switches to itself briefly before quitting and returning to the text editor. If I am not watching what is going on I keep typing and can possibly lose typed material during that process. Granted it is only a few secs - more an annoyance than anything.

What about using the "ignoring response" stuff in AS? I am not real familiar with that and I have not tested myself?

honestpuck · 04-29-2002, 10:48 AM

Quote:


	Originally posted by porkchop_d_clown Tony, What about a small C program that read a list of script names and forked off a background process for each one?

Aaah, yeah something like that. Problem is that it has to start it's life from the GUI so that it can run 'osascript' and not have it gakk with an "application not found" error. I've almost managed to write a Macintosh application, but a Mac background application is still beyond me.

If I could get a background app working I'd actually consider getting it to listen for ICMP packets on a nice high IP port, then you could just send it the Applescript you want run buried in an ICMP packet and it could do a sys call to run osascript for you. From the "Terminal" side I could write a Perl app to handle sending the ICMP packet, that's no problem. This has the advantage that not only would it get over the osascript problem but you could actually run scripts across a network.

It's going to take me some time, but I'm going to do it - if not to solve this problem then just for the sheer joy of building such a neat hack.

Tony

porkchop_d_clown · 04-29-2002, 10:58 AM

I tried a simple program that did a vfork and exec and promptly discovered that UNIX binaries won't run as login items and can be run by double-clicking their icons.

Is there some file extension I should put on a simple binary to tell the Mac that it's executable?

04-26-2002, 03:19 PM	#21
porkchop_d_clown Triple-A Player Join Date: Jan 2002 Location: Phoenixville, PA Posts: 127	Ugh. This is a pain. Well, I will admit that I'm stumped. I can't even figure out how to get the Mac to execute a script when you log in - putting a shell script or even a "run time only" applescript in the login preferences will only cause an editor window to pop up the next time you log in. Manually set the environment in the cron job to match the terminal environment. No effect. Tried using su -l to simulate a log in, no effect. The weirdest part is that running the script completely disconnected from a Terminal still works; and so does logging into the iBook from a remote machine (over ssh) and executing the script! Could it have something to do with cron running as root? __________________ Knock Knock.

04-27-2002, 10:52 PM	#31
porkchop_d_clown Triple-A Player Join Date: Jan 2002 Location: Phoenixville, PA Posts: 127	Must be from a different background... tony, "Headless" - Ah. I've been working on Unix boxes for 20 years now, I never ran into that term before - we always just called it "running in the background". As for putting things in .login - unfortunately, it looks like .login gets run everytime you open a terminal window; dunno why - but if I add a line to ~/Library/init/tcsh/login.mine it will get processed for every Terminal window. Heh. This shouldn't be this hard! When I started looking at it I thought I'd find an answer in 10 minutes or so... __________________ Knock Knock.

04-27-2002, 11:46 PM	#33
porkchop_d_clown Triple-A Player Join Date: Jan 2002 Location: Phoenixville, PA Posts: 127	I thought about that... I thought about using some kind of flashed-up semaphore thing (a lock file or similar) to prevent multiple executions; I just don't like it - I want an elegant solution, darn it! :-P grepping through the process table for yourself is another approach; but it still seems harder than needed. I wonder if there's any documentation on Applescript in multi-user environments.... __________________ Knock Knock.

04-29-2002, 06:40 AM	#36
honestpuck Major Leaguer Join Date: Apr 2002 Location: Sydney, Australia Posts: 256	bluehz, I'm working on it, I'm working on it. I thought I could maybe build a "fake" terminal using expect, but that failed too. It really does look like I'm going to have to figure out how to write a background application in C to fix this problem - of course Apple fixing osascript would be ideal At least anything you run at box logon should be OK as you can specify "hide" and it should never appear. I haven't tested it, though - are you saying that it still appears? That would be a MAJOR disappointment. Tony Last edited by honestpuck; 04-29-2002 at 06:45 AM.

04-29-2002, 09:31 AM	#37
porkchop_d_clown Triple-A Player Join Date: Jan 2002 Location: Phoenixville, PA Posts: 127	What about? Tony, What about a small C program that read a list of script names and forked off a background process for each one? __________________ Knock Knock.

04-27-2002, 10:28 AM	#26
wayneyoung Triple-A Player Join Date: Jan 2002 Location: Colorado Springs, CO Posts: 216	I can confirm this works when used in cron. Based on this thread http://forums.macosxhints.com/showth...&threadid=2440 adding open ~/picset to my crontab, where the applescript application "picset" is do shell script "/Users/wayne/timepictures.pl" I got the desired results, picset runs every five minutes. Wayne

04-27-2002, 10:45 AM	#28
wayneyoung Triple-A Player Join Date: Jan 2002 Location: Colorado Springs, CO Posts: 216	Thank you Tony. For my application being intrusive, I would say for me it is no big deal. I see the Applescript icon pop up in my dock every five minutes, then the picture changes. Some might find that annoying, but I can accept it.

04-27-2002, 11:39 PM	#32
mervTormel League Commissioner Join Date: Jan 2002 Posts: 5,536	it's true, every new terminal app window runs login (foolishly ? the court's still out) one of the robust things code should do is to not assume anything about its environment. porkchop, one thing you can do is leave evidence that your task has completed via the first login to terminal, then wrap your call in some 'error handling' scriptage that checks this evidence and skips it if evidence is found. then, of course, you have to cleanup the evidence somehow. but there are some tricks. -- if it was easy, we wouldn't call it code.

04-29-2002, 09:34 AM	#38
bluehz MVP Join Date: Jan 2002 Posts: 1,562	The technique works great in terms of functionality - the sh is firing through cron and all is well. My only complaint is purely aesthetic. For example lets say I am typing in a text editor and the cron job fires - the "headless" AS app launches and switches to itself briefly before quitting and returning to the text editor. If I am not watching what is going on I keep typing and can possibly lose typed material during that process. Granted it is only a few secs - more an annoyance than anything. What about using the "ignoring response" stuff in AS? I am not real familiar with that and I have not tested myself?

04-29-2002, 10:58 AM	#40
porkchop_d_clown Triple-A Player Join Date: Jan 2002 Location: Phoenixville, PA Posts: 127	Hack is right... I tried a simple program that did a vfork and exec and promptly discovered that UNIX binaries won't run as login items and can be run by double-clicking their icons. Is there some file extension I should put on a simple binary to tell the Mac that it's executable? __________________ Knock Knock.