Let's first look at what happens if a program is started from an interactive shell (connected to a terminal) without & (and without any redirection). So let's assume you've just typed foo:
The process running foo is created.
The process inherits stdin, stdout, and stderr from the shell. Therefore it is also connected to the same terminal.
If the shell ...
As Tim said, type fg to bring the last process back to foreground.
If you have more than one process running in the background, do this:
 Stopped vim
- Stopped bash
+ Stopped vim 23
fg %3 to bring the vim 23 process back to foreground.
To suspend the process running in the background, ...
I think you may be confused about the job control notation. Notably "Stopped" means that a job is still alive but that its ability to process anything has been held (it is not given any time on the CPU to process anything). This is effectively a "Pause" or "Suspended" state, although that is not the correct technical term.
CtrlC does not "stop" a job, it ...
This should be true of any shell with job control, which (for the most part) you can take for granted unless dealing with a truly ancient shell. It's in the POSIX standard, so even dash supports job control (when run interactively or with -m).
Ctrl+z will suspend the currently foregrounded program
bg will background the most recently suspended ...
My favorite solution is using tmux, you could detach the session, and re-attach it in another terminal.
When you detached from previous session, you can safely close the terminal; later use tmux attach to get back to the session, even if you logged out.
The output of programs is buffered, so if the connection is slow the program will be halted if the buffer fills up.
If you use screen, it has a buffer as well that it uses to try and display to a connected session. But a program connected in the screen session will not be stopped if screen cannot update the remote terminal fast enough. Just like when a ...
The term you are looking for is called "backgrounding" a job. When you run a command either in your shell or in a script you can add a flag at the end to send it to the background and continue running new commands or the rest of the script. In most shells including sh, this is the & character.
That way, the shell doesn'...
If you've already started something somewhere, backgrounded it, and now need to attach it to a new terminal, you can use reptyr to re-attach it. (The man page summarises the command as "Reparent a running program to a new terminal".)
The reason you can't see it in the "jobs" command or use "fg" to bring it to the foreground is because these commands are ...
From the 4BSD manual for csh:
A ^Z takes effect immediately and is like an interrupt in that pending output and unread input are discarded when it is typed. There is another special key ^Y which does not generate a STOP signal until a program attempts to read(2) it. This can usefully be typed ahead when you have prepared some commands for a job which ...
Your kill command is backwards.
Like many UNIX commands, options that start with a minus must come first, before other arguments.
If you write
kill -INT 0
it sees the -INT as an option, and sends SIGINT to 0 (0 is a special number meaning all processes in the current process group).
But if you write
kill 0 -INT
it sees the 0, decides there's no more ...
After a process is sent to the background with &, its PID can be retrieved from the variable $!. The job IDs can be displayed using the jobs command, the -l switch displays the PID as well.
$ sleep 42 &
$ echo $!
$ jobs -l
 - 5260 running sleep 42
Some kill implementations allow killing by job ID instead of PID. But a ...
When using wget with -b or --background it puts itself into the background by disassociating from the current shell (by forking off a child process and terminating the parent). Since it's not the shell that puts it in the background as an asynchronous job, it will not show up as a job when you use jobs.
To run wget as an asynchronous (background) job in ...
Hitting Enter the script ends the process remains in the background.
Almost! Actually, the script has already exited by the time you press Enter. However, that's how you can get your prompt back (because your shell prints its $PS1 all over again).
The reason why hitting Ctrl + C terminates both of them is because the two of them are linked. When you ...
They are to distinguish between current and previous job; the last job and the second last job for more than two jobs, with + for the last and - for the second last one.
From man bash:
The previous job may be referenced using %-. If there is only a
single job, %+ and %- can both be used to refer to that job. In
output pertaining to jobs (e.g., the ...
start a command
pause the execution by pressing Ctrl+Z
find the job number of the paused command (it's usually already printed to console when to console when to command is paused) by executing
let command1 continue in background
plan execution of command2 to await finish of command1
wait -n <command1 job number> ; command2
The command does not hang. You think that the command is hanging because you don't see the prompt. The prompt is there. You don't see the prompt because it was pushed up by the output of the background process. Pressing enter after the long output of a background process causes the shell to "execute" the empty line and print a new prompt.
Try the following ...
From man jobs(1P):
<current> The character '+' identifies the job that would be used as a default for the fg or bg utilities; this job can also be specified using the
job_id %+ or "%%". The character '−' identifies the job that would become the default if the current default job were to exit; this job
can also be ...
What does it mean? What is "Exit 2"?
It is exit status of ls. See man for ls:
0 if OK,
1 if minor problems (e.g., cannot access subdirectory),
2 if serious trouble (e.g., cannot access command-line argument).
I guess the reason is that you have lots of *conf files in /etc and no *conf files in /usr. In ...
Let's say you lack both GNU screen and tmux (and X11, and virtual consoles) but want to switch between a login shell and another interactive shell.
You would first login on the console, and then start a new shell, temporarily blocking the login shell. To get the login shell back to do some work there, you'd do suspend. Then you would fg to get the ...
You use bg normally to run programs in the background, which has no console interaction, like most program with a graphical user interface.
Example: You wanted to run xterm & but forgot the & to run the terminal emulator in the background. So you stop the (blocking) foreground xterm process with Ctrl-Z and continue it in the background with bg.
This usually happens if the process tries to read from its stdin stream. When the process is in the background, it receives a TTIN signal and is thus frozen (same behavior as a STOP signal). There is also the dual signal TTOU when a background process tries to write to its terminal.
Bringing it to the foreground resumes the process and allows it to read ...
The parent process id (ppid) of a process cannot be changed outside of the kernel; there is no setppid system call. The kernel will only change the ppid to (pid) 1 after the processes parent has terminated - if the process did not respond to a signal that the parent was terminated. For this to happen, the process needs to have ignored various signals (...
As with other bash built-ins, there is help for it:
$ help fg
fg: fg [job_spec]
Move job to the foreground.
Place the job identified by JOB_SPEC in the foreground, making it the
current job. If JOB_SPEC is not present, the shell's notion of the
current job is used.
Status of command placed in foreground, ...
Job control is a feature that was added to BSD systems in the early 80s. csh being the BSD shell, it comes as no surprise that the feature was introduced in that shell first. You had to wait several years before job control was added to non-BSD Unices and to other shells (starting with the Korn shell).
It should be noted that job control is not the ability ...
Adding a detail to Anthon's explanation:
It is not always the case that a writing background process is stopped. This depends on the terminal setting tostop.
can be used to toggle this setting. So if you want a background process to write to "another process's" terminal then you can keep it running but don't need tmux, screen or ...
Say there's a loop reading input and executing. It may be useful to let the task finish the current instruction it computes, without interrupting it before it gets back to the command line for a new one. So thus to end a cycle. This ends the loop gracefully and prevents it from running again if read is under a timeout restriction.
The fact that a process is "disowned" has only a meaning for the interactive shell that created this process. It means that the shell doesn't include (anymore) the process in its jobs table, and that SIGHUP will not be sent to this process when the shell exits. It is not really related with your questions.
About what happens to the outputs that are sent to ...
Your background job continues executing until someone tells it to stop by sending it a signal. There are several ways it might die:
When the terminal goes away for any reason, it sends a HUP signal (“hangup”, as in modem hangup) to the shell running inside it (more precisely, to the controlling process) and to the process in the foreground process group. A ...
Yes, all you need to know is the process id (PID) of the process. You can find this with the ps command, or the pidof command.
kill $(pidof ping)
Should work from any other shell. If it doesn't, you can use ps and grep for ping.