Easiest CRON Question in the World - RESOLVED
If I wanted to create a CRON job to run a program once, and ONLY once, at 21:00 EST today, and leave the program open until it is closed manually, how would I do it?
|
Easy: use the at program. (Not cron.)
Quote:
|
Quote:
|
Please define "interact". Does the program have a separate (GUI) window, started from a terminal? Or do you have to give input (ie type in words) in the terminal window?
In the first case, running the command that brings up the window in the background might help. In the second case, it won't help, though. |
Quote:
In your case I'd use 'at' command. -- Vladimir unix-news.blogspot.com |
Ok, it's established "at" is what I need. Regarding the interaction, it runs via terminal. It isn't a GUI; just information on what the program is doing and an endline to type special commands. It doesn't seem this can be viewed unless you somehow left a terminal session entirely devoted to it, though... :\
|
There are some tools to interact with an interactive program like the one you describe there.
Search for "expect" for instance. And yes, it'll probably require that you attach it to some terminal window. Running in background will make the program halt every time it asks you to type in some words. Anyway, it is possible to send some commands to your program via stdin. Such technique is often used to script FTP sessions. See "here-doc" operator (<<) in Bash for instance. |
Quote:
I'll mess around a bit when it's a more godly hour of the day. |
I ended up using "nohup", as it allowed the process to run in the background, simply and efficiently. However, now I've another problem: how can I bring the process back to the front? I can't find the job id, as both TOPS and lsof are not permitted at my userlevel on this system.
|
You could try the "jobs" command after you launch them in the backgroup, but the nohup may interfere with this (haven't tested it).
If it works, it'll print the job numbers for all running background processes and you can then use fg %jobnr to bring it to the foreground (once it's on foreground, use Ctrl-Z and "bg" to get it back to background). Also, the $! variable should hold the process ID most recently executed background command. So, if you start your commands like Code:
nohup command1 |
FYI, in the cmd sequence
nohup prog & it's the '&' that backgrounds a job. 'nohup' prevents a prog from terminating when you logout. By default any job/process you start without 'nohup', even if it's backgrounded via '&', will terminate when you logout. Backgrounded jobs are still associated with the initiating terminal, as you'll see if it prints to stdout/stderr, it'll appear in your terminal. |
Quote:
Quote:
Quote:
Have any clue as to how I can get this sucker to the fg, chris? I can kill it instead of bringing it to the front; I don't care. I just need control of the app restored to me. |
Maybe you could do something like:
Code:
your_ccommand & The $! trick may work too. Reading up on job control in "man bash", I also found that "%%" and "%+" refer to the last background job. Maybe you could try this too? Unfortunately, nohup probably interferes with this. It's certainly possible to find all jobs detached from a terminal, but frankly, I doubt that there is a way to attach any random process, using its process ID, to your current terminal/shell so that you can view it's output. |
Quote:
And yes, the referrers to the last background job are screwed up by nohup. |
does fg built-in cmd work ?
fg [jobspec] Resume jobspec in the foreground, and make it the current job. If jobspec is not present, the shell’s notion of the current job is used. The return value is that of the command placed into the foreground, or failure if run when job control is dis- abled or, when run with job control enabled, if jobspec does not specify a valid job or jobspec specifies a job that was started without job control. if not, try ps -ef|grep prog_name and kill pid_of_prog |
All times are GMT -5. The time now is 11:16 PM. |