Re: Short question
The thread went background so you killing it has no effect until they'll wait for input ;-) - Aviram Jenik "Addicted to Chaos" - Today's quote: Top 25 Explanations by Programmers when their programs don't work: 12. You must have the wrong executable. - Original Message - From: Yaron Zabary <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, August 11, 1999 8:17 Night Subject: Re: Short question > > Die thread, die. > > -- Yaron. > > > = > To unsubscribe, send mail to [EMAIL PROTECTED] with > the word "unsubscribe" in the message body, e.g., run the command > echo unsubscribe | mail [EMAIL PROTECTED] > > = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Short question
Die thread, die. -- Yaron. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Short question
In <[EMAIL PROTECTED]>, Ariel Biener <[EMAIL PROTECTED]> writes: > I was referring to something else completely, and thus this > misunderstanding. > > To better explain. > > If you try backgrounding a process why it waits for input: > > host:~> ftp host > ftp> ^Z > Suspended > host:~> bg > [1]ftp ftp & > host:~> > [1] + Suspended (tty input) ftp ftp > host:~> exit > There are suspended jobs. > host:~> kill -9 $$ Just remember, this has nothing to do with the kernel sending anyone signals. A stupid process can continue trying to read from its nonexistent terminal forever. This is an application issue, not a system issue. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Short question
On 11 Aug 1999, Adam Morrison wrote:
No, you're right.
I was referring to something else completely, and thus this
misunderstanding.
To better explain.
If you try backgrounding a process why it waits for input:
host:~> ftp host
ftp> ^Z
Suspended
host:~> bg
[1]ftp ftp &
host:~>
[1] + Suspended (tty input) ftp ftp
host:~> exit
There are suspended jobs.
host:~> kill -9 $$
ssh host ...
host:~> ps ax|grep ftp|grep -v grep
host:~>
Naturally, if you first do:
ftp> get somefile
^Z
host:~> bg
host:~> exit
it will work, since it's not suspended at tty input.
anyway, I apologize for this long thread, I was going to a rather
different direction than what was asked here...
and you are right of course Adam.
--Ariel
> In <[EMAIL PROTECTED]>, Ariel Biener
><[EMAIL PROTECTED]> writes:
>
> > Second, ftp WILL exit when it loses the control terminal. Try it, from
> > bash or tcsh.
>
> I explained this behavior previously.
>
> When the terminal goes away, the program will start getting
> errors on write()s to the terminal.Whether it exits or not
> at that point depends on how well it is written.
>
> Simply, if ftp attempts to receive input from the user and fails, it
> exits.This is correct behavior, why should it stick around?
>
> Therefore, when using a shell with job control, it's quite
> straightforward to do the following:
>
> ftp> get big-file
> 150 Opening BINARY mode data connection for big-file (lots of bytes).
> ^Z
> Suspended
> % bg
> [1] ftp
> % exit
>
> When ftp finishes the transfer, it'll exit by itself because of the
> above mentioned condition.(It doesn't try reading from the terminal
> while transferring the file.)Come to think of it, I've been doing
> this forever!
>
> Because ftp is run in a background process group, the kernel doesn't
> send it a SIGHUP when the shell exits.Had you run something similar
> from a shell without job control (which isn't as simple as the example
> above, since you can't suspend and `bg' jobs in a shell WITHOUT job
> control!), then ftp would die immediately when the shell exited.
>
> > In fact, most Unix utilities will exit when losing the control terminal.
>
> If the application expects to get input, and it can't do so (because
> it lost its terminal), I'd expect it to exit.Like I said, that's
> correct behavior.
>
> To decide based on observing this behavior that job control doesn't
> work, which is basically what you were saying... that's quite a
> stretch.
>
> > You are welcome to prove me otherwise, and this way I might learn
> > something.
>
> I explained what's going on, twice.
>
> Which part were you disputing, exactly?
>
> The fact that background jobs started from a shell with job control
> don't die when the shell exits?
>
> bash$ sleep 666 &
> [1] 31187
> bash$ exit
> Connection to linux-box closed.
> % ssh linux-box
> Last login: Wed Aug 11 19:00:46 1999 from vortex
> You have new mail.
> bash$ ps -p 31187
> PID TTY TIME CMD
> 31187 ? 00:00:00 sleep
>
>
> Or my explanation of how job control works?
>
> $ cat wrapper.c
> #include
> #include
> #include
>
> int
> main(int argc, char **argv)
> {
> if (argc < 3) {
> fprintf(stderr, "usage: wrapper path args\n");
> return (1);
> }
> if (setpgid(0, getpid()) == -1) {
> perror("setpgid");
> return (1);
> }
> if (execv(argv[1], &argv[2]) == -1) {
> perror("exec");
> return (1);
> }
> /*NOTREACHED*/
> }
> $ gcc -o setpgid wrapper.c
> $ ./setpgid /usr/bin/sleep sleep 666 &
> 9616
> $ exit
> Connection to solaris-box closed.
> % ssh solaris-box
> Last login: Wed Aug 11 11:23:52 1999from vortex
> Sun Microsystems Inc. SunOS 5.6 Generic August 1997
> You have mail.
> $ ps -p 9616
>PID TTY TIME CMD
> 9616 ?0:00 sleep
> $ sleep 666 &
> 9624
> $ exit
> Connection to solaris-box closed.
> % ssh solaris-box
> Last login: Wed Aug 11 11:33:52 from vortex
> Sun Microsystems Inc. SunOS 5.6 Generic August 1997
> You have mail.
> $ ps -p 9624
>PID TTY TIME CMD
> $ exit
>
>
> =
> To unsubscribe, send mail to [EMAIL PROTECTED] with
> the word "unsubscribe" in the message body, e.g., run the command
> echo unsubscribe | mail [EMAIL PROTECTED]
>
--
Ariel Biener
e-mail: [EMAIL PROTECTED] Work phone: 03-640608
fingerprint = 07 D1 E5 3E EF 6D E5 82 0B E9 21 D4 3C 7D 8B BC
=
To unsubscrib
Re: Short question
In <[EMAIL PROTECTED]>, Ariel Biener
<[EMAIL PROTECTED]> writes:
> Second, ftp WILL exit when it loses the control terminal. Try it, from
> bash or tcsh.
I explained this behavior previously.
When the terminal goes away, the program will start getting
errors on write()s to the terminal. Whether it exits or not
at that point depends on how well it is written.
Simply, if ftp attempts to receive input from the user and fails, it
exits. This is correct behavior, why should it stick around?
Therefore, when using a shell with job control, it's quite
straightforward to do the following:
ftp> get big-file
150 Opening BINARY mode data connection for big-file (lots of bytes).
^Z
Suspended
% bg
[1] ftp
% exit
When ftp finishes the transfer, it'll exit by itself because of the
above mentioned condition. (It doesn't try reading from the terminal
while transferring the file.) Come to think of it, I've been doing
this forever!
Because ftp is run in a background process group, the kernel doesn't
send it a SIGHUP when the shell exits. Had you run something similar
from a shell without job control (which isn't as simple as the example
above, since you can't suspend and `bg' jobs in a shell WITHOUT job
control!), then ftp would die immediately when the shell exited.
> In fact, most Unix utilities will exit when losing the control terminal.
If the application expects to get input, and it can't do so (because
it lost its terminal), I'd expect it to exit. Like I said, that's
correct behavior.
To decide based on observing this behavior that job control doesn't
work, which is basically what you were saying... that's quite a
stretch.
> You are welcome to prove me otherwise, and this way I might learn
> something.
I explained what's going on, twice.
Which part were you disputing, exactly?
The fact that background jobs started from a shell with job control
don't die when the shell exits?
bash$ sleep 666 &
[1] 31187
bash$ exit
Connection to linux-box closed.
% ssh linux-box
Last login: Wed Aug 11 19:00:46 1999 from vortex
You have new mail.
bash$ ps -p 31187
PID TTY TIME CMD
31187 ?00:00:00 sleep
Or my explanation of how job control works?
$ cat wrapper.c
#include
#include
#include
int
main(int argc, char **argv)
{
if (argc < 3) {
fprintf(stderr, "usage: wrapper path args\n");
return (1);
}
if (setpgid(0, getpid()) == -1) {
perror("setpgid");
return (1);
}
if (execv(argv[1], &argv[2]) == -1) {
perror("exec");
return (1);
}
/*NOTREACHED*/
}
$ gcc -o setpgid wrapper.c
$ ./setpgid /usr/bin/sleep sleep 666 &
9616
$ exit
Connection to solaris-box closed.
% ssh solaris-box
Last login: Wed Aug 11 11:23:52 1999 from vortex
Sun Microsystems Inc. SunOS 5.6 Generic August 1997
You have mail.
$ ps -p 9616
PID TTY TIME CMD
9616 ?0:00 sleep
$ sleep 666 &
9624
$ exit
Connection to solaris-box closed.
% ssh solaris-box
Last login: Wed Aug 11 11:33:52 from vortex
Sun Microsystems Inc. SunOS 5.6 Generic August 1997
You have mail.
$ ps -p 9624
PID TTY TIME CMD
$ exit
=
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
Re: Short question
On Wed, 11 Aug 1999, Stanislav Malyshev a.k.a Frodo wrote: THANKS ! FInally a sane voice among the croud. What I meant is that most Unix utils are designed to DO SOMETHING when they look for the control terminal (waiting for input, or write output), and they have a decision making clause when they don't find it anymore. Most just exit when they don't find it. --Ariel > AB>> In fact, most Unix utilities will exit when losing the control terminal. > > Depends on what do you mean on "losing". If you do the following: > > run ftp > background it while it's busy (i.e., not reading from terminal, like in > downloading) > desintegrate parent shell process (like kill -9) > > then ftp will happily survive. You'll lose any communication ability to > it, though, and it will exit as soon as it tries to read user input > (like, on finishing download). So it's practical to use screen when > available. > > The point is that the absence of the controlling terminal by itself won't > kill ftp, it's the shell that is losing it would. If you prevent shell > from touching ftp, it will happily proceed until it needs terminal by > itself. Then it discovers that it's gone and will decide what to do. > -- > [EMAIL PROTECTED]\/There shall be counsels taken > Stanislav Malyshev/\Stronger than Morgul-spells > phone +972-3-9316425 /\ JRRT LotR. > http://sharat.co.il/frodo/whois:!SM8333 > > > > > = > To unsubscribe, send mail to [EMAIL PROTECTED] with > the word "unsubscribe" in the message body, e.g., run the command > echo unsubscribe | mail [EMAIL PROTECTED] > -- Ariel Biener e-mail: [EMAIL PROTECTED] Work phone: 03-640608 fingerprint = 07 D1 E5 3E EF 6D E5 82 0B E9 21 D4 3C 7D 8B BC = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Short question
AB>> In fact, most Unix utilities will exit when losing the control terminal. Depends on what do you mean on "losing". If you do the following: run ftp background it while it's busy (i.e., not reading from terminal, like in downloading) desintegrate parent shell process (like kill -9) then ftp will happily survive. You'll lose any communication ability to it, though, and it will exit as soon as it tries to read user input (like, on finishing download). So it's practical to use screen when available. The point is that the absence of the controlling terminal by itself won't kill ftp, it's the shell that is losing it would. If you prevent shell from touching ftp, it will happily proceed until it needs terminal by itself. Then it discovers that it's gone and will decide what to do. -- [EMAIL PROTECTED] \/ There shall be counsels taken Stanislav Malyshev /\ Stronger than Morgul-spells phone +972-3-9316425/\ JRRT LotR. http://sharat.co.il/frodo/ whois:!SM8333 = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Short question
On 11 Aug 1999, Adam Morrison wrote: First of all, I said jobs wont exit when run with nohup, unless your reading capability is less than your unix knowledge. Second, ftp WILL exit when it loses the control terminal. Try it, from bash or tcsh. In fact, most Unix utilities will exit when losing the control terminal. You are welcome to prove me otherwise, and this way I might learn something. --Ariel -- Ariel Biener e-mail: [EMAIL PROTECTED] Work phone: 03-640608 fingerprint = 07 D1 E5 3E EF 6D E5 82 0B E9 21 D4 3C 7D 8B BC = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Short question
In <[EMAIL PROTECTED]>, Ariel Biener <[EMAIL PROTECTED]> writes: > Most things you run in the backround (like ftp, irc, and such) install > their own handlers. ``Oh, really?'' % find /usr/src/usr.bin/ftp/ | xargs grep SIGHUP % And as for IRC, it EXITS on a SIGHUP. % find ircii-2.8.2 | xargs grep SIGHUP ircii-2.8.2/source/irc.c: (void) MY_SIGNAL(SIGHUP, irc_exit, 0); ircii-2.8.2/ChangeLog: handlers for SIGHUP/SIGTERM that call irc_exit(). > In fact, you have to know for sure that the job you run has not installed > a signal handler. What are you talking about? In my previous message, I explained why any program that deals with SIGHUP won't exit when executed from a shell without job control. If it was run with nohup(1), it will ignore the SIGHUP sent by the kernel and continue running. If it installs its own signal handler, that handler will be run; the program will exit only if its handler causes it to exit, e.g. IRC. With jobs run from shells with job control, the SIGHUP isn't sent in the first place. That's the correct way to do things, btw; why kludge around and disable a signal (nohup) when the kernel offers job control primitives to do what you want? Fortunately, modern shells have job control. > So, practically, the job must: > > 1). not be interactive. Depends. If you expect to run something in the background and still be able to type input into it, that (of course) won't work. But expecting that is as reasonable as expecting a ^C you type to the shell to interrupt background jobs as well. As for output, as long as the terminal is there you'll see the output (unless the program notices its in the background and stops producing output). When the terminal goes away, the program will start getting errors on write()s to the terminal. Whether it exits or not at that point depends on how well it is written. > 2). not install it's own handler. That has nothing to do with anything, unless the handler causes the program to exit. Which is why nohup is evil, imho. USE A SHELL WITH JOB CONTROL. > If you can make sure that it answers these criteria, then it will work. > (like backgrounding a matlab job). > > If you can't, then you'd better use nohup or screen. You said jobs run with nohup will ``terminate as soon as they are detached from the controlling terminal''. > > --Ariel > > > P.S. Notice that I am more concerned in giving practical answers, than > theoretical ones. Notice that I am more concerned with giving answers that are based on reality than incorrect ones. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Short question
On 11 Aug 1999, Adam Morrison wrote: Hi Adam, Most things you run in the backround (like ftp, irc, and such) install their own handlers. In fact, you have to know for sure that the job you run has not installed a signal handler. So, practically, the job must: 1). not be interactive. 2). not install it's own handler. If you can make sure that it answers these criteria, then it will work. (like backgrounding a matlab job). If you can't, then you'd better use nohup or screen. --Ariel P.S. Notice that I am more concerned in giving practical answers, than theoretical ones. > Oh, really? > > A ``job'' is a process group.When a session leader (e.g. a shell) > exits, the kernel checks whether there is a controlling terminal > associated with its session.If so, the foreground process group of > that terminal is signaled with exactly one ``signals'', SIGHUP. > > Shells without job control don't deal with process groups at all, and > so all their children get SIGHUP'd when they exit.For these cases, > nohup(1) simply invokes commands with SIGHUP ignored.(Obviously, if > you run a program that independently installs a SIGHUP handler with > `&' under sh, that handler will get called when the shell exits, which > may or may not be alright.) > > Shells with job control (csh descendants, bash, some incarnations of > sh, etc) have, well, JOB CONTROL.Jobs are started in their own > process groups, and the shell changes the terminal's foreground > process group whenever a job is brought into the foreground (e.g. with > `fg').Therefore, the kernel won't send a SIGHUP to background jobs. > > > = > To unsubscribe, send mail to [EMAIL PROTECTED] with > the word "unsubscribe" in the message body, e.g., run the command > echo unsubscribe | mail [EMAIL PROTECTED] > -- Ariel Biener e-mail: [EMAIL PROTECTED] Work phone: 03-640608 fingerprint = 07 D1 E5 3E EF 6D E5 82 0B E9 21 D4 3C 7D 8B BC = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Short question
In <[EMAIL PROTECTED]>, Ariel Biener <[EMAIL PROTECTED]> writes: > > > Does anybody know a shell command that allows me to run something in the > > > background immediately? > > > > Use nohup if you're using a Bourne shell (sh) descendant. > > > > Just use `&' if you're using a C shell (csh) descendant. > > Both will terminate as soon as they are detached from the controlling > terminal. Backgrounding jobs using `&' require that the job be configured > (compiled in that way) to ignore some signals from the controlling > terminal, in order for them not to terminate when the controlling terminal > is killed. Oh, really? A ``job'' is a process group. When a session leader (e.g. a shell) exits, the kernel checks whether there is a controlling terminal associated with its session. If so, the foreground process group of that terminal is signaled with exactly one ``signals'', SIGHUP. Shells without job control don't deal with process groups at all, and so all their children get SIGHUP'd when they exit. For these cases, nohup(1) simply invokes commands with SIGHUP ignored. (Obviously, if you run a program that independently installs a SIGHUP handler with `&' under sh, that handler will get called when the shell exits, which may or may not be alright.) Shells with job control (csh descendants, bash, some incarnations of sh, etc) have, well, JOB CONTROL. Jobs are started in their own process groups, and the shell changes the terminal's foreground process group whenever a job is brought into the foreground (e.g. with `fg'). Therefore, the kernel won't send a SIGHUP to background jobs. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Short question
On 10 Aug 1999, Adam Morrison wrote: > In <[EMAIL PROTECTED]>, Isaac Aaron <[EMAIL PROTECTED]> writes: > > > Does anybody know a shell command that allows me to run something in the > > background immediately? > > Use nohup if you're using a Bourne shell (sh) descendant. > > Just use `&' if you're using a C shell (csh) descendant. > > For this purpose, bash (the bastard shell) compiled with job control, > acts as a csh descendant. Both will terminate as soon as they are detached from the controlling terminal. Backgrounding jobs using `&' require that the job be configured (compiled in that way) to ignore some signals from the controlling terminal, in order for them not to terminate when the controlling terminal is killed. --Ariel > > > = > To unsubscribe, send mail to [EMAIL PROTECTED] with > the word "unsubscribe" in the message body, e.g., run the command > echo unsubscribe | mail [EMAIL PROTECTED] > -- Ariel Biener e-mail: [EMAIL PROTECTED] Work phone: 03-640608 fingerprint = 07 D1 E5 3E EF 6D E5 82 0B E9 21 D4 3C 7D 8B BC = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Short question
In <[EMAIL PROTECTED]>, Isaac Aaron <[EMAIL PROTECTED]> writes: > Does anybody know a shell command that allows me to run something in the > background immediately? Use nohup if you're using a Bourne shell (sh) descendant. Just use `&' if you're using a C shell (csh) descendant. For this purpose, bash (the bastard shell) compiled with job control, acts as a csh descendant. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Short question
On Mon, 9 Aug 1999, Isaac Aaron wrote: > Does anybody know a shell command that allows me to run something in the > background immediately? > > I've looked in to the alternatives - > > at: Doesn't fit my need. I need to run it now. > batch: Batch run a process immed. only if the load average is lower than > 0.8. > cron: Same as at. > issuing the command with the & sign: This will run as a nested process. > When I'll close the terminal, the command will shut with it. Then just use 'screen', it is very suitable, because later you can reattach terminal, and you can also run progs that need terminal I/O -- Vadim Smelyansky (AKA Proglot) cellular:+972-54-876933 WideNet Ltd., Yokneam, 20692, Israel. ICQ: #38048982 = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Short question
On Mon, 9 Aug 1999, Yaron Zabary wrote: You can also use `screen'. --Ariel > On Mon, 9 Aug 1999, Isaac Aaron wrote: > > > Hi > > > > Does anybody know a shell command that allows me to run something in the > > background immediately? > > > > I've looked in to the alternatives - > > > > at: Doesn't fit my need. I need to run it now. > > You could > > at now + 0 minutes > > > > batch: Batch run a process immed. only if the load average is lower than > > 0.8. > > cron: Same as at. > > issuing the command with the & sign: This will run as a nested process. > > When I'll close the terminal, the command will shut with it. > > Or use nohup as described by another poster. > > > > > Anyone? > > > > > > = > > To unsubscribe, send mail to [EMAIL PROTECTED] with > > the word "unsubscribe" in the message body, e.g., run the command > > echo unsubscribe | mail [EMAIL PROTECTED] > > > > > > > -- Yaron. > > > = > To unsubscribe, send mail to [EMAIL PROTECTED] with > the word "unsubscribe" in the message body, e.g., run the command > echo unsubscribe | mail [EMAIL PROTECTED] > -- Ariel Biener e-mail: [EMAIL PROTECTED] Work phone: 03-640608 fingerprint = 07 D1 E5 3E EF 6D E5 82 0B E9 21 D4 3C 7D 8B BC = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Short question
For processes that need input, just redirect /dev/null ( < /dev/null). "Stanislav Malyshev a.k.a Frodo" wrote: > > IA>> issuing the command with the & sign: This will run as a nested process. > IA>> When I'll close the terminal, the command will shut with it. > > nohup is your friend. Also an interesting fact - if you _already_ run the > process via & and now want it to remain after shell exits, just kill -9 > the shell - the process should survive. Don't do it with processes that > need terminal, though - they'll be suspended. > -- > [EMAIL PROTECTED] \/ There shall be counsels taken > Stanislav Malyshev /\ Stronger than Morgul-spells > phone +972-3-9316425/\ JRRT LotR. > http://sharat.co.il/frodo/ whois:!SM8333 > > = > To unsubscribe, send mail to [EMAIL PROTECTED] with > the word "unsubscribe" in the message body, e.g., run the command > echo unsubscribe | mail [EMAIL PROTECTED] -- - | Omer Efraim| Earth First! | | [EMAIL PROTECTED] | We can Strip Mine the other planets later... | - = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Short question
use : YOUR_COMMAND & Mike Isaac Aaron wrote: > Hi > > Does anybody know a shell command that allows me to run something in the > background immediately? > > I've looked in to the alternatives - > > at: Doesn't fit my need. I need to run it now. > batch: Batch run a process immed. only if the load average is lower than > 0.8. > cron: Same as at. > issuing the command with the & sign: This will run as a nested process. > When I'll close the terminal, the command will shut with it. > > Anyone? > > = > To unsubscribe, send mail to [EMAIL PROTECTED] with > the word "unsubscribe" in the message body, e.g., run the command > echo unsubscribe | mail [EMAIL PROTECTED] = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Short question
On Mon, 9 Aug 1999, Isaac Aaron wrote: > Hi > > Does anybody know a shell command that allows me to run something in the > background immediately? > > I've looked in to the alternatives - > > at: Doesn't fit my need. I need to run it now. You could at now + 0 minutes > batch: Batch run a process immed. only if the load average is lower than > 0.8. > cron: Same as at. > issuing the command with the & sign: This will run as a nested process. > When I'll close the terminal, the command will shut with it. Or use nohup as described by another poster. > > Anyone? > > > = > To unsubscribe, send mail to [EMAIL PROTECTED] with > the word "unsubscribe" in the message body, e.g., run the command > echo unsubscribe | mail [EMAIL PROTECTED] > > -- Yaron. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Short question
IA>> issuing the command with the & sign: This will run as a nested process. IA>> When I'll close the terminal, the command will shut with it. nohup is your friend. Also an interesting fact - if you _already_ run the process via & and now want it to remain after shell exits, just kill -9 the shell - the process should survive. Don't do it with processes that need terminal, though - they'll be suspended. -- [EMAIL PROTECTED] \/ There shall be counsels taken Stanislav Malyshev /\ Stronger than Morgul-spells phone +972-3-9316425/\ JRRT LotR. http://sharat.co.il/frodo/ whois:!SM8333 = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
