我发觉管理Linux和Unix系统最有利的情况之一就是已经有如此得多工具都能够帮助你完成工作。几乎任何一个可以想像的问题，都有人花费时间制作出相应的处理工具。并且多数情况下，此类工具都足够灵活，能够根据你所遇到的问题被完全更改。对我来说，screen就是这样一个工具。
Screen给我留下如此深的印象，感动了我，或许是因为在我使用Unix系统工作的前10年中，从来没有听说过它的存在。我浪费了大量时间试图解决它已经解决的各类问题。或者，我也许很容易被感动。不过如果screen对你来说是一个新东西，或者你已经知道她，并想得到它的一些使用技巧，请接着读下去。
Screen工具是一个终端多路转接器，在本质上，这意味着你能够使用一个单一的终端窗口运行多终端的应用。你现在可能会想，“有什么了不起，我早就能够将工作放在shell的后台来执行了。”确实，你能够那样做，不过若是程序本身不能够放入后台怎么办??也就是说，一些用ncurses写的程序?或者，如果你需要获得终端的整个对话该怎么办?再有，根据程序的先决条件，可能同时运行的程序之间会有影响。
Screen将允许你做到所有的这些事情。你的程序将不会察觉到与在单独的终端下运行有何不同，这将使它们运行的很好。这种情况下也没有客户机或服务器等“远程”工具的概念，只要在系统中安装了screen工具，你就可以运行你想要的工具，并且能够用screen连接系统，也就是说，你拥有所有你需要的东西。Screen的另一个好处是它由GNU组织撰写和维护，因此，它能够在可以想像的到的几乎所有的Unix平台上使用。(对于那些管理多种不同类型系统的人来说，这非常关键，因为它意味着你能够在不同的平台上使用相同的工具。)
Screen工作的例子
在我家里，我运行了一个低功率的FM发射器以广播我的音乐收藏。(发射器相比无线连接并不贵，它能够让我在院子里使用随身听仍然听到我的频道。)我使用名片mp3blaster驱动发射器，这是一个非常好的基于控制台的MP3播放器，能够支持巨大的MP3收集。一旦它开始运行，mp3blaster的信息看起来就像下图一样:
迄今为止，它都是如此的优秀:我能够打开一个窗口，开始mp3balster，整天广播音乐。但是如果我坐在楼上我的笔记本面前，并且不详跑到楼下改变播放列表该怎么办?很简单，我只需要在一个screen对话下启动mp3blaster，然后能够从任何拥有shell的系统访问所调用的screen。
我能够使用如下的方法开始一个叫做“radiostation”的screen对话:
tmancill@ghostrider:~$ screen -S radiostation
(此时出现一个空白的screen)
tmancill@ghostrider:~$ mp3blaster
(载入我的播放列表，然后按下play开始发射)
(按下“CTRL-a”，然后按下“d”离开)
在这里，我能够退出我的shell，而mp3blaster则继续保持工作，使用现有的音轨信息和运行时间来更新终端窗口(现在此窗口并不存在)。让我们假设，我的妻子打电话给我说，“嘿!播放一些不同于你收藏的音乐的吧!”，然后，我用ssh登录ghostrider机器，并使用下面的命令恢复会话:
tmancill@ghostrider:~$ screen -r radiostation
如果我碰巧忘记了正在运行的screen会话的名字，我可以使用“-ls”开关来查看正在运行的会话:
tmancill@ghostrider:~$ screen ?ls
There are screens on:
10238.frm (Detached)
25400.radiostation (Attached)
2 Sockets in /var/run/screen/S-tmancill.
如果我离开办公室时没有注销“radiostation”screen，我能够恢复它，指示screen在恢复运行(-r)我所请求的对话之前跟任何正在运行的对话分离(-d)。在我办公室的窗口上，我将看到:
tmancill@ghostrider:~$ screen -r radiostation
[remote detached]
当然，你不可能运行这个广播站而耗尽所有的screen。在生产环境中，这非常有用，因为你不必区分你应该从哪个地点访问这个对话。在我的办公室中，我需要在GDB(GNU Project debugger，http://www.gnu.org/software/gdb/gdb.html)下运行一块自动售货机软件，以便在它们存在缺点(segfaulted)时，能够得到错误的回溯跟踪信息。当崩溃发生时，我的监控软件将向我们发出警告通知，我们二十四小时随叫随到的支持团队成员将访问这个会话，在我们单独的每个工作站上运行GDB shell来解决问题。这里有一个选择，就是可以从系统控制台直接运行软件，但这意味着待命的技术团队必须在现场，然后必须物理的进入数据中心执行后续的工作。因此，screen绝对是一个适合的解决方案。
有一件事需要谨慎行事:screen是一个对用户权限非常敏感的程序，也就是说它会根据执行操作的用户来进行不同的响应。在GDB的例子中，自动售货机软件运行于一个特殊的用户账户下，因此如果你使用“su”或“sudo”命令改变成另一个用户，你将遇到权限问题。出现这种问题的原因是screen必须能够打开你的tty(终端)。举一个例子，让我们假设我想在我系统中的screen下以用户“asterisk”运行一些程序，如果我以用户“tony”登录，然后改变为用户“asterisk”，我将用以下的命令来运行:
asterisk@bach:~$ screen -S pbx
Cannot open your terminal '/dev/pts/146' - please check.(不能打开你的终端“/dev/pts/146” - 请检查。)
asterisk@bach:~$ ls -al /dev/pts/146
crw------- 1 tony tty 136, 146 May 31 18:16 /dev/pts/146
就像你能够看到的一样，由于安全问题，我的tty(终端)由打开shell的用户所拥有，而不是我改变为asterisk后的有效用户ID。解决这个问题的一个方式是在调用screen之前，直接以用户asterisk登录，但这个问题同样会以另外的形式呈现，那就是，如果我以asterisk开始工作，然后在其它用户下请求联机，之后再切换回asterisk，“screen ?r”仍将不能打开终端。同样注意到，在我改变为用户asterisk之前，“screen ?ls”也不会向我显示出“pbx”会话，这是由于screen为每个screen用户创建了一个文件夹，它只能列出此用户的会话。
那么，该怎么做才能规避这些权限问题呢?如果用户账号有一个密码，你通常能够通过ssh以此用户直接进入系统(也可能是本地机)。或者，如果你总是很匆忙，并且有足够的自信，感觉并不会存在本地安全威胁，你则可以在tty(终端)修改权限。如果你这样做了，请确信在工作完后，你已经从你工作的终端上注销。实际上，你已经给予了每个本地系统用户通过shell访问的权限。另一个选择是改变成root用户再调用screen，然后在screen会话中改变为运行工作所需的系统账号。这样做能够正常的原因是超级用户能够打开任何用户的ty(终端)，而表面上，你的支持团队应该有改变为root用户的足够权限。
Screen能够帮助你使用那些不适合“无人看管”使用的大量终端软件，并且只需运行一个起始会话即可。相比之前你可能通过多个会话登录远程系统，它的部署是如此快速，易用性又是如此之好，或者说它在你的Linux控制台上添加和设置了附加的虚拟控制台。这就是screen，上面的文章将指导你更好的使用这个强大的工具，你可以在你需要的任何时候运行它。
