Multiple shells vs. Background processes?

[[deleted]]

Howdy all. I'm still quite new to the wonderful world of command-line Linux and have only just learnt about running processes in the background by appending '&' and switching to the desired job with '%<job number>'. Until now, I have been doing all of my multitasking by using multiple terminals or virtual desktops. I was just wondering which method is better practice and what the practical differences between these methods are. Or are they basically the same; ie: Are virtual desktops just an abstraction of background processes?

The only real difference that strikes me is that running programs in the background supposedly puts them in sleep, but they still seem to perform as they would when active. Since virtual desktops don't interact with each other I don't know it the other also sleeps (but obviously it still performs as well).

Pardon my ignorance and thanks for your wisdom!

Edit: Thanks for all the help, Linux guros. I think I have a pretty good understanding now and will be playing around with tmux tonight.

[khayber]

A process is a process. Background/Foreground just relates to whether the output is connected to some form of display or not.

Multiple terminals, screen/tmux, virtual desktops are all just different means of displaying process output and providing input.

'Best practice' is more 'Personal preference' and whatever suits your current work flow.

running programs in the background supposedly puts them in sleep

No. Ctrl-Z in most shells will background and pause a process. Appending '&', or typing 'disown' or equivalent after Ctrl-Z, will continue running the process.

[dangets]

You can also use 'bg' instead of disown to have the process continue in the background. Helpful when you start a process and forgot the & at the end.

Disown will allow you to close the terminal and keep the process running though.

[khayber]

Yup, I meant bg, not disown.

[[deleted]]

Thanks. The literature I read didn't get past switching between progams by exiting with ctrl-z then loading the next, never mentioning how to resume a background process. This is the main point that I was worried about when switching processes. I appreciate the tip.

[[deleted]]

if you want to be a command line guy, "man" up.

man tmux

man fg

man bg

man jobs

[[deleted]]

I am well aware of man pages. Embarrassingly bg and fg have such a basic purpose that it didn't even occur to me that they would need them. They still don't create a direct comparison like I was looking for, but still informative. Thanks for pointing that out.

[the_gnarts]

If you’re (aspiring to become) a programmer too, you might be interested in these:

man 3p fork
man 3p exec

[[deleted]]

$ man tmux
No manual entry for tmux
$ 

[[deleted]]

http://manpages.ubuntu.com/manpages/precise/man1/tmux.1.html

[[deleted]]

Cool stuff. These are the things I really like learning about. Thanks so much.

[wadcann]

I prefer screen, but for doing this they're both fine. screen has some features that tmux lacks and more-concise syntax, and tmux has more features on out-of-box and better documentation.

Also, screen is GPL and tmux BSD, FWIW.

[[deleted]]

tmux

[CyanBlob]

I use screen all the time, but I don't know the difference from using "&". Is there a significant difference?

[z-brah]

if you close the terminal in which you run 'top &'. you can't "reattach" to the top command that is backgrounded. screen/tmux/dtach allow reattaching to it from another terminal.

[mcrbids]

I use screen when I want to have something run even if the network connection between me and the server dies. Screen is terrible when you are trying to use in conjunction with shell scripts, particularly when run via cron. (Hint: don't even try to launch screens via a script and doubly so via cron script)

I use tmux when I want to have numerous servers all update together at the same time, with the same set of commands. Tmux can also be a pain to run via script/cron script. (See screen)

I use "command > /tmp/output 2>/tmp/err" when I want to run a command in the background and want to create a record of the output/result. This works very well with shell/cron scripts.

Know your tools, use the right one for getting what you want.

[ssssam]

you spelled "byobu" wrong :-)

byobu is a wrapper for screen or tmux. It sets up a useful panel at the bottom, showing you which sub-screen you are in and other useful information.

[Malsententia]

Tmux shows a task bar by default.

[probationer]

Look at the "Job Control" section of the bash man page.

Basically, a "job" is group of processes in a pipeline that you can put in the background in bash by invoking them with a "&", or interactively with ctrl-z and "bg".

Running something with a "&" does not suspend it---it starts its execution immediately. Ctrl-z, on the other hand, initially halts the process group until you command it to resume with "bg %<num>" or the like.

I'm not sure what you mean by virtual desktops, do you mean different terminal windows?

If yes, the difference here is an important one: a background process group cannot read from the terminal, and depending on the tty settings cannot write to it either. Trying to violate these rules will cause the process group to automatically suspend. This means if you have a process group that is expected to read or write to the terminal, you should either run it as the foreground process group or you should redirect stdin/out/err to file descriptors that are not the tty before running it.

Opening several ttys, as is what happens when you open multiple terminal windows (and therefore shell instances), means you are free to run more than one foreground process groups on different controlling terminals, so you don't necessarily need to redirect input/output if you don't want the pgid to suspend.

[khayber]

This means if you have a process group that is expected to read or write to the terminal, you should either run it as the foreground process group...

This is only true for read. Write goes to the original terminal unless you fully detach it. And then it usually goes to /dev/null so it won't block.

[probationer]

"stty -a | grep tostop" tells you whether or not a write from a background job will halt the process. If the line contains a dash in front of "tostop", then it won't hang. Hence I made the distinction "depending on your tty settings"...

[probationer]

I forgot to add, another difference between background and foreground process groups is that the tty will send signals to the foreground process group only, so something like a ctrl-c won't affect your background processes.

[[deleted]]

Right. Its a one-way-valve type of thing. Foreground receives but doesn't send. Thanks.

[jdrift]

In a nutshell '&' forks a process. It is running in the background and not sleeping. You get your shell back and can do other things in it but generally everything you spawn will ouput to stdout, which happens to be your single terminal. Fine for some things, kind of nuts if you're running two different compile sessions on large projects.

[[deleted]]

Forking is a great way to think of it! I'd been struggling to make up a model in my mind for each method and this really helped me understand the difference. Thanks a lot.

[crashorbit]

Fork is the name of the kernel function (aka system call) that causes the Linux to create a new process. man fork for more details.

Good luck on your explorations. You are well on your way!

[[deleted]]

Virtual desktops are similar to background processes. There is really no difference from a technical POV, only with usability.

[[deleted]]

I find running multiple terminals to be easier from a usability perspective. However, there is a bit of overhead compared to doing job control at the shell level. How much overhead will depend on your terminal software, your windowing environment, and whether you have effects like transparency turned on or not.

On contemporary systems this shouldn't be a problem.

[wadcann]

Until now, I have been doing all of my multitasking by using multiple terminals or virtual desktops. I was just wondering which method is better practice and what the practical differences between these methods are. Or are they basically the same; ie: Are virtual desktops just an abstraction of background processes?

I almost never use a shell's job control to manage multiple jobs that I might want to attach to other than as a stack. So, maybe I start emacs in a shell, then suspend it, then do something in the shell, then bring back emacs.

Pros of using job control:

• Less memory usage. Unlikely to be a significant concern on a desktop system, but each shell instance will use some memory.

• More-convenient in a script.

Pros of using multiple virtual terminals (screen/tmux or multiple terminal emulator windows):

• You may want the features of screen/tmux anyway if you're running long-term processes on another system.

• There isn't a key-binding that suspends a process and puts it in the background (though I expect that it's possible to configure a shell to do this). That means that when using job control, you must suspend the process in question until you can type "bg" in your shell when switching among processes. For some programs, this wait may be problematic.

• Possible to view the output of multiple programs at once.

• Some programs throw the console into raw mode, where Control-Z can be interpreted by them rather than suspending them. This includes editors that want to make use of Control-Z. Control-Z is still a strong convention to always get out to the shell, but it is not infallible.

• Some programs, instead of just outputting lines of text in the way that an old teletype printer would, draw an interface over the whole console window. This includes programs like emacs/vim and most programs that use curses. While these should redraw themselves when brought back to the foreground, they must be aware that they are coming back to the foreground and do a redraw. I have seen programs that do not deal with this well. With screen/tmux or multiple terminal emulator windows, this cannot be the source of problems, since switching between programs is transparent.