Imagine Desktop workstation terminals
that extend as far as the eye can see.

Click the "Audio discussion" link Now
  • Audio discussion 0.8 meg


  • Things_VT


    Well this page isn't quite as bad of a mess as it was when I first posted it. Read it, and see.  However section 5. isn't even started even though there's lots of links to click on, they just don't go anywhere.

    First a word about the CLI:

    You, assuming you came from a Windows, or Mac environment, may have the mistaken notion that the CLI,(Command Line Interface) is difficult to learn, or hard to use.  Nothing could be further from the truth.  Linux, if used properly is still primarily a command line driven system, but unlike the command line of old, where every single 'i' had to be dotted, and 't' crossed, the command line of a modern 2007 bash shell completes commands for you given a partially keyed in command by simply pressing the tab key, the system either looks for executable commands matching the syntax of the command you partially typed in and it completes the executable programs name, based on an evolving executable hash table the Executable PATH variable   $PATH   or a file used with it, in the PWD,(Present Working Directory)  or if you press <Alt-Tab> it will draw from command history for a match to the last partially entered command fragment you've keyed in on the command line.  If it can by inference divine the meaning you intended, you're done, if not it interacts with you to obtain enough information to infer what it is that you are attempting to do.  Faced with the lack of a unique solution, you press <ctrl-R> and this mechanism prompts you for some unique fragment it can use to search the previously entered command history to display previous complete commands.  Subsequent <ctrl-R> keys simply use the same command search fragment to walk further back in history, presumably you stop on the proper command when you see it, and if necessary make a minor modification here or there, to hone the old command to your present needs, and then press enter to execute the new command.  If it executes, or at least makes a solid attempt, this too becomes part of the history of command execution.

    The CLI in combination with GPM,(General Purpose Mouse) also does things to make entering things at the command line easier, MUCH Easier! Unlike the GUI,(Graphical User Interface) where you have to do 20 eye hand cordinated mouse clicks, just to pull up a document that you were editing yesterday, often four or five key taps is all that is needed.  So why do I bring up this example?  I say so why not? What if Micro$oft never existed.  Never invented Winders.  What if we had a GUI, that played second fiddle to a command line, and that command line was as good as Bash is today, back in 1988 or so.  It could have happened that way, it almost did.  I saw a curious attempt, marketed by Epson, that offered a command.com shell replacement that parsed your command line entry, and if that operation resulted in an error it drilled down into an Artificial Inteligence Data Base to give you some examples of how to use the program it thought you were trying to key in.  While not quite what the bash shell is today, but at least it was going the right direction.  Why do I say Right Direction?  Just about this same time period Micro$oft introduced Windows 1.0 which was a joke, if memory serves, it came on one or two 360K floppies, took ten minutes to load, and didn't have any application programs to speak of.  Nothing to recomend it, except it was Micro$oft's way of showing the public this is our view of the future.  In truth they visited PARC,(Palo Alto Research Community) took notes, and said yea, we can do that.  Next they advertised the hell out of it, and soon there was a version 2.0, then 3.0 and by 3.0 people were actually trying to use Windows.  What if Epson had put that kind of effort into their AI,(Artificial Intelligence) driven CLI? Well for one thing people would know what a program was, what a file is, what a subdirectory is.  Let's cut to the chase, what if by 1988 we had the bash shell, with the GPM mouse, and an SVGA-Lib to standardize graphics, or an X-server GUI, generally available to the public.  Folks would still script startup Icons, sure, you'd still click start your apps, as you do today in Windows, but the difference is, you would be the one to write the script to start them, because in doing so, you get to customize how the app starts up, which custom features it starts up with, and when Errors, and Warnings come up, they are printed out on the terminal that started them running.  When these things happen in Windows, the user never knows about them.  The Error/Warning messages are the application program crying out in pain "Ouch" to the user, they are saying "Don't do that, it hurts!"  If today you keep doing something that makes an application cry out Ouch you're hurting me, and you don't know why, or what to do about it, so you ignore it, when the program finally crashes, taking your precious data with it, at least you remember those crys of pain, and maybe a little about what it was trying to tell you. So that when you get with your buddies, and mention Memory-leak detected, they know right where to go, to begin skulling the problem out.  The problem with Windows is that the end user is so effectively abstracted from what is really going on, under the GUI Icon driven hood of this lean mean muscle car of an operating system, that by the time they realize that anything is amiss, there's a trail of broken rods, springs, a sporadic piston here or there, bolts, nuts, an occasional fan blade to two, lining the roadside for ten miles or more.  Knowing the needs of your apps gives an alert user the chance to at least backup your data before the crash, and a power user, can partially bring a crashed app back to life, often just long enough to save the file,(See Core Files).  Many people tout advantages of one operating system over another, and I am sure folks reading this preamble will detect a vauge bias in my writing, especially this part.  In the Browser-box provided below I present one view of the DMCA story, if you're already familiar with these industry excesses skip over the Browser-box, and go on, but it makes an interesting read so grab the Browser-box's left glider bar and give it a twirl, it's a hoot...  No Really, read it, you'll prabably like it.


    I don't want to dampen your enthusiasm for an alternative operating system, but I won't sugar coat it either.  First off, don't think you are going to make the switch from Windows to Linux overnight, large corporations do that, but they have an army of tech support operatives on the payroll just to deal with end user problems.  Your best bet is to keep using your Winbox, as you setup the Linbox, and learn the basics.  Get Linux networking up and running, set up Samba so that Linux and Windows can share each others files.  Next download, and install TerraTerm to the Winbox, get the Secure Shell plugin for it, so that the Winbox can login to the Linbox.  This will allow you to control your Linbox from a Windows desktop.  These things require someone who is knowledgeable in both Linux and Windows networking, hint having a geek for a friend is very useful in this getting started phase.  It will take about two years of serious effort, to learn not only how to run and maintain a new operating system, and all of the types of software you use, on a regular basis, how to migrate your old data, into the new, and how to do workarounds for differences therein, and to buy Linux compatible hardware, (Hint WinPrinters, and WinModems often won't work under Linux) but also to adjust to the, new for you, do it yourself paradigm.  You see Open Source, is in reality a far flung, closely knit community of users, that know how to get "some" things done, they know how to, and who to ask, to get the rest of it.  Needless to say I have quite a lot to say on this subject, nor is Linux your only choice, there's Hurd, FreeBSD, and soon Haiku OS will resurrect BeOS as Open Source, and Open Solaris, plus Linux itself comes in many flavors, RedHat, Debian, Gentoo, Mandrake, Ubunto, DSL, and Slackware, to name just a few of the more prominent distros and then there's Micro$oft's SuSE Linux under the auspices of Novell which many say is a violation of the GPL,(General Public License), then there's CodeWeavers, and Wine, which emulate Micro$oft Windows under Linux, allowing you to run Windows programs from the safety of a Linux/BSD/Hurd X-server, and trust me, I haven't even scratched the surface yet, for instance Apple MacOsX, is an overlay for BSD running under every MacOsX machine you see.  BSD is Open Source, MacOsX is Closed Source how's that for twisted.

    An expanse of terminals as far as the eye can see:


    And stacked as high as the sun!

    Like everything else in Linux, default terminal settings are more like minimal examples to whet your appetite, not anything you'd want to work with on a day to day basis.  None of any of these are really any fault of Linux, or its design, rather they are configuration choices, that were "made for your own good" by the distro house.  Many a Linux Distro fancy their self appointed mandate to uplift new users, or to ease the transition from Windows to Linux.  Sooner or later this manifests as policy, and tends to become inflexible as time marches on.  While there's nothing wrong with uplifting newbies, it should always be done in such a way that the end user has final, knowledgeable say in each and every configuration decision.  Not an easy assignment, especially since the end user often must use a configuration setup for a while, to gain experience with it, to determine whither they like a feature or not.  The trouble is, it is so easy to think that you, as the distro's creator know what's best for the end user.  I hope to avoid this trap by suggesting to end users new to Linux, several of the more flexible distros they can choose from, and then showing configuration changes I have found useful in a step by step manner, with full explaination of how they work.  Not all distros even lend themselves to being reconfigured in this manner, I will mention one in particular, Ubuntu, near the end of section 6.   Making more Virtual terminals but I would refrain from jumping to that section, this page presents you with an awfully lot of technical info, in order for you to understand it all.  For now here are some ludicrous examples of what I mean by failing to allow the end user to make such choices.

  • Who ever thought half a dozen Virtual-Terminals was enough?...
  • Yet nearly every distro on the planet defaults to the basic six, plus a GUI on seven.  There's a much better way to do it, 23 VTs plus the GUI on 24

  • The VT prompt should provide you with some useful status...
  • The one I show you how to build does, but to accomodate it, it requires a two line prompt.  This is one area that begs for user customization, yet I seldom see anyone doing any...

  • Virtual-Terminals are programmable it is easy to place them in Console-Coma...
  • You as an alert user need to know how to return sanity to any of the various Terminal-Bombs.  I discuss this in depth.

  • Any, or even many, Virtual-Terminals can offer themselves up to Screen...
  • any instance of the Screen program can offer you limitless VTs via the Screen programs Menu system for naming, and selecting a VT under Screen's control, I show only one, VT-1, but you can have as many VTs running Screen as you like.

  • Why do kernel errors clutter up your screen while you try to input commands?...
  • Many books claim you need to see them, yet X never bothers the end user with them, so who is right?  I say move those important, but annoying missives to a special terminal of their very own, and to let you know that message activity is occurring on VT23, we optionally sound the VT23 console bell, set to a unique pitch, and duration to avoid confusing it with the local console bell.

  • Who ever thought the X-server should run on power-up by default?...
  • Marketroids bent on making Linux look like Winders, that's who!  If a user wants to run the GUI, fine let them run startx.  The X window system is like any other highly complex application program, as such the X server isn't as carefully designed as the system itself.  Maybe a user might even want to run X all the time, but that should never be the default behavior of a distro, foisting defaults like X on boot-up on an unsuspecting public, is tantamount to taking from them any remnant of freedom to make, (or not make) such a choice.
  • Virtual-Terminals VTs...
  • can do so much.

  • Virtual-Terminals VTs...
  • can do so much.

  • Virtual-Terminals VTs...
  • can do so much.

    Who ever thought half a dozen Virtual-Terminals was enough?...  Get real, my keyboard has 12 function keys, so I always boost VTs to include responding to <Alt (F8 - F12)> evoking   /dev/tty8   through   /dev/tty12   usually through some getty program of some stripe or other, of course it doesn't end there, while a dozen VTs might be good enough for a server or a firewall that you rarely ever plug in a video display monitor, and a keyboard, the machine that you regard as your main workstation is a different matter.  A properly configured Linux box, running good stable hardware, overclockers need not apply, :-) with an Uninterruptible Power Supply, (UPS) seldom, if ever, goes down.  Starting jobs that are intended to get very long in the tooth is for the first time practical, with some common sense caveats, like knowing about the "Lazy Unmount" switch -l (Kernel 2.4.11 or later) see the   umount   manpage before you adopt this mode of system usage.

    Also the terminal restoration program   fixvt   as of late 2007 was available from...

    http://metalab.unc.edu/pub/Linux/utils/terminal/fixvt.sh

    it's 598 bytes long, and sports an md5sum of   47dce715cf89e701e9c3ff97b8ccba7b

    and it's been there since I first discovered it, last century, in exactly the same file, byte for byte, any program that lasts that long without any changes, in the computer world, evokes comparative mental imagery of the Sphinx, or the Pyrimids, another very important program for promoting good longterm VT health is   stty   especially in conjunction with the   Sane   switch, as in   stty sane    see the manpage here too, also know something about Flow Control, a scroll-locked terminal can appear indistinguishable from a dead machine, especially if you panic. It is from that machine, your main workstation, that you remote into machines all over your home, or your enterprise.  That machine usually isn't just one machine either, it's cabled with a KVM Switch (Keyboard Video, and Mouse switch box) that switches to physically different machines. Regardless of that consideration, machines that you regard as your main workstations, should all get loads of VTs, not just the twelve I mentioned earlier, but VTs that also respond to, assuming you have a good ole 101 key keyboard, the <right Alt (F1 - F12)> key combos, evoking   /dev/tty13   through   /dev/tty24   from all of those you can dedicate one or two of them to run the screen program. This allows you a limitless number of terminals through a menu selection process, that's always two combinatorial keystrokes away, plus the effort to select a terminal from the menu. We are literally talking hundreds of logins here.  Since screen is the easiest to learn, I feel we should do it first.

    Note: None of this exercise requires root access, but you should be at a Virtual Terminal, it will even run in an X Term but I imagine there are all sorts of problems with doing that.  X will close a window with little regard to the tens, or perhaps hundreds of logins under it, and probably Zombies those tasks.  X Terms come in all sorts of flavors, and with a host of special features, any of which can interact with unpredictable results.  If you intend to use screen under X my advice is take it easy at first, don't open too many terminals, or start very many applications, especially apps that write to files, until you see how it goes.

    OK This is a fun little exercise...

    The absolute easiest way to learn how to tame screen is to copy out the following   ~/.screenrc   even though it's probably wrong for your machine, and run screen.  Lines 5-7 give an example walk through.  To shut down all the terminals it opens up, simply keep typing   exit <Enter>   until you logout of all of them, simple as that.
    # A working example of   ~/.screenrc
    #
    # After placing this data in a file called $HOME/.screenrc run the screen
    # program from a virtual terminal and then to access an interactive list
    # of multiplexed terminals key in     <Ctrl \> "
    # to toggle last used screen key in   <Ctrl \> <Ctrl \> 
    # to get the help screen key in       <Ctrl \> ?
    #
    # """
    #
    # The wake up key sequence to access menu/controls defaults to  <ctrl a>
    # unfortunately  <ctrl a>  is used by many programs you are likely to
    # run.  Here are some of my experiments to replace  <ctrl \>  as the
    # wake up key
    #
    # These are like starting screen up as     ---> screen -e "\034\134"
    # Note this works                          ---> escape "\034\\"
    # and so does this                         ---> escape "^\\\"
    # This does not do what I expected at all  ---> defescape "\034\\"
    #
    # 
    
    escape "^\\\"
    
    vbell off
    
    term linux
    
    # The following pre-assigns several terminals
    
    screen
    title "Beatnik Aumix"
    
    screen telnet -l jk 10.0.0.132
    title "Vagabond X10"
    
    screen /home/jk/scripts/srg_mast_lst
    title "SargeMasterlist"
    
    # This...
    # screen cat /home/system/Sarge/master_list | less -i -M -p zvbi_0.2.15-1_i386
    # title "SargeMasterlist"
    # ...does not work!  I had to bundle the "cat /home/s..._i386" command into a
    # bash script, and launch that see above screen /home/jk/scripts/srg_mast_lst
    


    Machine   Vagabond   makes BSR X10 services available throughout my house, it is also my Print server, and a few other ancillary services, that you do not have a machine called   Vagabond   at that IP address, is almost a certainty, so with this   ~/.screenrc   on your machine, when the   screen   program wakes up, the   Vagabond   telnet login will fail.  As will the   jk   login following it, but the terminal and its title will still be there.  So this rc file is kind of like the proverbial Bicycle-in-a-box with a rubber stamp impression on the side that reads Some assembly required  This rc file is only a starting point for you to build on, and customize according to your needs.

    But the focus of this configuration section is on...

  • 1.   Am I someone you can trust?

  • Will my changes ruin your system?

  • 2.  Insuring that X won't autostart


  • 3.  /etc/issue making VTs self identifying


  • 4.   Keys for Navigating between 23 VTs

  • in and out of a GUI, and screen

  • 5.   Can X activate VTs 13-thru-23?

  • And should it be mapped to do so?

    From the default half dozen to eleven plus the graphical terminal.

  • 6.   Making more Virtual terminals

  • the simple case 11 with the GUI on VT7

  • 7.   Making lots more Virtual terminals

  • advanced case 23 with the GUI on VT24

  • 8.  Move GUI VT via /usr/bin/X11/startx


  • 9.  Changing GUI VT under GDM and similar kindred spirits.


  • 10.  Diverting system messages to VT23.


  • 11.  Adding a bell tied to VT23 activity.




  • 1.   Am I someone you can trust?
    Will my changes ruin your system?

    If I said yes, would you try any of them? What if I said, Hey life is full of risk, you can't even be certain that you will live out this day, let alone have an insanely complex system like the computer sitting in front of you continue to function normally after making major alterations in its most sacrosanct configuration files? If you bought Novell, or RedHat, and you think that the warranty, they provide you is something you can't live without then I submit you are not willing to take any risks at all.

    Back to my question,
    Am I someone you can trust?

    Will my changes ruin your system?

    I will say this, I've been running my main workstation configured this way for some time now, a Debian Sarge system, often with so many VTs in use that I spill over into atleast one instance of the screen program.  As far as I can tell, both Fedora Core 2, Red Hat Linux release 7.3 (Valhalla), work fine, as well as Debian Woody, and as I mentioned earlier, Debian Sarge is my main work station, gets lots of use at the terminal, and the at present, relatively new, Debian Etch, on a Toshiba laptop, that dual boots Ubuntu.

    However I will also say this, I present this material in a much different way than you have come to expect.  My approach is a series of very small, self contained, and independantly testable configuration changes, mostly in the   /etc   tree.  Each of these changes by itself constitute some small improvement over the way the operating system was shipped.  Thus I present this material in a way that is both a good tutorial, and something that you can back out of, if you don't like the way a change works.  In fact if you think for one Pico-second that you can get away with implementing my configurations, without making backups of the files as they originally existed before you touched them, you are seriously mistaken.  You NEED to be ABLE to UNDO these things.  To throw caution to the wind in such matters flies in the face of common sense, and good practice.  Before you start, as Superuser e.g. (root login) the very least you can do is the following shown below in White:
    mkdir -v /root/Prior_to_Zap-Tek
    pushd  /root/Prior_to_Zap-Tek
    tar cvzf OrigEtcTree.tgz /etc
    md5sum OrigEtcTree.tgz >> assurance.md5
    popd
    

    The easiest way to enter those commands is, assuming you have the GPM,(General Purpose Mouse) for console terminals installed, you simply scoop up the commands shown above, by holding down the left mouse button, while gliding the mouse cursor over the text, then, switching to the Superuser console single click the right button, to dump the mouse buffer, then press the enter key to execute the command.

    There are some subtle problems that will arise from adding terminals that are not included in distros following the prevailing wisdom, of you only need six plus a GUI. There once was this Free (as in beer) device given away by many merchants but far and away the widest dispersal vector was Radio Shack. I'm speaking of course of the CueCat, a bar code reader, that auto-detected many popular formats, and then imposed a very weak encryption of the output. The CueCat plugged into the keyboard jack of your motherboard, and near that plug, was a jack offered by the CueCat for you to plugin your keyboard.  Therefore technically, the CueCat was what we call a keyboard wedge.  Anyway they Dimentional the mother company is as far as I can tell nolonger in the CueCat business, and after giving away thousands of them, with free advertising software so that the CueCat would take you right to the Web Site selling something that you scanned.  The thing is you give that many of a cool gadget away, and some open source project will spring up to make it useful.   Actually several open source projects wrote a myriad of drivers, and programs for the CueCat.  One of them was simple perl script called cat.pl it was fifty three lines of perl code, 925 bytes long, and had an MD5SUM of 018b2ee7ab0e31c72e65f1350689d160  cat.pl and the first comment read "# This code is public domain code." as tiny as it was, it was probably the most useful.  The problem with the CueCat, is that as soon as it decoded a valid scan, the lead bytes it output, were the key sequence <Alt-F10> and an unmodified Linux workstation would simply ignore it, but if you set up Ten or more Virtual-Terminals as soon as it detected a valid bar code to scan, it issued the key sequence to take you directly to VT-10  What to do  What to do  Well you could modify my settings in  /etc/inittab  or you could simply resign yourself to use the CueCat only when you are on VT-10 so the CueCat's action of sending the key sequence <Alt-F10> is no longer a problem.  To date, this is the only issue of adequate significance to make me aware of any problem arising out of the use of this type of configuration, after two years of steady use, and yes, sadly, it's in the devices firmware.

    The source of much of what I am about to show you came to me as a mix of my own experimentation, some stuff I read in books, and on the net, E-mail answers to questions I've asked friends over the years, and the like. Linux is a vast moving target, things that worked once, often have to be tweaked to work today, and tomorrow who knows. One thing I can say with certainty, if you find a good nugget of information on the net, don't simply save the URL, the internet is far too fluid to rely on in that way, yes my site has been up since 1999, but many move, or change their addy within a couple of years, so my advice is save the page, or better yet, isolate the important stuff, charts, graphs, examples, how-to text, and the like, and include the URL it was sourced from, because if the site does stick around, they tend to make corrections from time to time. Because of this I rarely list a URL that carries information that is likely to change, here on my web site. Magazine articles are an obvious exception. Once written they don't, or at least shouldn't change much. So fixed is this form of media that The Linux Gazette has been included in the more recent Debian distros Sarge, and Woody at least anyway.

    ----------------------------------------------------------------------------

    2.   Insuring that X won't autostart

    At some point starting up the X-server became organized, a real "C" program was written,   xinit   to start the X-server up according to dictates of one large configuration file in   /etc/X11   along with several smaller ones in that general area.  Still, with lots of command line switches to choose from, environment variables, and the like, normal fare for anyone conversant in the language of the Command Line Interface,(CLI) was considered to be too much for someone used to the mouse driven GUI,(Graphical User Interface) to grapple with, so they wrote a rather temporary script called   startx   to make it trivial to get the X-server up and running.  How temporary was it?  This is an excerpt of the actual   /usr/X11R6/bin/startx   script shipped with Debian Etch (GNU/Linux 4.0), Ubuntu Gutsy Gibbon (7.10), both of which are relatively recent releases as of April 2008
    #!/bin/sh
    
    # $Xorg: startx.cpp,v 1.3 2000/08/17 19:54:29 cpqbld Exp $
    #
    # This is just a sample implementation of a slightly less primitive
    # interface than xinit. It looks for user .xinitrc and .xserverrc
    # files, then system xinitrc and xserverrc files, else lets xinit choose
    # its default. The system xinitrc should probably do things like check
    # for .Xresources files and merge them in, startup up a window manager,
    # and pop a clock and serveral xterms.
    #
    # Site administrators are STRONGLY urged to write nicer versions.
    #
    # $XFree86: xc/programs/xinit/startx.cpp,v 3.16tsi Exp $
    
    The Slackware version 7.1 excerpt of the same   /usr/X11R6/bin/startx   script bore a striking resemblance way back in December 1998, the names were changed as X was under the auspices of the XConsortium, and XFree86, way back then as differentiated from the modern form of X.org, so over the nine years of it's existence that I have demonstrated here, probably many more, as I have certainly had even older distros, that probably used this file, with the same boilerplate advisory.

    Then came   Xdm   which was an attempt to keep even the login in the GUI realm.  The acronym Xdm stood for X Display Manager, later Gdm short for Gnome Display Manager did the same job, with more emphasis on security a generally agreed upon weakness of the X-server by notable folks in the Cloak-n-Dagger industry.  I suspect that if users are proficient enough to understand the command line well enough to see programs such as Xdm, and Gdm, as more of a nuisance than an aid, and have some understanding of security issues, firewalls and the like, are probably better off without the imposition of these programs.  For one thing, this forces the system to run with the GUI up all of the time, wasting CPU and memory, and putting at risk any video driver bugs all of the time, as opposed to only when you actually need the GUI.

    So how do these programs startup, what is it in the initiating sequence that makes them go?  Xdm, and the more pedestrian work Gdm, have a startup script of their very own, in   /etc/init.d    Programs in this area can be run manually, by the superuser, but mostly they are called through a series of symbolic links in the runlevel directories.  Not all distros put them in the same place, sad but true.  Miquel van Smoorenburg's Runlevel system, is elegant simplicity, a form of algorithmic poetry, a half dozen predefined runlevels, are in effect recipes for booting Linux with a subset of components that will make it useful for six different walks of life.  The components that are selected to run, and the order they are loaded, are crucial, for that walk of life to properly perform its task.  Off the   /etc/   directory are, assuming a properly implemented Miquel van Smoorenburg's Runlevel system, several directories of the form   rcX.d   where the   X   is the numerical label of the runlevel.  They are filled with symbolic links, all pointing to script files in   /etc/init.d   another special directory that is also part of the runlevel system.  The naming convention, special letters, and numbers, in the names of the symbolic links themselves dictate the order or sequence of the startup, and shutdown, of services which allow this simple, easily maintained, system to effortlessly switch from one runlevel, to another, by simply calling a command line program to goto another runlevel.  The details of ordering which service starts, when, or which shuts down, and when, is all controlled by the symbolic links in those   "rcX.d"   directories.  It is this coded naming convention that makes it possible for a program,   telinit   to automate the whole thing, when you think about it, it's a thing of beauty.  Since the naming convention follows explicit rules, it is possible for third party programs to interactively, or autonomously change the runlevel order, and or contents.  Indeed many such programs have already been written, often as a GUI wrapper to assist the user in setting the runlevels.  The following is a README that is part of the built in documentation that goes into all Debian installs nowadays, I urge you to read it.
    As I mentioned earlier not all distros put the   "rcX.d"   runlevel symlink repositories in the designated prescribed System-V location.  System-V, pronounced "System five" was a code fork long ago established Unix tradition in two directions System-V, and BSD.  Today System-V is synonymous with a Runlevel based design, and in the Open Source GPL world that usually means Linux of some sort, and BSD conversely is synonymous with a hard coded script driven start up.  System-V was created under the auspices of none other than AT&T, AKA TPC, The Phone Company this has been given as the reason there are seven runlevels, because AT&T felt that was what they needed from an operating system that was to perform telephone related tasks.  I suspect you could add more runlevels, although scripting written for seven wouldn't deal with any you add, since the world has standardized on seven.  I also suspect for more or less the same reason, Miquel van Smoorenburg's implementation of the System V Runlevel system was largely an effort of adhering to a previously existing standard, rather than inventing anew.



    keeping with the need for compatibility with from long ago established Unix tradition, in keeping with the need for compatibility with Miquel van Smoorenburg's System V Runlevel system, the   "rcX.d"   directories have atleast some representation, even if only a symlink to the real thing, at   /etc/rc1.d -thru- /etc/rc6.d   a distro that places them in weird places should provide symlink directories /VT/README.runlevels.html Mostly for compatibility with Miquel van Smoorenburg Runlevel system, which defines the "rc" directories as follows the "rc" directories have atleast some representation, even if only a symlink to the real thing, at   /etc/rc1.d -thru- /etc/rc6.d   a distro that places them in weird places should provide symlink directories

    3.   /etc/issue making VTs self identifying

    Many Linux distros fail to recognize the value of having a blank login screen identify which Virtual Terminal is being presented to you. First of all I need to mention something covered exhaustively in the next section namely navigating VTs.  You can jump directly to a particular VT by using the key combo <left Alt Fn> where n is one of the Function keys at the top row of a 101 key keyboard.  This gets you to any of the first 12 VTs.  To jump to VTs 13 to 24 is a bit more involved, but the simple case is if you are not in the GUI, you use the key combo <right Alt Fn> where n is F1 for VT13, F2 for VT14, and so on up to F12 for VT24.  Basically as long as you're at the VT console these key mappings work properly.  In addition to that you can jump to the VT to the right, or to the left, of where you are now,  by using the left/right arrow keys in the arrow key cluster of a 101 key keyboard, by pressing <left Alt Left-arrow> or <left Alt Right-arrow> respectively.  Now this is where it's real important to have terminal ID reporting turned on.  That way, a blank login tells you which VT it is, no guesswork.

    CueCat's as I mentioned earlier, send an <left Alt F10>  at the beginning of every successful barcode read, so you need to select VT10 you use the CueCat.  And if you are using the  left/right  arrow method to get there, a handy way to do it, having blank logins identify themselves really makes a difference. To turn on this feature we use the  "\l"  switch inside the   /etc/issue   file. The format of the switches used in this file are covered in the Getty manpage.  Gettys come in many varients, getty, agetty, or, mingetty, to name a few, I list the switches you can place in that file, here to give you soe idea of the flexibility this mechanism offers.
    ISSUE ESCAPES
           mingetty recognizes the following escapes sequences  which
           might be embedded in the /etc/issue file:
    
           \d     insert current day (localtime),
    
           \l     insert line on which mingetty is running,
    
           \m     inserts machine architecture (uname -m),
    
           \n     inserts machine's network node hostname (uname -n),
    
           \o     inserts domain name,
    
           \r     inserts operating system release (uname -r),
    
           \t     insert current time (localtime),
    
           \s     inserts operating system name,
    
           \u     resp. \U the current number of users which are cur-
                  rently  logged  in.  \U inserts "n users", where as
                  \u only inserts "n".
    
           \v     inserts operating system version (uname -v).
    
    EXAMPLE
           "Linux eos i386 #1 Tue Mar 19 21:54:09 MET 1996" was  pro-
           duced by putting "\s \n \m \v" into /etc/issue.
    

    As I said many Linux distros fail to recognize the value of having a blank login screen, cheif among them is   RedHat   and spawn of   RedHat   Fedora Core n  seem rather inflexible in this area, to be fair they may view it as a security issue, although restricting local consoles seems a bit much. 

    Happily however it's trivial to remedy, you edit the   /etc/issue   file adding the   \l   switch  need I mention to edit anything in the   /etc   tree requires root access.


    Before

    /etc/issue unaltered
    Red Hat Linux release 7.3 (Valhalla)
    Kernel \r on an \m
    

    Blank login

    Red Hat Linux release 7.3 (Valhalla)
    Kernel 2.4.18-3 on an i686
    
    gypsy login:
    


    After

    /etc/issue with /l switch
    Red Hat Linux release 7.3 (Valhalla)
    Kernel \r on an \m at terminal \l
    

    Blank login/w term ID

    Red Hat Linux release 7.3 (Valhalla)
    Kernel 2.4.18-3 on an i686 at terminal tty3
    
    gypsy login:
    




    In this youthful varient of Linux the file /etc/rc.d/rc.S contains the following segment...
    # Setup the /etc/issue and /etc/motd to reflect the current kernel level:
    # THESE WIPE ANY CHANGES YOU MAKE TO /ETC/ISSUE AND /ETC/MOTD WITH EACH
    # BOOT. COMMENT THEM OUT IF YOU WANT TO MAKE CUSTOM VERSIONS.
    echo > /etc/issue
    echo Welcome to Linux `/bin/uname -a | /bin/cut -d\  -f3`. >> /etc/issue
    echo >> /etc/issue
    echo "`/bin/uname -a | /bin/cut -d\  -f1,3`." > /etc/motd
    

    ...so rather than change the   /etc/issue   file, as I instruct you to do in beginning of this treatise, I rewire the code that rewrites that file to begin with, see below...

    echo > /etc/issue
    echo -n Welcome to Linux `/bin/uname -a | /bin/cut -d\  -f3`. >> /etc/issue
    echo "   "\\l >> /etc/issue
    echo >> /etc/issue
    echo "`/bin/uname -a | /bin/cut -d\  -f1,3`." > /etc/motd
    

    ...that finishes the terminals so you can see which one they are, if no one is as yet logged in.




    4.   Keys for Navigating between 23 VTs,
    in and out of a GUI, and screen

    There are very few sources of info that even mention how to move the VT that activates the X-server GUI, http://www.linuxjournal.com/article/5303 mentions it, as well as a book here or there, on administering Linux, but when it comes to switching between VTs while out of the X-server, I have yet to see one that get's all of it right.

    o-   While in the X-server GUI, to escape to bare VTs 1 - 12 you press <Ctrl L-Alt F1 -through- F12>  -or-  <Ctrl R-Alt F1 -through- F12> will exit the GUI to the VT of your choice, Almost! The caviat is that there's no way to reach VTs 13 -through- 23, the GUI simply interprets both the Left and Right Alt key combos the same way, and places you at a VT corresponding to <Left Alt Fx> where x is 1-thru-12 Only!

    o-   Books, the dead tree kind, and many a HowTo on the net, tell you to use <Ctrl L-Alt F1 -through- F12> universally whither using it to exit the GUI to a VT, or hopping from one VT to another.  This info is DEAD WRONG!  That the VT keyboard handler either ignores the left control key in combintaion with Left Alt, or treats the combo the same as the Left Alt key alone, so it is in this mistaken view that it is alright to teach fledgling Linux users to use <Ctrl Left Alt Fx> whither you're in the GUI or not, saving them the effort of learning a special key combo for each environment, GUI, and VT.  The problem arises when you turn on VTs 13 -thru- 24, which use the Right Alt key, and while in the VT CLI, (Virtual Terminal Command Line Interfaced) environment no such substitution for <Ctrl Right Alt Fx> is wired to VTs 13 -thru- 24

    o-   The proper way to remember and use it is...
    When in GUI: <Ctrl Left Alt Fx> for x=1-12 only.
    When in CLI: <Left Alt Fx> for x=1-12  and <Right Alt Fx> for x=13-24
    MEMORIZE THIS, USE IT, MAKE IT SECOND NATURE.



    5.   Can X activate VTs 13-thru-23?
    And should it be mapped to do so?

    Warning This is Experimental!

    This whole thing of the X-server not fully supporting underlying functionality of the Virtual Terminals, seems to be a matter of one Opensource Group not being aware of what the other is doing. Can it be made right? I will answer that with a qualified yes. You see this goes right back to the question, can you trust me. The kind of tweaking I'd have to do to make the X-server work properly, gets into a series of changes that I would like to pose a question to the folks that are maintaining the X-server, before I recommend it to anyone, failing that, I'd like to run with it for a while to make sure it all works. But it seems it can be done. Here's an experiment that sort of proves it's possible, atleast under Debian Sarge. Note: This is experimental I will not be responsible for anything you do after reading my site, it goes without saying that you are REALLY ON YOUR OWN with an experimental setup! If you are curious enough to try this, please back everything up, or do your experimentation on a sacrificial machine, like that one you pulled out of the dumpster last weekend. It is assumed that you've installed a well rounded Linux distro on such a machine, gotten X working, and laied in my settings described in this section, to give you an unbroken string of 23 virtual terminals, with number 24 being the X window GUI. The following experimental setup is based on Debian Sarge, though others will probably work.

    First without X running, edit the file:   /etc/X11/xkb/compat/xfree86   Change the following item...
        interpret  XF86_Switch_VT_11 {
            action = SwitchScreen(Screen=11, !SameServer);
        };
    
    ...to read...
        interpret  XF86_Switch_VT_11 {
            action = SwitchScreen(Screen=23, !SameServer);
        };
    
    ...and then run startx. When it is fully operational, press <Ctrl Alt F7> and you should go to VT7  After you have observed that this is in fact working, press <Right Alt F12> now you should be back in the  X-server.  OK now press the key combination that activates our experimental VT23, that being <Ctrl Alt F11> and shazam, it works!  As you'd expect <Right Alt F12> gets you back in X.

    Working backward through the keycode logic, your next stop is probably the file:   /etc/X11/xkb/symbols/srvr_ctrl   Now go looking for a substring called:   XF86_Switch_VT_   and study the logic around them.  If you search from   /etc/X11/xkb   recursively as follows:

    grep -r -i "XF86_Switch_VT_" * | less
    


    there are many more places where this substring appears, and that means if I were to do it, I'd need ample time, motivation, and perhaps feedback from X.org as to what all else will be effected by this. If you think you would like to tackle getting X to recognize VTs addressable by both Left-ALT and Right-ALT this may be a starting place, under Debian Sarge, and Fedora C2 there are several a doc files, do ls -al /etc/X11/xkb/READM* to get the list. One in particular /etc/X11/xkb/README near the end, mentions the complete specification on http://www.x-docs.org/XKB/XKBproto.pdf


    6.   Making more Virtual terminals
    the simple case 11 with the GUI on VT7

    This one is so simple that if you don't atleast do this one, you'll wish you had.  No mucking about down in the innards of X, in fact we intentionally leave the X-server at VT7, for now, I save that sort of thing for the industrial strength, ultra heavy duty advanced user modifications that I show later.  No really, it is that simple, what you do is, as root, you edit the file   /etc/inittab   with what ever simple text editor you regard as your favorite.  You are looking for a series of automatically self re-spawning calls to the program responsible for the default VTs,(Virtual Terminals) your system has to begin with.  Usually VT1 -thru- VT6 and usually this hunk of script code is near the end of the inittab file.  That program, the VT maker, is some form of   getty   short for Get-TTY.  I can't tell you what exactly you're looking for, because there are several kinds of these programs, that all do pretty much the same thing, some do serial lines, others are integrated into another package, and the like.  One underlying common thread that I have observed seems to be that what ever its name, it has the term getty embedded in the name, some examples include mingetty, agetty, vgetty, mgetty, and fgetty. Here's a way to help you to spot which one your system is using...

    ps axw | grep -i getty
    


    ...execute the above command to reveal the true getty  I demonstrate by experiment what happens at every step of this unfolding configuration project.  I don't generally recommend that you repeat the experiment that shows what happens when you cause the X-server to use a VT that's already spoken for, but don't worry, I give you ample Kids...  Don't do this at home! type of warning.  It isn't reasonable for me to cover all distros, I have to leave some of you out, however many of them, with a little thought, and study of what's being done, may find the chore of modifying my instructions for one of the three that I do show, to fit your particular distro, both rewarding, and enjoyable.  Lets face it sooner or later you're going to have to learn how to skull this sort of thing out anyway, and short of offering a few very general guide lines here or there, I don't believe one can really teach the art of Skulling.  One thing I do hope to instill in you, is good practise when it comes to documenting what you do, and how you came to decisions along the way.

    Good Luck.

    Slackware-version 7.0.0

    Under Slackware-version 7.0.0 with Kernel 2.2.13 on a machine called Slacker This is an old enough distro that things go back to a simpler time when Linux was young. The runlevels are for instance Hard-Coded shell scripts, and as in modern Linux, these scripts are mostly coded by Miquel van Smoorenburg who later went on to write the Symbolic Linked RunLevel system most folks are familiar with today. I will revisit this when I show you a piece of code that needlessly rewrites the   /etc/issue   file, everytime you reboot. The file /etc/inittab like all the other distros is where all the VTs are spawned, but it's quite a bit different, and yet in some ways the same.

    (Late breaking item Ubuntu doesn't use /etc/inittab or the standard runlevel control system that Miquel van Smoorenburg wrote)

    The first six terminals VTs 1 - 6 are spawned as follows leaving VT 7 for the X-server GUI,(Graphical User Interface) shown in purple.
    # The getties in multi user mode on consoles an serial lines.
    #
    # NOTE NOTE NOTE adjust this to your getty or you will not be
    #                able to login !!
    #
    # Note: for 'agetty' you use linespeed, line.
    # for 'getty_ps' you use line, linespeed and also use 'gettydefs'
    # Run gettys from Virtual Terminals 1 - 6 activated by <Left Alt F1 - F6>
    c1:1235:respawn:/sbin/agetty 38400 tty1 linux
    c2:1235:respawn:/sbin/agetty 38400 tty2 linux
    c3:1235:respawn:/sbin/agetty 38400 tty3 linux
    c4:1235:respawn:/sbin/agetty 38400 tty4 linux
    c5:1235:respawn:/sbin/agetty 38400 tty5 linux
    c6:12345:respawn:/sbin/agetty 38400 tty6 linux
    
    Continuing in the Slackware example, to get the simple case 11 VTs with the GUI still on VT7 you would add the following...

    Don't forget to actually flesh out the sequence, that is don't merely parrot what I wrote in the example.

    # Run gettys from Virtual Terms 8 - 12 activated by <Left Alt F8 - F12>
    c8:1235:respawn:/sbin/agetty 38400 tty8 linux
    c9:1235:respawn:/sbin/agetty 38400 tty9 linux
        -    -    -  sequence is filled in as you'd expect  -    -    -
    c11:1235:respawn:/sbin/agetty 38400 tty11 linux
    c12:1235:respawn:/sbin/agetty 38400 tty12 linux
    


    Debian-version Sarge

    Under Debian-version Sarge (3.1) with Kernel 2.4.27-2-386 on a machine called Thinman.  This is a new enough distro that it uses a Symbolic Linked RunLevel system which was the brainchild of Miquel van Smoorenburg.  As I said earlier Debian loves to sprinkle in loads of comments in its configuration files, and this excerpt of the   /etc/inittab   emphasizes my point.

    # /sbin/getty invocations for the runlevels.
    #
    # The "id" field MUST be the same as the last
    # characters of the device (after "tty").
    #
    # Format:
    #  <id>:<runlevels>:<action>:<process>
    #
    # Note that on most Debian systems tty7 is used by the X Window System,
    # so if you want to add more getty's go ahead but skip tty7 if you run X.
    #
    # Run gettys from Virtual Terminals 1 - 6 activated
    by <right Alt F1 - F6>
    1:2345:respawn:/sbin/getty 38400 tty1
    2:23:respawn:/sbin/getty 38400 tty2
    3:23:respawn:/sbin/getty 38400 tty3
    4:23:respawn:/sbin/getty 38400 tty4
    5:23:respawn:/sbin/getty 38400 tty5
    6:23:respawn:/sbin/getty 38400 tty6
    
    Still in Debian Sarge:
    these are the VT getty allocations that you add in this simple version of making more VTs shown below in Yellow.
    # Run gettys from Virtual Terms 8 - 12 activated by <Left Alt F1 - F12>
    8:23:respawn:/sbin/getty 38400 tty8
    9:23:respawn:/sbin/getty 38400 tty9
    10:23:respawn:/sbin/getty 38400 tty10
    11:23:respawn:/sbin/getty 38400 tty11
    12:23:respawn:/sbin/getty 38400 tty12
    

    RedHat 7.3 (Valhalla)

    This is the default case for RedHat 7.3 (Valhalla) it provides the first six terminals activated by <Left Alt F1 - F7> shown below in Purple.
    
    # Run gettys in standard runlevels
    1:2345:respawn:/sbin/mingetty tty1
    2:2345:respawn:/sbin/mingetty tty2
    3:2345:respawn:/sbin/mingetty tty3
    4:2345:respawn:/sbin/mingetty tty4
    5:2345:respawn:/sbin/mingetty tty5
    6:2345:respawn:/sbin/mingetty tty6
    

    These are the VTs that you add in for RedHat 7.3 (Valhalla) it provides the next five terminals activated by <Left Alt F8 - F12> shown below in Yellow.
    8:2345:respawn:/sbin/mingetty tty8
    9:2345:respawn:/sbin/mingetty tty9
    10:2345:respawn:/sbin/mingetty tty10
    11:2345:respawn:/sbin/mingetty tty11
    12:2345:respawn:/sbin/mingetty tty12
    

    Ubuntu 7.10 (Gutsy Gibbon)

    Everything that all other distros I have seen so far, accomplished in the single file   /etc/inittab   is now performed under Ubuntu as a series of very short script files in a subdirectory Ubuntu calls   /etc/event.d   that attempts to accomplish the same functionality as the original Miquel van Smoorenburg's Runlevel system, but apparently without actually using any of his code.  All the System V compatible runlevel commands have been replaced with a Canonical Ltd Copyrighted version.  Even more interesting, Ubuntu a trademark of Canonical Ltd which claims to be Debian based, appears with regularity along side Miquel's name in the bug lists, and if you look in your man pages, of other Normal distros of Linux they haven't talked about bugs now for years, because there haven't been any.  Modern distros don't even bother with puting the BUGS: None phrasing in the manpage, that is until Canonical Ltd's Ubuntu, with its odd duck replacement for Miquel's time tested runlevel code.  Anytime you build any reverse engineered clone of an established piece of software, you run the risk of introducing new bugs.  This is especially true with cloning low level primitives that support mountains of other software written, and debugged hence the originals inception.  "So" the wisdom goes you'd better have an extremely good reason for tinkering with an established pillar before you begin, and as a matter of good practise you need to document what you've done thoroughly, for the benefit of future programmers, especially if what you've done, can fail on your platform, and yet work properly on other existing, widespread systems in use at the time.  I haven't found any such document, and I did a fairly careful search, though admittedly not an exhaustive one, I certainly haven't come across anything on a par with the man page for inittab(5) that comes with every Normal Linux distro out there.  Be that as it may, I will attempt to show what happened when, after a lot of experimentation, I managed to get extra VTs to come to life under Ubuntu a trademark of Canonical Ltd.  To begin with I think it would be instructive to show you the directory in question, the   ls   command is shown in White, and the listing results in Blue-Green.
    ls -al /etc/event.d
    

    drwxr-xr-x  2 root root 4096 2008-03-18 01:10 .
    drwxr-xr-x  3 root root 4096 2008-03-18 01:10 ..
    -rw-r--r--  1 root root  260 2008-03-18 01:10 control-alt-delete
    -rw-r--r--  1 root root  299 2008-03-18 01:10 logd
    -rw-r--r--  1 root root  552 2008-03-18 01:10 rc0
    -rw-r--r--  1 root root  342 2008-03-18 01:10 rc1
    -rw-r--r--  1 root root  403 2008-03-18 01:10 rc2
    -rw-r--r--  1 root root  403 2008-03-18 01:10 rc3
    -rw-r--r--  1 root root  403 2008-03-18 01:10 rc4
    -rw-r--r--  1 root root  403 2008-03-18 01:10 rc5
    -rw-r--r--  1 root root  422 2008-03-18 01:10 rc6
    -rw-r--r--  1 root root  485 2008-03-18 01:10 rc-default
    -rw-r--r--  1 root root  392 2008-03-18 01:10 rcS
    -rw-r--r--  1 root root  461 2008-03-18 01:10 rcS-sulogin
    -rw-r--r--  1 root root  558 2008-03-18 01:10 sulogin
    -rw-r--r--  1 root root  302 2008-03-18 01:10 tty1
    -rw-r--r--  1 root root  303 2008-03-18 01:10 tty13
    -rw-r--r--  1 root root  300 2008-03-18 01:10 tty2
    -rw-r--r--  1 root root  300 2008-03-18 01:10 tty3
    -rw-r--r--  1 root root  300 2008-03-18 01:10 tty4
    -rw-r--r--  1 root root  300 2008-03-18 01:10 tty5
    -rw-r--r--  1 root root  300 2008-03-18 01:10 tty6
    -rw-r--r--  1 root root  300 2008-03-18 01:10 tty9
    

    If you are by now familiar with   /etc/inittab   and some of what it does, this goes without saying that you're the studious type, you're the one to read several chapters ahead in the textbook, before getting seriously under the skin of the teacher, and in keeping with the Modus Operandi, you've already deduced, that if the above filenames are any indication of their function, that this directory is where that functionality is.  And you'd be right, remember in a normal distro's   /etc/inittab   there were sections where line after line went something like...
    6:23:respawn:/sbin/getty 38400 tty6
    

    ...to setup the VT / getty?  Well under Ubuntu the Smoorenburg Franken-clone equivelent uses a whole file to accomplish the same thing, here's Ubuntu's entry for tty6 shown here in Purple...
    # tty6 - getty
    #
    # This service maintains a getty on tty6 from the point the system is
    # started until it is shut down again.
    
    start on runlevel 2
    start on runlevel 3
    
    stop on runlevel 0
    stop on runlevel 1
    stop on runlevel 4
    stop on runlevel 5
    stop on runlevel 6
    
    respawn
    exec /sbin/getty 38400 tty6
    

    ...So I added two of my own, VT9, and VT13.  VT9 was chosen because VT1 - VT6 plus the GUI at VT7, plus an error window on VT8, hence VT9 was the next available.  As for the rational of VT13 for the next test, was that I wanted to know if the second rank of VTs worked under Ubuntu.  Shown below are my modifications.  First VT9 shown in Yellow.
    # tty9 - getty
    #
    # This service maintains a getty on tty9 from the point the system is
    # started until it is shut down again.
    
    start on runlevel 2
    start on runlevel 3
    
    stop on runlevel 0
    stop on runlevel 1
    stop on runlevel 4
    stop on runlevel 5
    stop on runlevel 6
    
    respawn
    exec /sbin/getty 38400 tty9
    

    Next VT13 shown in Yellow.
    # tty13 - getty
    #
    # This service maintains a getty on tty13 from the point the system is
    # started until it is shut down again.
    
    start on runlevel 2
    start on runlevel 3
    
    stop on runlevel 0
    stop on runlevel 1
    stop on runlevel 4
    stop on runlevel 5
    stop on runlevel 6
    
    respawn
    exec /sbin/getty 38400 tty13
    

    After I laid these changes in, and rebooted Ubuntu, both new terminals worked, VT9 worked perfectely, where as VT13 worked if you could get to it.  Pressing <right Alt (F1 - F12)> key combos, has the exact same effect as pressing <left Alt (F1 - F12)> key combos, completely locking out direct combinatorial key access to the second rank of VTs.  There are still a couple of ways to access VT13 one is, repeatedly press <left Alt (Left arrow or Right arrow)> key combos, until you get there.  The other is to from an active Login simply execute   chvt 13   for example to switch to VT13, so yes VTs 13 - 24 could in theory be made to work but I have to wonder how many more things they've screwed up, and how fixing those things will become vulnerabilities themselves.  In My skulling on the internet I noticed people asking for help fixing things that would have been dirt simple, if were not for Ubuntu's deliberate nonstandard needless quirkiness.  The answers they were getting were downright absurd, and clueless.  It is for these and other reasons I cannot recommend that anyone use Ubuntu, unless there is simply no other solution, I am quite certain that in the long term you will not be happy.



    7.   Making lots more Virtual terminals
    advanced case 23 with the GUI on VT24

    Continuing on with my configuration, I lay ther ground work for moving the GUI from VT7 to VT24, this will permit us to open up a uniform block of 23 contiguous VTs, but for now we leave VT7 unchanged, as it will allow me to show that step by experiment, and it will remain right up to the very end reversible.

    Slackware first:
    This excerpt of the   /etc/inittab   shows the default first six VTs being instantiated in purple.

    # The getties in multi user mode on consoles an serial lines.
    #
    # NOTE NOTE NOTE adjust this to your getty or you will not be
    #                able to login !!
    #
    # Note: for 'agetty' you use linespeed, line.
    # for 'getty_ps' you use line, linespeed and also use 'gettydefs'
    # Run gettys from Virtual Terminals 1 - 6 activated by <Left Alt F1 - F6>
    c1:1235:respawn:/sbin/agetty 38400 tty1 linux
    c2:1235:respawn:/sbin/agetty 38400 tty2 linux
    c3:1235:respawn:/sbin/agetty 38400 tty3 linux
    c4:1235:respawn:/sbin/agetty 38400 tty4 linux
    c5:1235:respawn:/sbin/agetty 38400 tty5 linux
    c6:12345:respawn:/sbin/agetty 38400 tty6 linux
    
    Still Slackware:
    Our previous experiment, this excerpt of the   /etc/inittab   shows the simple case of adding VT8 - VT12 being instantiated in Blue-Green.  leaving VT7 available to the GUI for testing.
    # Run gettys from Virtual Terms 8 - 12 activated by <Left Alt F8 - F12>
    c8:1235:respawn:/sbin/agetty 38400 tty8 linux
    c9:1235:respawn:/sbin/agetty 38400 tty9 linux
    c10:1235:respawn:/sbin/agetty 38400 tty10 linux
    c11:1235:respawn:/sbin/agetty 38400 tty11 linux
    c12:1235:respawn:/sbin/agetty 38400 tty12 linux
    
    Still Slackware:
    Brings us up to the present, in the experiment we are about to perform, this excerpt of the   /etc/inittab   shows the advanced case where we add VT13 - VT23 to be instantiated in Yellow.  leaving both VT7 and VT24 available to the GUI for experimental testing.
    # Run gettys from Virtual Terms 13 - 24 activated by <Right Alt F1 - F12>
    c13:1235:respawn:/sbin/agetty 38400 tty13 linux
    c14:1235:respawn:/sbin/agetty 38400 tty14 linux
    c15:1235:respawn:/sbin/agetty 38400 tty15 linux
    c16:1235:respawn:/sbin/agetty 38400 tty16 linux
    c17:1235:respawn:/sbin/agetty 38400 tty17 linux
    c18:1235:respawn:/sbin/agetty 38400 tty18 linux
    c19:1235:respawn:/sbin/agetty 38400 tty19 linux
    c20:1235:respawn:/sbin/agetty 38400 tty20 linux
    c21:1235:respawn:/sbin/agetty 38400 tty21 linux
    c22:1235:respawn:/sbin/agetty 38400 tty22 linux
    c23:1235:respawn:/sbin/agetty 38400 tty23 linux
    # note: vt 24 is left un-configured, as it belongs to X windows
    # c24:1235:respawn:/sbin/agetty 38400 tty24 linux
    

    Under Debian-version Sarge (3.1) with Kernel 2.4.27-2-386 on a machine called Thinman.  This is a new enough distro that it uses a Symbolic Linked RunLevel system which was the brainchild of Miquel van Smoorenburg.  As I said earlier Debian loves to sprinkle in loads of comments in its configuration files, and this excerpt of the   /etc/inittab   emphasizes my point, in the default VT getty allocations shown here in Purple.
    # /sbin/getty invocations for the runlevels.
    #
    # The "id" field MUST be the same as the last
    # characters of the device (after "tty").
    #
    # Format:
    #  <id>:<runlevels>:<action>:<process>
    #
    # Note that on most Debian systems tty7 is used by the X Window System,
    # so if you want to add more getty's go ahead but skip tty7 if you run X.
    #
    # Run gettys from Virtual Terminals 1 - 6 activated
    by <right Alt F1 - F6>
    1:2345:respawn:/sbin/getty 38400 tty1
    2:23:respawn:/sbin/getty 38400 tty2
    3:23:respawn:/sbin/getty 38400 tty3
    4:23:respawn:/sbin/getty 38400 tty4
    5:23:respawn:/sbin/getty 38400 tty5
    6:23:respawn:/sbin/getty 38400 tty6
    

    Still in Debian Sarge:
    In the previous exercise, these are the VT getty allocations that you added in the simple version of adding VTs shown below in Blue-Green.
    # Run gettys from Virtual Terms 8 - 12 activated by <Left Alt F1 - F12>
    8:23:respawn:/sbin/getty 38400 tty8
    9:23:respawn:/sbin/getty 38400 tty9
    10:23:respawn:/sbin/getty 38400 tty10
    11:23:respawn:/sbin/getty 38400 tty11
    12:23:respawn:/sbin/getty 38400 tty12
    

    Still in Debian Sarge:
    Now in this the advanced exercise, these are the VT getty allocations that you are about to add, my example configures gettys for VT13 - VT23 shown below in Yellow.
    # Run gettys from Virtual Terms 13 - 23 activated by <Right Alt F1 - F12>
    13:23:respawn:/sbin/getty 38400 tty13
    14:23:respawn:/sbin/getty 38400 tty14
    15:23:respawn:/sbin/getty 38400 tty15
    16:23:respawn:/sbin/getty 38400 tty16
    17:23:respawn:/sbin/getty 38400 tty17
    18:23:respawn:/sbin/getty 38400 tty18
    19:23:respawn:/sbin/getty 38400 tty19
    20:23:respawn:/sbin/getty 38400 tty20
    21:23:respawn:/sbin/getty 38400 tty21
    22:23:respawn:/sbin/getty 38400 tty22
    23:23:respawn:/sbin/getty 38400 tty23
    



    8.   Move GUI VT via /usr/bin/X11/startx

    Now the time has come to roll up our ethereal shirtsleeves, and begin to experiment with placing the X-server on different virtual terminals.  All of this is a moving target, the XFree86 organization ended its life when a well meaning someone made a miniscule change to the open source license to give credit to some under recognized people within the organization, making XFree86 no longer GPL compatible, as a direct result distro after distro refused to include the new version 4 in their software.  Others erected X.org and the race was on to catch X.org up to the high standard that XFree86 had attained, without using any of XFree86's code.  You need to experiment with this to find out what works, because frankly I can't begin to predict how these varaibles will be used until this settles out.

    The file   /usr/bin/X11/startx   they haven't yet fleshed out the variables, what was to become the file   /usr/X11R6/bin/startx   had a variable called   defaultserverargs=""   was handled with a little more care, so that my setting it to   defaultserverargs="vt24"   had several extra chances to overide the VT7 default, but in Slackware 7.0.0 the variable   serverargs=""   lacks this additional logic. However after studying the script, I timidly set   serverargs="vt24"   and it seemed to work.  As an additional test I temporarily left VT7 unassigned, (no getty instantiation of VT7) and ran   startx   it placed the GUI on VT24, then I ran it again shown here in White, as follows...
    startx -- vt7
    

    ...and sure enough, it placed the GUI on VT7.  I now have the X-server defaulting to starting up on VT24, and working properly on VT24, yet still responding to command line directives, so now we can dispense with having to reserve VT7 for the GUI X-server.

    Next I assigned a Getty to VT7:

    First Slackware:
    This excerpt of the   /etc/inittab   shows the assigning of VT7 to a   getty   for the advanced case configuring code highlighted in Yellow.  leaving only VT24 available to the X-server GUI
    # Run gettys from Virtual Terms 1 - 12 activated by <Left Alt F1 - F12>
    # Run gettys from Virtual Terms 13 - 23 activated by <Right Alt F1 - F12>
    
    c7:12345:respawn:/sbin/agetty 38400 tty7 linux
    
    # note: VT24 is left un-configured, as it belongs to X windows and if you're
    #       on a VT, you access the GUI by pressing <Right Alt F1 - F12>
    #       c24:1235:respawn:/sbin/agetty 38400 tty24 linux
    

    Next the Debian case:
    Once again an excerpt of   /etc/inittab   shows code to assign VT7 to a   getty   in yellow highlight.  leaving only VT24 available to the X-server GUI

    In keeping with Debian's verbose, and useful commenting of script files, I flank both sides with useful comments about occupying VT7, and setting VT24 as the default VT for the GUI X-server.  You should choose where best to place these comments.  Also note that assigning the VT7 getty late in the game, i.e. not in numerical order, will only affect the PID,(Process ID.) as far as I know nothing else is affected if you activate it out of order, to maintain the flow and readability of the   /etc/inittab   script.
    # Run gettys from Virtual Terms 1 - 12 activated by <Left Alt F1 - F12>
    # Run gettys from Virtual Terms 13 - 23 activated by <Right Alt F1 - F12>
    
    7:23:respawn:/sbin/getty 38400 tty7
    
    # Here I reserve tty24 for the X-server
    # 24:23:respawn:/sbin/getty 38400 tty24
    # Note a change in the file   /usr/X11R6/bin/startx   on line 24 the parameter
    # defaultserverargs=""
    #   ...was changed to...
    # defaultserverargs="vt24"
    #      to move the X-server from VT7 to VT24
    #      (many thanks to Evan A for skulling the following out for me)
    #      also if you do use GDM,(Gnome Display Manager)   /etc/X11/gdm/gdm.conf
    #      needs the parameter   FirstVT=7   fixed up appropriately too.
    

    Now that VT7 has a Getty:
    Re-boot to make it so...

    ...and again I ran   startx   Now the GUI was available via. <Right Alt F12> which is VT24.  Exactly what we set out to do.

    Now for some dangerous experimentation.

    Kids...  Don't do this at home!  You have been warned, I know many ways to deal with out of control consoles, I can if necessary sneak in through the LAN to fix a borked up console, without subjecting the system to a less than orderly shutdown.

    After shutting down the X-server, I then ran...
    startx -- vt7
    

    If you are alert, you will realize that this will attempt to start the X-server on a VT that is already occupied by the aforementioned getty that I just assigned to VT7...  You're probably thinking something's got to break.  And you'd be right, break it does...

    ...at this point I had a GUI, that had no keyboard, only the mouse. I tried all sorts of things on the keyboard, but it appeared utterly dead. I then used the mouse to shut down the X-server, which it did, and I was back at VT2 the same terminal that launched X under VT7. So being curious, I pressed <Left Alt F7> and there was a bare login screen, with a considerable number of nonsensical keystrokes typed in at the login prompt. Additional work at the keyboard revealed the keyboard was in the wrong mode, as X changes the mode of the keyboard.  There are elegant things one can do to restore the keyboard back to sanity, but running   ps axw   to get the   PID   of the Getty that was VT7, and then kill it, since it is a self re-spawning program, it re-spawned in the right mode, and that was that.  I'd read some where that is a really bad thing to do, to run X in a VT that is already occupied by a Getty and now I know what they mean.  First thing that goes wrong is that the keyboard focus remains on the Getty Terminal, and as the X-server starts up it switches the keyboard mode, so things are now so totally borked that this instantiation of X-server is doomed to a short life of failure.

    There is yet one final detail to complete the scene. The file   /etc/securetty   begins as follows...
    # This file defines which devices root can log in on.
    # These are the ttys on the physical console:
    console
    tty1
    tty2
    

    ...it needs fleshing out, add specifiers for all the new ttys you've just added to the system, probably tty8 - tty24  You'll find that Debian is very generous with these default terminal settings, probably no changes are necessary.



    9.   Changing GUI VT under GDM and
    similar kindred spirits.

    Warning This is Experimental!

    About a quarter into the file   /etc/X11/gdm/gdm.conf   you will see the following directives...
    # Automatic VT allocation.  Right now only works on Linux.  This way
    # we force X to use specific vts.  turn VTAllocation to false if this
    # is causing problems.
    FirstVT=7
    VTAllocation=true
    
    ...changing   FirstVT=7   to something else seems to work on the next startup/restart of   GDM   but other than really checking to see if it works I've gone no further, much more testing is needed, an auto restarting X is problematic even in the best of circumstances anyway, and X itself tends to pick up cruft, processes that fail to terminate properly, memory leaks, temp files that aren't disposed of, are all hallmarks of GUI technology, I've shown you what can happen if you hand off X to an already active terminal and if anything goes wrong in the hand off, that is exactly what's likely to happen.  Now we consider GDM set to a different terminal, if there's another directive somewhere, that GDM chooses to override our FirstVT directive, say on a restart, you could loose control of your workstation.  The CLI is clean, unambiguous, an intelligent agent, YOU, are in control of everything, by contrast a GUI does so much stuff behind the scenes that when something anomalous happens, something that an alert human would say "hey wait a minute, what just happened there," the GUI never questions it, so the error never gets fixed, and eventually quite often produces a cascade of errors that bring the whole GUI down.  Note: it doesn't very often bring down the system as a whole, just the GUI, so you can often restart X to go on, but then the file cruft never gets fixed.  If on the other hand, X is issued a command to do an organized shutdown, it has mechanisms to resolve at least some of those errors, but only if X is still alive, once it dies, the memories of the locus of cumulative errors is gone forever, as well as information on how to resolve them.  GDM tends to never give X a proper rest. 

    CLI inside the GUI as a safety net.
    * Best Practices

    I rarely run X anywhere but my workstation, and I tend to launch application programs from the command line, in an Xterm often followed by an   &   symbol which backgrounds the application to free the terminal for other work.  This has several advantages, for one thing, you get to see error messages in real time, as they happen, also most applications like to be told what to do, and how to act, thus instead of clicking on the   xine   icon and then diving into a dozen menus, clicking like mad to restart some cute car crash clip somebody put up on the internet, if you'd used the CLI to begin with, you merely pull it from history, a few key strokes like this...
    xine /home/jk/Vid/ShortClips/Humor/CarCrash.avi"#compression:9000;volume:40" &
    
    ...incidentally the above starts the   Xine   video player, with the sound fed through a sox filter that is effectively an autolevel circuit with a built in look ahead buffer so that the sound is acted on before it arrives.  No more straining to hear faint sounds, and then getting jarred out of your seat on the loud ones, waking up everyone in the house that are trying to sleep.  Just try doing that with your mouse in the GUI.



    10.   Diverting system messages to VT23.

    I would like to say don't do this one, because it doesn't even work, unfortunately it does work, and everytime I boot up the machine that has this gimmick, it reminds me that it does work, by beeping every little bit, and I have to go in as root to turn off the stupid bell.  OK First of all it's experimental, but not in the sense that it will cause problems, if anything it solves problems.  The trouble is I was never able to get it to solve the one problem I invented it for to begin with, so I classify it as a failure, even though it clearly is not. Also because I think of it as a failure, I never bothered to show how to implement it on machines other than Debian Sarge, so if you have some other machine, you'll have to skull out some of the missing details. OK so are you OK with that?  Good!  Well here we go.  This one rates a Ten on the scripting complexity scale, compared to the ease with which you've had these things go together up to now.

    When you get this thing completed,   Syslog   configuration will be slightly modified to stop sending Emergency messages to the VT Console and instead to send all messages, or part of them, or just Emergency messages, take your pick, to a special VT Console tty23, and optionally ring a unique sounding bell anytime a message comes in on tty23.

    Why is this so important?  OK let's say you're in an editor, banging out something while someone else, lacking the latest advances, down the hall, needed to load some programs from the latest DvD of Linux, and asked you to mount up the DvD, so they could pull some files over an NFS connection.  That was yesterday, and you've forgotten all about it.  But they haven't, they've been busy getting configurations ready, and now you're editing something, and the little red LED of the DvD drive, is furiously blinking because a jelly donut deposit smeared on the disc is making it unreadable, and your editing screen suddenly fills up with read error reports from   /dev/hdc   pushing all your work off the available screen space. Sound familiar?  That was the scenario this modification was suppose to fix, and it did'nt, apparently those errors come from somewhere that Syslog wasn't looking for :-(  Oh well.

    However the scheme does work for the types of errors it does trap, and maybe one fine day, I'll figure out where those errors are comming from and trap them too. 

    Until then here's how to implement this mechanism:

    OVERVIEW   VT23 error diverter.


    There are several pieces of this mechanism.

  • 1.     Two minor variants of   syslog.conf   I call them   /etc/syslog_do-beep.conf   and   /etc/syslog_no-beep.conf



  • 2.     A pseudo device file, a pipe, in the   /dev   tree masquerading as a device.



  • 3.     A Perl daemon   /etc/init.d/beepmrgd   to ring the bell once per line.



  • 4.     BASH startup script   /etc/init.d/vt23beep



  • 5.     BASH startup script   /etc/init.d/post_boot.sh



  • 6.     These six



  • 7.     Just to seven



  • 8.     Again if eight








  • MINUTIA   Obtaining the two syslog variants.


    To describe to you precisely how to edit a copy of the   syslog.conf   file might work, maybe even most of the time you'll get through it error free, assuming I didn't make any mistakes in the description of doing such a mundane operation.  But there is a better way.  Actually if you think about it, this kind of thing is required the world over, many times, each and every day by programmers.  Or if you prefer the term coders.  Most of what a programmer does, is not write whole programs, no most of their time is spent debugging, that is rewriting a very small, relatively speaking, portion of another existing program. A pair of tools called   diff   and a companion   patch.   Let's say I find a better way to locate colors that human beings have trouble seeing, and lets suppose I modify about 50 bytes scattered throughout a subroutine, and it's supporting code.  I suppose I could E-mail my altered version of the color handler source code, and have others on my team recompile the whole handler, but there's a much more efficient way to deal with this.  First I run   diff   against the original version, and my edited version, of the subroutine, and it's  supporting code.  This operation can, with the proper switches, build a   patch   file of approximately 50 bytes, actually there is some header, and tailer info, plus some syntactic sugar to show what lines are stricken, added, and those to be left alone, in the resulting file being built.  If I E-mail this short little   patch   file to my other team members with instructions to run the   patch   program on my   patchfile   once everyone gets used to the idea, the world is a much better place.  For one thing you can read a   patchfile   before you apply it to the code to be patched.  As hard as that is to believe, the format of a   patchfile   is comprehensible by us human beings.

    I felt it would be instructive to include my CLI commands I issued to build the two   patchfiles   that you will use to make the variant syslog configuration files, and due to the cleverness of 50 million :-) opensource programmers all getting a crack at   diff   and the   patch   programs we all use, these tools are so refined that they can often patch files from the future, that were written yesterday!  Just think what that means, I can patch a program today, it can often be revised tomorrow, and my patch will still work just fine.  Such is the case for the Do_beep and No_beep varients of the   syslog   configuration, written for Debian Sarge, yet can patch the radically different   rsyslog   configuration files  For Debian Lenny as long as you drop the   "r"   when you copy it to the work directory.
    /hemi/usr/home/jim/syslog_crosspatch/extract/hist
    CurDir = <  /usr/home/jim/syslog_crosspatch/extract  >
    [jim@hemi]$ # ------------------------------------------------
    CurDir = <  /usr/home/jim/syslog_crosspatch/extract  >
    [jim@hemi]$ cp -iv /etc/syslog.conf ../.
    
    `/etc/syslog.conf' -> `.././syslog.conf'
    
    CurDir = <  /usr/home/jim/syslog_crosspatch/extract  >
    [jim@hemi]$ cp -iv /etc/syslog_do-beep.conf ../.
    
    `/etc/syslog_do-beep.conf' -> `.././syslog_do-beep.conf'
    
    CurDir = <  /usr/home/jim/syslog_crosspatch/extract  >
    [jim@hemi]$ cp -iv /etc/syslog_no-beep.conf ../.
    
    `/etc/syslog_no-beep.conf' -> `.././syslog_no-beep.conf'
    
    CurDir = <  /usr/home/jim/syslog_crosspatch/extract  >
    [jim@hemi]$ ls -ao ..
    
    total 32
    drwxr-xr-x   5 jim 4096 2010-01-10 12:56 .
    drwxr-xr-x  35 jim 4096 2010-01-10 00:45 ..
    drwxr-xr-x   2 jim 4096 2010-01-10 12:53 extract
    drwxr-xr-x   2 jim 4096 2010-01-10 01:22 Lenny
    drwxr-xr-x   2 jim 4096 2010-01-10 02:23 re-assemble
    -rw-r--r--   1 jim 1957 2010-01-10 12:55 syslog.conf
    -rw-r--r--   1 jim 2034 2010-01-10 12:56 syslog_do-beep.conf
    -rw-r--r--   1 jim 2034 2010-01-10 12:56 syslog_no-beep.conf
    
    CurDir = <  /usr/home/jim/syslog_crosspatch/extract  >
    [jim@hemi]$ # ------------------------------------------------
    CurDir = <  /usr/home/jim/syslog_crosspatch/extract  >
    [jim@hemi]$ cp -iv ../* .
    
    `/etc/syslog_no-beep.conf' -> `.././syslog_no-beep.conf'
    cp: omitting directory `../extract'
    cp: omitting directory `../Lenny'
    cp: omitting directory `../re-assemble'
    `../syslog.conf' -> `./syslog.conf'
    `../syslog_do-beep.conf' -> `./syslog_do-beep.conf'
    `../syslog_no-beep.conf' -> `./syslog_no-beep.conf'
    
    CurDir = <  /usr/home/jim/syslog_crosspatch/extract  >
    [jim@hemi]$ diff -pruN syslog.conf syslog_do-beep.conf > syslog_do-beep.conf.patch
    CurDir = <  /usr/home/jim/syslog_crosspatch/extract  >
    [jim@hemi]$ diff -pruN syslog.conf syslog_no-beep.conf > syslog_no-beep.conf.patch
    CurDir = <  /usr/home/jim/syslog_crosspatch/extract  >
    [jim@hemi]$
    


    The first resulting patchfile   syslog_do-beep.conf.patch

    --- syslog.conf	2010-01-10 15:39:00.000000000 -0700
    +++ syslog_do-beep.conf	2010-01-10 15:45:20.000000000 -0700
    @@ -45,7 +45,11 @@ news.notice			-/var/log/news/news.notice
     #
     # Emergencies are sent to everybody logged in.
     #
    -*.emerg				*
    +
    +# This is for the   beepmrgd   alternate system error message facility  J.K.P.
    +# *.*                           /dev/tty23
    +*.*                             |/dev/bell23
    +
     
     #
     # I like to have messages displayed on the console, but only on a virtual
    


    The second resulting patchfile   syslog_do-beep.conf.patch

    --- syslog.conf	2010-01-10 15:39:00.000000000 -0700
    +++ syslog_no-beep.conf	2010-01-10 15:46:08.000000000 -0700
    @@ -45,7 +45,11 @@ news.notice			-/var/log/news/news.notice
     #
     # Emergencies are sent to everybody logged in.
     #
    -*.emerg				*
    +
    +# This is for the   beepmrgd   alternate system error message facility  J.K.P.
    +*.*                             /dev/tty23
    +# *.*                           |/dev/bell23
    +
     
     #
     # I like to have messages displayed on the console, but only on a virtual
    



    shown in Purple.
    Hello world
    

    shown in Blue-Green.
    Hello world
    

    shown in Yellow.
    Hello world
    



    CurDir = < /usr/home/jim/syslog_crosspatch/reextract > [jim@hemi]$ rm -i syslog.conf ; cp -iv ../Lenny/rsyslog.conf syslog.conf rm: remove regular file `syslog.conf'? y `../Lenny/rsyslog.conf' -> `syslog.conf' CurDir = < /usr/home/jim/syslog_crosspatch/reextract > [jim@hemi]$ patch -p0

    First you'll need pseudo device file, a named pipe really, something that you can feed data to, and have the outcome do something much like a device file would do but, in this case, it not only diverts that data to   dev/tty23   but also rings a bell.  To accomplish this, do the following...

    mkfifo /dev/bell23
    

    Place the following listing in the   /etc/init.d/   directory in a file called   beepmrgd   it is executed by the program   vt23beep   shown below the beepmrgd listing.

    #!/usr/bin/perl
    
    # /etc/init.d/beepmrgd
    #
    # This trivial program Copyright 2008, Jim Phillips may be copied only under
    # the terms of either the Artistic License or the GNU General Public License,
    # which may be found at www.fsf.org or if your machine is a Linux box, check
    # in   /usr/share/common-licenses   for license listings.
    #
    # Although this program works as it is written, there are many short comings,
    # lots of room for improvement, like maybe not sounding the bell on errors
    # below a certain priority.  Please feel free to modify it under the terms of
    # the aforementioned licenses.  See what I mean, I'll make a programmer of
    # you yet.
    
    use Proc::Daemon;
    
    ($source, $dest) = @ARGV;
    
    if (($source eq "") || ($dest eq ""))
        {
        print "\nPurpose: To merge a beep into the outgoing data stream ";
        print "anytime incoming pipe is fed a new line of data.\n";
        print "Usage:   beepmrgd named-instream tty-device\n\n";
        print "A practical example might look like...\n\n";
        print "         /etc/init.d/beepmrgd /dev/bell23 /dev/tty23\n\n";
        print "...Where /dev/bell23 is a named pipe, not a real device file\n\n";
        exit;
        }
    
    #      Test these files for openability, and then close them, while we
    #      can still die with a message that will print on our local terminal.
    open (INFILE, "<$source") || die ("Can't open input file $source: $!");
    open (OUTFILE, ">>$dest") || die ("Can't open output file $dest: $!");
    
    #  Note: the above 2 lines of code will hang until data is sent through it
    #        The proper proceedure for starting this Daemon is to first with
    #        syslog.conf set to NOT send anything to the bell pipe  /dev/bell23
    #        and   /etc/init.d/sysklogd restart   run to "Make it so"
    #        You start the daemon by running   /etc/init.d/post_boot.sh   it has a
    #        line like   /etc/init.d/beepmrgd /dev/bell23 /dev/tty23   that starts
    #        it.   As noted above the code will hang until data is sent through it.
    #        Next edit   /etc/syslog.conf   to start sending messages to
    #        /dev/bell23   and run   /etc/init.d/sysklogd restart   to "Make it so"
    #        Since as sysklogd restarts it sends messages upon doing so, the bell
    #        will sound, a restart notification will appear on VT23, and the
    #        terminal that launched post_boot.sh is now reporting...
    #        "I/O selection found reasonable, and workable, beep going Daemon."
    #        and that terminal is now back at a bash prompt.
    
    print "I/O selection found reasonable, and workable, beep going Daemon.\n";
    
    close(INFILE);
    close(OUTFILE);
    
    Proc::Daemon::Init;
    
    open (INFILE, "<$source");  #  We've tested them, so open them blind
    open (OUTFILE, ">>$dest");
    
    while (1==1)
        {
        while ()
            {
            print OUTFILE "$_\007\r\n" ;
            }
        }
    
    
    



    #!/bin/sh
    #
    # This   vt23beep   BASH script normally located at   /etc/init.d/vt23beep
    #
    # start/stop Beep Merge Daemon  beepmrg.d  for VT23 message alert beeps
    
    test -f /usr/bin/perl || exit 1
    test -f /etc/init.d/beepmrgd || exit 1
    
    case "$1" in
    
        start)
           echo "Starting VT23 Beep daemon:"
           SYSLOGD="-f /etc/syslog_do-beep.conf"
           pidfile=/var/run/syslogd.pid
           binpath=/sbin/syslogd
           echo -n "Restarting system log daemon: syslogd "
           echo    "using syslog_do-beep.conf"
           start-stop-daemon --stop --quiet --exec $binpath --pidfile $pidfile
           sleep 1
           start-stop-daemon --start --quiet --exec $binpath -- $SYSLOGD
           #   -   -   -
           echo
           /etc/init.d/beepmrgd /dev/bell23 /dev/tty23
            ;;
    
    # Of Course  kill -9 `pidof -x /etc/init.d/beepmrgd`  would be too simple
    # Right?  :-)   I point it out for crude cmd-line control while debugging
        stop)
    	echo "Stopping VT23 Beep daemon:"
            bpmrgpid=`pidof -x /etc/init.d/beepmrgd`
            if [ -n $bpmrgpid ]
            then
               {
               kill -9 $bpmrgpid
               #   -   -   -
               SYSLOGD="-f /etc/syslog_no-beep.conf"
               pidfile=/var/run/syslogd.pid
               binpath=/sbin/syslogd
               echo -n "Restarting system log daemon: syslogd "
               echo    "using syslog_no-beep.conf"
               start-stop-daemon --stop --quiet --exec $binpath --pidfile $pidfile
               sleep 1
               start-stop-daemon --start --quiet --exec $binpath -- $SYSLOGD
               }
            else
               {
               exit 1
               }
            fi
            ;;
    
        *)
    	echo "Usage: /etc/init.d/vt23beep {start|stop}"
    	exit 1
    	;;
    
    esac
    
    exit 0
    
    



    #! /bin/sh
    #
    # This file   /etc/init.d/post_boot.sh   is to make some finishing touches
    # to the system.
    #
    # For this file to do anything at all, a symlink from   /etc/rcS.d/  must
    # point to it.  Not only that, but the proper "Startup Sequence Priority"
    # To layin a proper Startup Sequence for a Debian Sarge box execute the
    # following link command:...
    #
    # ln -s /etc/init.d/post_boot.sh /etc/rcS.d/S55post_boot.sh
    
    # You're wondering why, for instance, normally to change the number of loop
    # devices you have to work with, it's a simple entry in   /etc/modules.conf
    # Debian went a little a-miss here, in Sid, and Sarge, for sure, maybe more.
    #
    # So I invented this file to fix things like this.  Yes it's crude, like
    # using a "goto" in 'C' but expedient.  JKP
    #
    
    # -------------------------------------------------------------------------
    # The rest of this   post_boot.sh   activates the alternate error message
    # reporting daemon   vt23beep   that diverts these error messages to VT23
    # -------------------------------------------------------------------------
    
    # Set bell freq to 2Khz and dur 1/2 second on tty23 to make the sound unique
    /usr/bin/setterm -bfreq 2000 -blength 500 > /dev/tty23
    
    # Re-instantiate klogd to only bother console
    # users with the highest priority messages
    /bin/echo Re-Instantiating klogd at higher console message priority
    if [ ! -z `/bin/pidof /sbin/klogd` ]
    then
        {
        /bin/kill -HUP `/bin/pidof /sbin/klogd`
        }
    fi
    /sbin/klogd -c 3
    
    # Set VT23 to beep when a message from syslog is sent through the
    # beep daemon   /etc/init.d/beepmrgd /dev/bell23 /dev/tty23   on its
    # way to VT23 the error message dumping ground.
    /etc/init.d/vt23beep start
    
    # Suggest things the Admin should do on this machine immediately after powerup
    /bin/echo "Things one might want to do after powerup."
    /bin/echo ""
    /bin/echo "/etc/init.d/vt23beep stop      Turn off VT23 audible message alert."
    /bin/echo ""
    
    


    11.   Adding-or-Removing a bell tied to VT23 activity.








    
    
    Here's where I left off  Things_VT --L359--64%   much more work needs to be
    done on this file, as you can see
    
    
    .----------------------------------------------------------------------------.
    `----------------------------------------------------------------------------'
    
    
    
    SVGATextMode+bell patch for 2.6.11-vz9.2
       Subject: SVGATextMode+bell patch for 2.6.11-vz9.2
       List-id: <linuxconsole-dev.lists.sourceforge.net>
    James:
    I noted that the SVGATextMode+bell patches where
    absent from 2.6.11-vz9.2. I attach the diff.
    I don't use framebuffers, SVGATextMode is faster and
    looks better. The original patch was by Aivils. The
    bell patch provides bells on vt's other than vt7, the
    original is by Jean-Daniel Pauget.
    Regards,
    Hugo
    
       Attachment: patch-2.6.11-vz9-92.hvw
       Description: 2166988619-patch-2.6.11-vz9-92.hvw
    
    
    Start X up on <Alt F8> ?
    startx -- :1 -bpp 16
    
    
    
    :1  ==  F8
    :18 ==  F25
    
    startx -- :18 -bpp 24
    
    SYNOPSIS
           chvt N
    DESCRIPTION
           The  command chvt N makes /dev/ttyN the foreground terminal. The corre-
           sponding screen is created if it did not  exist  yet.  To  get  rid  of
           unused VTs, use deallocvt(1).
           The  keymap  action  `Console_N'  (usually  bound  to  key  combination
           (Ctrl-)LeftAlt-FN, with N in the range 1-12, and to RightAlt-FN-12 with
           N  in  the range 13-24) also allows to switch to another VT, but really
           switches only if it is already allocated. This prevents allocating  new
           VTs with a misplaced keystroke.
    SEE ALSO
           deallocvt(1).
    
    
    
    CurDir = <  /home/jim  >
    [jim@thinman]$ grep -i defaultserver /usr/bin/X11/startx
    defaultserver=/usr/X11R6/bin/X
    defaultserverargs=""
        defaultserverargs=$userserverrc
        defaultserverargs=$sysserverrc
            server="$defaultserverargs"
            server=$defaultserver
    CurDir = <  /home/jim  >
    [jim@thinman]$ #  defaultserverargs="vt25"
    
       CAPTION: Capacities of Compact Disc types
    
        Type  Sectors  Data max size     Audio max size   Time
                       (MB)    (MiB)     (MB)     (MiB)   (min)
         8 cm  94,500 193.536 ~= 184.6   222.264 ~= 212.0    21
              283,500 580.608 ~= 553.7   666.792 ~= 635.9    63
       650 MB 333,000 681.984 ~= 650.3   783.216 ~= 746.9    74
       700 MB 360,000 737.280 ~= 703.1   846.720 ~= 807.4    80
       800 MB 405,000 829.440 ~= 791.0   952.560 ~= 908.4    90
       900 MB 445,500 912.384 ~= 870.1 1,047.816 ~= 999.3    99
       Note: Megabyte (MB) and minute (min) values are exact.
    
       CD capacities are always given in binary units, although decimal SI
       prefixes are usually used: a "700 MB" CD has a nominal capacity of
       about 700 MiB. DVD capacities, on the other hand, are given in decimal
       units: a "4.7 GB" DVD has a nominal capacity of about 4.38 GiB.
    
    shown in White.
    Hello world
    

    shown in Purple.
    Hello world
    

    shown in Blue-Green.
    Hello world
    

    shown in Yellow.
    Hello world
    


    Back to Me and Linux

    The large print Giveth, and the small print Taketh away

    CopyLeft License
    Copyright © 2000 Jim Phillips

    Know then: You have certain rights to the source data,
    and distribution there of, under a CopyLeft License