Tag Info

Hot answers tagged

83

Using & causes the program to run in the background, so you'll get a new shell prompt instead of blocking until the program ends. nohup and disown are largely unrelated; they suppress SIGHUP (hangup) signals so the program isn't automatically killed when the controlling terminal is closed. nohup does this when the job first begins. If you don't nohup a ...


35

Using GNU screen is your best bet. Start screen running when you first login - I run screen -D -R, run your command, and either disconnect or suspend it with CTRL-Z and then disconnect from screen by pressing CTRL-A then D. When you login to the machine again, reconnect by running screen -D -R. You will be in the same shell as before. You can run jobs to ...


22

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: $ jobs [1] Stopped vim [2]- Stopped bash [3]+ Stopped vim 23 fg %3 to send the vim 23 process back to foreground. To suspend the process running in the background, ...


20

A process is any running program with its own address space. A job is a concept used by the shell - any program you interactively start that doesn't detach (ie, not a daemon) is a job. If you're running an interactive program, you can press CtrlZ to suspend it. Then you can start it back in the foreground (using fg) or in the background (using bg). While ...


20

If some-boring-process is running in your current bash session: halt it with ctrl-z to give you the bash prompt put it in the background with bg note the job number, or use the jobs command detach the process from this bash session with disown -h %1 (substitute the actual job number there). That doesn't do anything to redirect the output -- you have to ...


18

UNIX has separate concepts "process", "process group", and "session". Each shell you get at login becomes the leader of its own new session and process group, and sets the controlling process group of the terminal to itself. The shell creates a process group within the current session for each "job" it launches, and places each process it starts into the ...


15

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


13

Shell jobs live in "process groups"; look at the PGRP column in extended ps output. These are used both for job control and to determine who "owns" a terminal (real or pty). POSIX (taken from System V) uses a negative process ID to indicate a process group, since the process group is identified by the first process in the group ("process group leader"). ...


13

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. #!/bin/sh gedit & rm ./*.temp That way, the shell ...


13

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


9

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


7

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


6

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


6

Too late. After a process is started, shell has no more control on process file descriptors so you can not silence it by a shell command. You can only try to kill a SIGHUP to the process. If your process handles it correctly, It should detach from controlling tty. Unluckily, many software do not handle it correctly and simply die.


5

screen, tmux, or dtach (possibly with dvtm) are all great for this, but if it's something where you didn't think to use one of those, you may be able to leverage nohup.


5

This is exactly what screen and tmux were created for. You run the shell inside the screen/tmux session, and you can disconnect/reconnect at will. You can also have multiple shell sessions running inside one gnome-terminal.


5

According to the Bash Reference Manual: Job Control: In output pertaining to jobs (e.g., the output of the jobs command), the current job is always flagged with a +', and the previous job with a-'.


5

That should work: are you sure your .bash_aliases is read? (It's not a standard file, but it might be sourced by your ~/.bashrc. If you're confused about .bashrc and .bash_profile, see Difference between .bashrc and .bash_profile.) There's a bug in your function: it should be editorz () { gedit "$@" & disown } Your version doesn't work on file ...


5

As long as the jobs were all started from your current shell: use 'jobs' to get a list of backgrounded jobs. Each will have a numeric identifier, starting from '1'. Then you can bring the job to the foreground with fg %1, send it to the background if it's paused with bg %1, or kill it with kill %1 (use the correct number for the job you're trying to kill, ...


4

The process that is run from a terminal has its stdin, stdout and stderr bound to the terminal and you cannot do anything about it without re-gaining control over that terminal... Normally. But there are some tricky tools that actually let you do it. Have a look at this example. And other programs like retty mentioned there.


4

Unfortunately, commands started in background are set by the shell to ignore SIGINT, and worse, they can't un-ignore it with trap. Otherwise, all you'd have to do is (trap - INT; exec process1) & (trap - INT; exec process2) & trap '' INT wait Because process1 and process2 would get the SIGINT when you press Ctrl-C since they're part of the same ...


4

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


4

What does it mean? What is "Exit 2"? It is exit status of ls. See man for ls: Exit status: 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 ...


4

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 & [1] 5260 $ echo $! 5260 $ jobs -l [1] - 5260 running sleep 42 Some kill implementations allow killing by job ID instead of PID. But a ...


3

To answer the most interesting part of your question: to change the output of a live running program, you have to edit its file descriptors. That is quite easy to do with gdb. It's a hack, but works. See: http://stackoverflow.com/questions/593724/redirect-stderr-stdout-of-a-process-after-its-been-started-using-command-line A helper script is available at ...


3

Suppose you've just started a program outside screen. Suddenly you realize you wanted to do something else in that terminal. Ctrl+Z. Screen and tmux introduce a layer of isolation between the application and the terminal. This isn't always a good thing. For example, I find their scrollback a lot less convenient than xterm's, so I rarely use screen unless I ...


3

Ease of use would be the primary reason. It's much more convenient to switch between screens using keyboard shortcuts than to use the job control features. Moreover, with Screen every window is connected to a separate virtual terminal, while with job control you either have to suspend the process, or allow it to run in the background cluttering the only ...


3

As for daemons doing it, that's because they want any output or error messages they might produce to be discarded no matter how you redirect a process's input and output streams, it will still be SIGHUP'd if it's attached to a session and that session is closed to leave processes running. To leave processes running, there are few approaches: detach them ...


3

You can remember the PID of each new child (check $! after starting it). Periodically check how many children still exist (e.g. by kill -0), if the number goes down, spawn a new one, etc. At the end, just wait. Here is a script I wrote for the same reason: #! /bin/bash ## Tries to run commands in parallel. Commands are read from STDIN one ## per line, or ...


3

If you've already started something somewhere, backgrounded it, and now need to attach it to a new terminal, you can use repytr to re-attach it. 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 actually built-in to the shell. They don't technically detach the processes from the ...



Only top voted, non community-wiki answers of a minimum length are eligible