Preface: Ever since I replaced screen with tmux, thanks to a tip from @wblock@, I was anxious to share my experiences; an HOWTO was in order. However, my original article was too long, and although the people behind the forum were more than happy to help me out I just couldn't manage to work out the individual parts and merge them. SO I decided to split it up in two articles which are hopefully also useful by themselves.
1 - Introduction
When you log on to a computer running FreeBSD, either directly using a so called TTY or over a network (using ssh or PuTTY for example) you'll end up on a command line. If you logged directly on to your computer then you ended up on the console. However, if you logged on using the network we usually speak of a virtual console. But for clarity sake I'm simply calling this "console" or "CLI" (Command Line Interface).
So after you logged on you'll end up on a command line and in the environment of one of the many available interfaces, the so called shells. A shell is basically an environment which provides you with a massive collection of commands which you can use. Some of these commands are internally handled by your shell, whereas others are individual programs of their own (and as such not part of the shell).
If you use the command
1.1 - Jobs and multi tasking
FreeBSD is a multi-user and multi-tasking environment. Meaning so much that several people can use one computer at the same time, and obviously many different programs can be used simultaneously. But here's the fun part: you can even do that on the same console!
Take for example a program like /usr/bin/yes. If you start this program by simply using
But if you stop it (by pressing Control-C, or "^C") and then use
Don't panic!
To get out of this mess you need another command. Ignore the "y stream" and type carefully:
So what's happening here? By using the & character we actually told our shell to execute the yes program in the background. The shell started the program and transferred control right back to us.
The problem though is that yes sends out an endless stream of 'y' characters, so if you typed something it didn't stay on your screen for very long. By using the kill program we told our shell that it should stop the program %1. And that means so much as "the first program (or "job") which currently runs in the background".
You can even see as much in the code window above: the [1] section indicates that it's telling us something about the first job, in this case that it was terminated.
I hope you can see the usefulness here; even though you may have a single console there's nothing stopping you from using several commands at the same time. And if need be you can even make sure that you're not hindered by any unwanted output either, this output can be re-directed.
1.2 - Information streams
In general, Unix knowns 2 types of output on the console: stdout and stderr. These are so called standard streams, it's also where the name comes from. stdout means nothing more than Standard Output whereas stderr, you may guessed it by now, is the Standard Error. But it doesn't stop here, there is also something as a standard input stream: stdin.
These streams are very important on the console, and are constantly used. For example; if you use the previously mentioned
And here's the good part: most shells provide a way to redirect all of this, but the way to do this can differ per shell.
Let's go back to the previously mentioned yes program. It's pretty easy to start this without the nastiness of your screen getting flooded. Of course this makes the program pretty useless, but it serves as an excellent example:
First I started the program and used the > character to tell my shell that it should redirect any output coming from yes to /dev/null. /dev/null is the "great void" in Unix environments; everything which you sent to /dev/null is sent into this "great void". Or put differently: simply gone forever.
To be a little more specific: I told my shell that it should redirect stdout to /dev/null, and therefore no output is shown.
And finally I used the & sign to make sure that the command would run in the background. First we see a confirmation that the command is now the first job in my shell, and has been assigned with the Program Identifier ("PID") of 28407. If I press enter nothing happens, but when I use the
Just like before I killed it using %1, which indicates the first job, after which the shell will immediately inform me about this termination, even if you don't give it any commands (as you can see I only pressed enter).
Now, although this is a great way to use several commands or programs at the same time, it can also easily turn into a mess. Of course, you could use redirections to sent all output to a separate logfile, but that somewhat defeats the purpose of the shell a bit: being able to easily access your environment in a flexible way. Which is even ignoring all the trouble you may run into if you need to logout while the command you entered should keep going.
And that got people thinking, which initially led to the development of sysutils/screen which later inspired someone else to develop sysutils/tmux.
I'm not going to address the Ports collection here. So if you want to know how you can obtain and use either (or both?) of these two programs then please check out chapter 5.6 of the FreeBSD handbook: Using the Ports collection.
2 - Introducing Screen and TMux
Screen and Tmux ("terminal multiplexer") are programs which provide you with an almost infinite amount of virtual consoles, all from the very same console you logged onto in the first place. These virtual consoles are strictly separated from each other, so each virtual console basically behaves as if it was a fully regular console of its own. And that provides some very interesting options.
For example: let's say you're about to build a new tarball but haven't used tar long enough that you know the required parameters from mind. But obviously this always happens when you're almost at the end of the command:
So now what?
2.1 - Basic usage
If you're using screen or tmux you're never out of virtual consoles. Simply create a new virtual console, enter
How about a more advanced example: you're working with portmaster on the Ports collection and suddenly get an error that x11/xproto isn't installed while you're absolutely sure it is. In these cases portmaster will show you the error it encountered but also gives you the command which you can use to make it continue.
On a single user console you would now be faced with a dilemma. You could look into the status of x11/xproto but that could also eventually remove both the portmaster suggested commandline as well as any error messages which still exist in the backlog (pressing shift and page-up will display what's in the current backlog, this allows you to "scroll up" and view contents which didn't fit on your screen any longer).
Once again: if you have either screen or tmux installed this won't be a problem.
Either you create a new window to work in, or you could even consider to split your current screen into two panes (two 'windows') so that you can work on the problem in one section of your screen while the information you need to fix things (and to continue the build process) always remains visible in the other section.
Need more persuasion?
Say you're fixing a problem on a server in a datacentre. You're logged onto the main console and don't have something like a mouse available. You come across a weird error during this session and want to look into that error later on, but how do you secure it?
I suppose you could grab a pen and paper and write it all down, but that could become very tedious if we're talking about something like build errors. Another option is to start the process you were working on again and this time redirect the output, but how sure can you be that you'll once again get the exact same error message?
Once again; it's a non-issue when using screen or tmux. Simply open a new virtual console, start a program such as vi or maybe a mail program if you wish to sent the information somewhere, then simply copy and paste the information. Both screen and tmux provide a clipboard which you can use to copy text from one console and paste it into the other. That can be an invaluable feature at times, especially when you're in a fail safe session, for example while using single user mode.
And finally; these programs are also excellent to keep your programs running, even after you logged off from the server. I use this myself to keep irc/irssi running so that I remain logged onto my favourite IRC network (a semi-private network which some of my friends and me have set up and maintain, FreeBSD even excels with that!).
If you're a heavy console user you really should consider looking into these utilities if you haven't already.
Coming up next
In the next part I'll provide more information how you can move from screen to tmux. I'll go into detail as to why you might want to consider changing, the advantages and disadvantages you may encounter and the main differences between the two programs.
I'll also go into full detail how you can reconfigure tmux so that it behaves more like screen.
1 - Introduction
When you log on to a computer running FreeBSD, either directly using a so called TTY or over a network (using ssh or PuTTY for example) you'll end up on a command line. If you logged directly on to your computer then you ended up on the console. However, if you logged on using the network we usually speak of a virtual console. But for clarity sake I'm simply calling this "console" or "CLI" (Command Line Interface).
So after you logged on you'll end up on a command line and in the environment of one of the many available interfaces, the so called shells. A shell is basically an environment which provides you with a massive collection of commands which you can use. Some of these commands are internally handled by your shell, whereas others are individual programs of their own (and as such not part of the shell).
If you use the command
cd /usr/ports for example you're using an internal command, don't let the existence of /usr/bin/cd fool you: everything which happens here is fully handled by your shell itself. However, if you then use ls to list the contents of the current directory you are running an external command, in this case /usr/bin/ls.1.1 - Jobs and multi tasking
FreeBSD is a multi-user and multi-tasking environment. Meaning so much that several people can use one computer at the same time, and obviously many different programs can be used simultaneously. But here's the fun part: you can even do that on the same console!
Take for example a program like /usr/bin/yes. If you start this program by simply using
yes you'll notice a long stream of 'y' characters getting printed. If you then try to type something yourself you'll see that nothing really happens.But if you stop it (by pressing Control-C, or "^C") and then use
yes & it first seems as if nothing is different: once again an endless stream of 'y' characters. Yet if you try to use Control-c to stop the program this time you'll discover that nothing happens!Don't panic!
To get out of this mess you need another command. Ignore the "y stream" and type carefully:
kill %1 followed by enter. And presto; no more y's. But there's more, before doing anything else use the jobs command or simply press Enter, you'll see something like this:
Code:
y
y
y
smtp2:/home/peter $ jobs
jobs
[1] + Terminated yes
smtp2:/home/peter $The problem though is that yes sends out an endless stream of 'y' characters, so if you typed something it didn't stay on your screen for very long. By using the kill program we told our shell that it should stop the program %1. And that means so much as "the first program (or "job") which currently runs in the background".
You can even see as much in the code window above: the [1] section indicates that it's telling us something about the first job, in this case that it was terminated.
I hope you can see the usefulness here; even though you may have a single console there's nothing stopping you from using several commands at the same time. And if need be you can even make sure that you're not hindered by any unwanted output either, this output can be re-directed.
1.2 - Information streams
In general, Unix knowns 2 types of output on the console: stdout and stderr. These are so called standard streams, it's also where the name comes from. stdout means nothing more than Standard Output whereas stderr, you may guessed it by now, is the Standard Error. But it doesn't stop here, there is also something as a standard input stream: stdin.
These streams are very important on the console, and are constantly used. For example; if you use the previously mentioned
ls command to list the contents of a directory you're basically starting /usr/bin/ls. This is actually a small program which will check the contents of the current directory and then send this information to nothing other than the Standard Output, or stdout.And here's the good part: most shells provide a way to redirect all of this, but the way to do this can differ per shell.
Let's go back to the previously mentioned yes program. It's pretty easy to start this without the nastiness of your screen getting flooded. Of course this makes the program pretty useless, but it serves as an excellent example:
Code:
smtp2:/home/peter $ yes > /dev/null &
[1] 28407
smtp2:/home/peter $
smtp2:/home/peter $ jobs
[1] + Running yes > /dev/null
smtp2:/home/peter $ kill %1
smtp2:/home/peter $
[1] + Terminated yes > /dev/null
smtp2:/home/peter $ jobs
smtp2:/home/peter $To be a little more specific: I told my shell that it should redirect stdout to /dev/null, and therefore no output is shown.
And finally I used the & sign to make sure that the command would run in the background. First we see a confirmation that the command is now the first job in my shell, and has been assigned with the Program Identifier ("PID") of 28407. If I press enter nothing happens, but when I use the
jobs command you'll notice that it lists this first job, and also tells me that the job is currently running.Just like before I killed it using %1, which indicates the first job, after which the shell will immediately inform me about this termination, even if you don't give it any commands (as you can see I only pressed enter).
Now, although this is a great way to use several commands or programs at the same time, it can also easily turn into a mess. Of course, you could use redirections to sent all output to a separate logfile, but that somewhat defeats the purpose of the shell a bit: being able to easily access your environment in a flexible way. Which is even ignoring all the trouble you may run into if you need to logout while the command you entered should keep going.
And that got people thinking, which initially led to the development of sysutils/screen which later inspired someone else to develop sysutils/tmux.
I'm not going to address the Ports collection here. So if you want to know how you can obtain and use either (or both?) of these two programs then please check out chapter 5.6 of the FreeBSD handbook: Using the Ports collection.
2 - Introducing Screen and TMux
Screen and Tmux ("terminal multiplexer") are programs which provide you with an almost infinite amount of virtual consoles, all from the very same console you logged onto in the first place. These virtual consoles are strictly separated from each other, so each virtual console basically behaves as if it was a fully regular console of its own. And that provides some very interesting options.
For example: let's say you're about to build a new tarball but haven't used tar long enough that you know the required parameters from mind. But obviously this always happens when you're almost at the end of the command:
tar -c -v -z -f /home/peter/mytarball.tar.gz --exclude "???.So now what?
2.1 - Basic usage
If you're using screen or tmux you're never out of virtual consoles. Simply create a new virtual console, enter
man tar and check everything which eludes you, in my example that would be the --exclude option. The best part is that the console you were working on will remain exactly as you left it. So after you're done reading you simply switch back and continue typing, it's that simple.How about a more advanced example: you're working with portmaster on the Ports collection and suddenly get an error that x11/xproto isn't installed while you're absolutely sure it is. In these cases portmaster will show you the error it encountered but also gives you the command which you can use to make it continue.
On a single user console you would now be faced with a dilemma. You could look into the status of x11/xproto but that could also eventually remove both the portmaster suggested commandline as well as any error messages which still exist in the backlog (pressing shift and page-up will display what's in the current backlog, this allows you to "scroll up" and view contents which didn't fit on your screen any longer).
Once again: if you have either screen or tmux installed this won't be a problem.
Either you create a new window to work in, or you could even consider to split your current screen into two panes (two 'windows') so that you can work on the problem in one section of your screen while the information you need to fix things (and to continue the build process) always remains visible in the other section.
Need more persuasion?
Say you're fixing a problem on a server in a datacentre. You're logged onto the main console and don't have something like a mouse available. You come across a weird error during this session and want to look into that error later on, but how do you secure it?
I suppose you could grab a pen and paper and write it all down, but that could become very tedious if we're talking about something like build errors. Another option is to start the process you were working on again and this time redirect the output, but how sure can you be that you'll once again get the exact same error message?
Once again; it's a non-issue when using screen or tmux. Simply open a new virtual console, start a program such as vi or maybe a mail program if you wish to sent the information somewhere, then simply copy and paste the information. Both screen and tmux provide a clipboard which you can use to copy text from one console and paste it into the other. That can be an invaluable feature at times, especially when you're in a fail safe session, for example while using single user mode.
And finally; these programs are also excellent to keep your programs running, even after you logged off from the server. I use this myself to keep irc/irssi running so that I remain logged onto my favourite IRC network (a semi-private network which some of my friends and me have set up and maintain, FreeBSD even excels with that!).
If you're a heavy console user you really should consider looking into these utilities if you haven't already.
Coming up next
In the next part I'll provide more information how you can move from screen to tmux. I'll go into detail as to why you might want to consider changing, the advantages and disadvantages you may encounter and the main differences between the two programs.
I'll also go into full detail how you can reconfigure tmux so that it behaves more like screen.
Last edited by a moderator: