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.)

I don't follow. What is the program?

Okay, here's the deal: it's a linux webserver. I have shell access, and would like to set up a script that runs the Ventrilo voice server. This program runs in terminal, and stays open until you quit it. I don't want this program to stop, and really ideally I'd like to somehow be able to interact with it... that makes it more complex, I realize.

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.

Why cron? cron is designed for periodically schedule processing.

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.

Aahh... very good leads. I'll play around with it. This shouldn't be too tricky since the prog really just does its thing until I tell it to do something different... it never "prompts" for input, it just allows for it.

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
then you should be able to access the processes via the different process IDs ($pid1, $pid2, etc).

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.

The nohup command does indeed interfere with that. It lists nothing. To make sure I wasn't insane, I started a job ("man jobs" as it so happens) and used Ctrl+Z to stop it, then ran jobs again. This time it listed man jobs as a stopped process with id #1.

After I figure out how to get this process, I'll make a script that does what you just described. Thanks.


Right. I had forgotten that.

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:
Disown seems to do prevent SIGHUP signals from the exiting shell too, but the -h options prevents deletion from the table of active jobs.

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.

Executing the first command starts another instance of the program, which is no good; I need to get to the original instance already started. The second command returns "-bash: disown: current: no such job".

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