Human Interaction

A lot of system customizations may be done Behind the Scenes, although some features (such as a change in the window interface) are not meant to be done in a way that has no noticable impact to average end users. This section is mainly about how computers interact with humans and, terrifyingly, vice-versa.

Some of this may be rather specific, while some more general overviews might be in the user interface basics section.

User interfaces
Command lines

These can be useful for people sitting at a local console, people using a remote access solution like SSH, and people wishing to have programs being started by other programs.

For users of Unix, also check out the section on Unix terminals/consoles.

[#clishels]: Multiple shell choices
[#likshcsh]: Unix shells
A list of recognized shells might be listed in “/etc/shells”. (This list may be recognized by programs such as chpass and, as pointed out by OpenBSD's default version of this file, the file transfer protocol server ftpd.)

The most commonly used shells are largely compatible with the Bourne shell (sh). Examples of some alternatives include variations of the Korn shell (ksh), and bash. An alternative preferred by some people is the “C shell” csh, or a similar shell, tcsh. (All of these examples given use filenames that match a *sh* filespec as commonly supported in Unix.)

[#cshharm]: Csh Harm

Csh is viewed by many as being buggy by design, and therefore support of csh is even declared as a bad, harmful thing. Here are some articles that overview this claim:

MS-DOS and compatible

The basic command line of MS-DOS is COMMAND.COM. OS/2 and modern versions of Microsoft Windows have CMD.EXE which may have some additional support, such as better handling of long filenames.

JP Software products have additional shells. Some of the products are commercial. Others have source code released.

MAC OS X

There may be multiple ways to run Terminal. Here is what may be the most common steps with MAC OS X.

  • Use Finder
    • This may be done by locate the Dock near the bottom of the screen. (However, it seems like many Mac users are already aware of this, so if you start with a direction to use Finder, they will often know how to do that.)
  • Look for “Applications”
  • Look for “Utilities”
  • Double-click on “Terminal”.

Some feedback indicates that Terminal may be based on tcsh.

Substitutions

Environmental variables (operating system, or command processor, variables), and some other alternatives which may still need to be expanded upon or referenced in more detail: SUBST.EXE, soft linking, etc. Using the PATH environment variable, possibly by simply putting in batch/script files that run a different command. (Similarly, linking to the same executable that acts based on its filename.) Command line aliases (and hotkeys, such as JP Software's aliases keyboard aliases).

[#cmdhist]: Command line history

The basics of using command line history are mentioned by “User interface basics” guide: section on command lines (subsection about command line history). See that section further for details about using the command line history effectively.

A rather drastic change, which should work in many cases, is to use a different shell. This is generally an option for many Unix systems. For MS-DOS compatible systems, using a JP Software product is recommended. If that isn't readily available, perhaps CMD.EXE is built into the operating system. MS-DOS compatible systems which are not using a modern operating system with a graphical interface may benefit in the short term from running doskey which comes bundled with the operating system as an external command (meaning that it is not part of the shell). However, in some other operating systems, some decent command line history recall ability may be built into the shell, and so doskey serves little purpose. (It may allow for macro definitions, although such usage is not commonly popular to implement. The other main effect it may have is wasting some memory.)

However, there may be some additional configuration available.

Microsoft Windows

Run a command prompt and then choose the system menu. There may be some options that relate to command line history. For example, in Windows Vista (64-bit Home Premium), an options tab has a “Command History” section. The default Buffer Size may be 50, with the default Number of Buffers being set to 4.

JP Software products

Further research may be needed to verify how many, if any, of the options may be specific to 4DOS, and not supported by newer options like TCC LE.

Modifying the prompt
MS-DOS

Modify the PROMPT variable. This can be done with traditional methods of modifying the environmental variables, or with the PROMPT command.

The default prompt value for MS-DOS may be empty, which may cause the prompt to look the same as if the prompt was set to $N$G (showing just the drive and a greater-than sign). A much more popular version is to use $P$G (to show the current drive and path). There are other codes that may be used, which may vary based on the exact command shell being used. (For a command shell that is bundled with the operating system, this may vary based on the version of the operating system being used.) JP Software's help for the PROMPT command shows some options used by those commadn shells.

If color is desired, it is recommended to use one of JP Software's products, which have now become publicly-shared source code (with restrictions on source code usage) and free. However, another option is to use ANSI escape sequences. That method will work on more platforms, but it does not look nice unless the ANSI escape sequences are supported. Supporting ANSI escape sequences is generally done via a specific driver, and there is one or more third party drivers which will use up less memory than the versions that come with some operating systems. Further details are needed here about other ANSI drivers. (Perhaps see ANSI.com / ANSI_COM / NANSI.SYS, some of which may be shareware or used to be. PC Magazine may have released an option.) JP Software's page on ANSI support may show some details about internal support. See JP Software's help about ANSI support. PC Magazine's ANSI.COM by Michael J. Mefford has reached version 1.3l (that version number ends with a lowercase letter L), and is very small and comes with assembler source code. (ANSI13L.zip). Jason Hood's ansicon. Jason Hood's ANSICON is, according to its web page, “basically the Windows equivalent of ANSI.SYS.” NANSI.SYS (by Daniel Kegel, the derived NNANSI for EGA/VGA only by Tom Almy, and subsequent work by Eric Auer) has become GPL'ed. Note: Some of this may be more appropriately shown in a section about video output/device drivers.

In Unix
The effect may depend on what is in the shell. ksh and bash may use PS1, PS2, PS3. (See: customizing command line interface prompt.)

Some things that people like to do with prompts, other than just adding colors, include:

  • Include the path of the current direcotry
  • Include the user account's account name
  • Include the name of the system being used (particularly for users who access the prompt via a remote command prompt)
  • Include a reference to what the permissions level is
  • Include the error/exit/return code of the last command which is run
  • Include a number showing how many commands have been run
  • Include a clock. (The clock might show the time when the prompt was first shown, or it may be a real-time clock.)
  • Include a flag which may show whether an event, such as a new E-Mail being received, has occurred.

One unpleasant part of including a lot of information (especially unuseful information, such as ASCII art) is that this generally allows fewer characters to be typed before word wrapping requires another line to be used when a long command is used. This isn't necessarily a technically limiting problem, but it can be less pleasant than avoiding that scenario by just limiting the length of the prompt.

[#cpprgind]: Copying files (with progress indicators)

Some additional options for copying files (which may be options that do not show progress as much) may be available from the guide to copying files. (At the time of this writing, there may currently be some duplication in these sections.)

Unix

The one thing that people more familiar with MS-DOS, Windows, or OS/2 need to be aware of is that Unix always treats the last argument as a destination. So a destination needs to be used, even if it is . (simply a period by itself, representing the current directory). Case in point: “ cp /* ” will cause the shell to expand the wildcard to list all filenames and then the last filename ends up being a destination. (In contrast, MS-DOS may use “ COPY \*.* ” and that is treated like one command line argument, so the destination of the current directory is assumed.)

See the package called “pv” (which stands for “pipe viewer”). This command may be used to add a progress bar to a command that uses file streams but which doesn't provide a progress bar of its own. Examples of commands are cp, dd, netcat, or file compressors. A screenshot showing one command line calling pv three times as a tarred bzip2 is converted to a gzip shows how elaborate a skilled user can take advantage of this simple little program to create multiple progress bars. The command line is very similar to:

pv -cN sourceCmd < linux-2.2.20.tar.bz2 | bzcat | pv -cN bzcatCmd \
| gzip -9 | pv -cN gzipCmd > linux-2.2.20.tar.gz

(Actually, the sample command line just shown does vary a bit from the picture, which leaves off the “Cmd” portions mentioned in the above example. The three phrases that include the letters “Cmd” in the above example (“sourceCmd” and “bzcatCmd” and “gzipCmd”) are just some strings that get used in pv output so that the correct output line can be easily matched to the correct pv command line. However, they are just labels/strings/words, and there's no technical requirement that they match the name of the executable file.

MS-DOS

Some commands may support COPYCMD. (JP Software products do/may have an online help topic about this environment variable: It is similar to support for the DIRCMD variable.)

The command XCOPY may support more features than COPY. (However, JP Software's utilities will likey provide more options.)

Windows

The Windows NT line has offered “Robust File Copy”, probably more commonly known as “Robocopy”, as part of the resource kit, up until Vista when a version of Robocopy has been included. Wikipedia's page on Robocopy notes that “Robocopy does not behave consistently between different platforms.” (This text was specifically related to replicating security attributes.)

Copying may also be done with options that are also available with MS-DOS (COPY, XCOPY, and in Win9x perhaps XCOPY32?) or by using the graphical interface. For a greater degree of control, see also RichCopy. Another option is Robocopy GUI, which uses Robocopy, although it may provide little to no benefits that aren't easily performed by using one or both of the other options Robocopy and Richcopy.

[#uselscol]: Displaying files (using color to do so)
customls (which may be a bit duplicated with information here)

Oddly enough, this is something that is more typically implemented with command line interfaces, which are typically designed for use with text mode, and not with graphical user interfaces. Color is very often lost when being piped, so redirecting output to a file or a text file pager/viewer and viewing the output will often result in color being completely lost. However, it can help make interfaces a bit less dull and help to identify certain file types (whether “type” means something like a standard file or something else like a directory or some sort of link/shortcut/device visible in the file system, or whether referring to file extensions) more quickly by using the visual indicator of color.

[#lswcolor]: Unix

Instead of having ls simply run /usr/bin/ls, it is prefererd by some to have it run another command such as “ gnuls -l -AF --color=auto ”.

If colors are not being seen, there are various reasons for this. One is that colors may not be supported by the terminal: If using a remote connection then make sure the terminal software being used supports colors. Make sure the terminal type specified in the TERM variable is one that supports colors. Check the man page for the program displaying files to see if color support needs to be specified by a command line argument: If no support for colors is mentioned then it may not be supported in which case one of the programs listed below may be needed. In FreeBSD, csh and tcsh (according to guide to color ls in BSD comment from Aug 29, 2005 3:40:01am) support color if specified by an environment variable called CLICOLOR. In FreeBSD, ls may support color by using an environment variable called CLICOLOR or by using the -G parameter.

(OpenBSD 4.6's description for colorls says that “wsvt25” works for a wscons console and “xterm-xfree86” works for the standard X Windows client: using values of “vt220” or “xterm” “are not color-capable” in the default termcap file. It is probably possible that some software may support colors in some environments where other software does not support colors. Another option may be to use the rxvt TERM along with the software called rxvt.)

Here are some various reasons why color might not show up:

  • The /bin/ls simply doesn't support it. For example, although FreeBSD's does, OpenBSD's and NetBSD's do not.
    • However, both OpenBSD and NetBSD do support functionality like FreeBSD by using a package named “colorls”. OpenPorts for colorls says, “This is a simple hack, taken from FreeBSD, to” (the ls command) “to use ANSI sequences to display file attributes in color.”
  • Even if the program supports it, the program might not be displaying color
    • With some GNU-based software, try using --color=always (which might be more prone to show colors than --color=auto
    • With BSD (the colorls package for OpenBSD/NetBSD, or the base ls command for FreeBSD), use -G
  • The program sending output may realize that the code is being sent to a pipe. That might convince the program to strip color codes.
    • Instead of “colorls -G | less”, try “env CLICOLOR_FORCE=anyNonNULLValue colorls -G | less -R”.
  • Color codes may be getting stripped from the output
    • Do not use less without either the preferred -R parameter, or perhaps the -r parameter
      • This parameter can be saved to a default
    • A GPL'ed program called most may act as a pager and default to showing color. (This most program can also translate the output of the man command.)
  • The terminal might not support color codes

If color isn't supported (e.g. with OpenBSD's default /bin/ls command), realize that file types may be distinguished rather quickly by using the -F option for ls. This places suffixes at the end of files. If color is still desired (perhaps because it helps to distinguish even faster), then use a different piece of ls software. Examples include colorls or gnuls. (With Debian? Ubuntu?, the gnuls may simply be the default /bin/ls program. With other platforms, the command line may be gnuls which might only be available after it is installed separate from the base operating system installation. With OpenBSD's package, after installing gnuls the package is named gls as described by OpenBSD 4.6 description for gnuls.)

Once finding a preferred version, that may be the default when ls is used (instead of just running “/bin/ls”). (Note that some people may be annoyed by such a color customization: such users are still free to run specifically reference “/bin/ls” by name and presumably that should remain uncustomized.) Be aware that colors may not always work well, including if it is piped. (If piped to a pager, the colors will look like escape sequences.): for this reason it is recommended, insetad of using “ --color=always”, to instead use a terminal that is detected by the ls program being used and to use either “ --color” or “ --color=auto”. (However, using “ --color=always” may be useful when trying to verify whether a remote terminal program will be likely to support the color.)

The root directory is often a great directory for testing colors, as it usually does not have a lot of files but it does have subdirectories and may have symlinks.

alias ls="gnuls -AF --color=auto"
 ls -ah /

(Perhaps See also: dir, dircolor, dircolors, DIRCOLOR, DIRCOLORS. rxvt - FAQ refers to an LS_COLORS environmental variable and a file named /etc/DIR_COLORS as being things used in some cases/systems/platforms/environments. Comment on archived copy of a guide to color in ls says FreeBSD's csh or tcsh supports CLICOLOR (when using csh or tcsh).

See also: custom views of directory listing.

[#dirwcolr]: MS-DOS (and OS/2 and 16-bit and 32-bit versions of Microsoft Windows)
Some commands may support DIRCMD. (JP Software products have an online help topic about this environment variable. It is similar to support for the COPYCMD variable.) See TOOGAM's page about JP Software products (some of which are freeware and others of which are shareware) support a variable called COLORDIR. For other alternatives, see the shareware hdir/hotdir, perhaps ZanySoft Directory (ZDIR).
Other Windows versions
If the version of Windows being used cannot run MS-DOS programs, TOOGAM's page about JP Software products has information about JP Software products. Some JP Software products are known to work in these newer versions of Windows. (See using COLORDIR.) Some commands may support DIRCMD. (JP Software products have an online help topic about this environment variable.)
Terminals
[#unxconsl]: Unix terminals/consoles

Information which used to be here has been moved. See: Unix terminals/consoles.

Some hyperlink anchors used to be here, but each had related information moved to a new sub-section.

[#trmltplx]: Terminal Multiplexing

The information that was in this section has now been moved to a new Terminal Multiplexing sub-section.

[#tmxscrbk]: Scrollback (in terminal multiplexer programs)

The information that was in this section has now been moved to a new Terminal Multiplexing: terminal multiplexing scrollback sub-section.

[#tmuxscbk]: tmux

The information that was in this section has now been moved to a new Terminal Multiplexing: tmux scrollback sub-section.

“Graphical” interfaces
Graphical Interface Start

Many operating systems come bundled with a graphical interface, and by default will have the graphical interface automatically started when the operating system starts. Automatically starting the graphical interface may be fairly optional.

Starting a graphical interface
Microsoft Windows
Windows 3x (not Win NT), 95, 98, ME

If the graphical interface is not started, but the system is at a DOS prompt, running win may start it up.

With earlier versions of Microsoft Windows, this was often done automatically by using the \AutoExec.Bat file.

With Windows 95 and Windows 98, this was typically done automatically unless one of the boot files (typically named \MSDOS.SYS) specified otherwise.

Windows ME was more challenging to cause to NOT boot up the graphical environment. Contrary to popular belief at the time, this could be done without using (rather undocumented) third party modifications to Microsoft's code. (Some people found the modifications to be quite questionable. The fact that those changes were not clearly documented were a reasonable cause for strong concern.) However, it may require a third party command line shell. See: Windows ME: Automatic (forced) running of Win ME's GUI to learn how to get around this designed challenge (and to be able to clearly know what is happening to the system when doing so).

The X Window System
Overview
Warning of Networking Integration

The X Window System was designed to be able to allow a program to run on one computer, but for another computer to provide the user interface. This means that a program could run on an internal computer, and the user interface could be displayed on a remote, malicious computer. Similarly, a malicious program could run on a remote, malicious computer, and have the user interface of that malicious program run on another computer.

A traditional design of the X Window System is not substantially slowed down by network interfaces when a program is running locally. One reason is because the loopback interface can operate more quickly than a network card, and the second reason is because some optimizations may exist.

However, unless the networking feature was carefully set up, this networking feature needs to be disabled, or the network traffic blocked, when using the X Window System. Fortunately, many operating systems come with firewalls that block the feature, and or may have this feature disabled by default. So, in many cases, this is not an issue. However, due to the potential severity, for safety's sake, this is a matter that should be investigated before running the graphical interface. (If the graphical interface has already been started, checking into this may be a top priority.)

TCP port numbers include 6000 and other numbers right above that (e.g. 6001 through 6010 to block up to ten additional X Window System desktops). (Note that similarly, VNC may wish to block 5900 and nearby higher numbers, as well as 5800 and nearby higher numbers (also related to VNC). Usage of those ports is discussed by VNC desktop number.

remote access: shared display, XForwarding (particularly Xauth, XDMCP, and the even less secure Xhost).

Additional overview considerations

Before trying to install the X Window System, check operating system documentation to see the preferred method. Very often, the GUI might be pre-installed.

The command to start the X Window System may depend on which implementation is being used. This is another reason to check the operating system documentation. Find out which version of the X Window System is recommended for local use. (Such documentation probably won't mention the VNC-integrated options, so if one of those options is desired then the operating system documentation may typically not provide relevant details about that approach.)

Be prepared for potential problems, such as the mouse not working, or not having a window manager automatically running by default (for some environments). Remember that Alt-Ctrl-Backspace may typically kill the graphical interface, and that may not be a bad thing to remember if things are not working well.

OpenBSD FAQ 11 (X), section on “Configuring X on amd64 and i386” states ways to terminate the X window process, including, “Sometimes, a bad X configuration will hang the entire machine to the point that only a hard reset will resolve the problem.” (This means that an improper shutdown, caused by powering off the machine, may be needed.)

Commands for starting a GUI

There are a few common commands to start the GUI. Perhaps try each of these, in order:

which startx
 which xinit
 which X

Note: those commands do not run X. Instead, the which commands will attempt to locate the requested filenames, which are filenames that may successfully start X. The full location of any located filename will be output by each relevant which command. If the filename is not available, then the which command will not report anything.

If there are any troubles, try running the command

The startx command is a script that runs the xinit command (which may be a compiled executable, and not simply a script).

Implementations
X.org

Derived from XFree86.

Releases
Xenocara

OpenBSD Journal @ Undeadly.org article on Xenocara states that X.org decided on an organization to “allow drivers maintainers (or others) to make independent releases, whenever they are needed.” Then OpenBSD group maintains such a release to help with the building process. The changes from X.org are mainly about how source code is handled, rather than massive customizations that affect end user experiences. End users are not likely to notice any difference between Xenocara or a more default X.org release.

Starting X.org
Identifying requirements
OpenBSD FAQ 11 (X), section on “Configuring X” lists platforms and requirements for various platforms. For example, there is quite a bunch of text for Mac PPC platform, and some platforms need an aperture setting (which is about to be discussed in further detail), and some systems might not support running an X server. Become familiar with any notes on the platform that is being used.
Handling aperture

(Speculation Note: This can involve interaction with the kernel, or BSD system settings. So, this might be BSD-specific?)

OpenBSD FAQ 8, from year 2004 as archived by the Wayback Machine @ Archive.org refers to needing support in the kernel, although the GENERIC kernel does support this (so that won't be an issue for most users). Such text does not seem to be in the latest version of the guide, so perhaps that requirement is old and no longer relevant anyway. (So, for most people, don't worry about it. However, for people who are tinkering with custom kernels, know that this little detail could be a major showstopper much further in the process.)

On some systems, an aperture may need to be enabled. This is true for the x86 and x64 platforms, which is the platform that has been used for most common desktops, laptops, and servers released in about the year 2012 and earlier. (That may still be true throughout 2013 and later, although other platforms have been gaining popularity, especially for SFF (small form factor) devices such as phones and tablets. One possible exception might be Mac platforms.) Here is an example for checking the setting on a BSD system, see:

$ grep -i allowaperture /etc/sysctl.conf
machdep.allowaperture=2  # See xf86(4)

If that is not set, it may need to be. Also, the system may need to be rebooted after changing that.

So, why wouldn't the aperture setting have been set to the highest possible value? Well, particularly with aperture setting value of 2, OpenBSD FAQ 11 (X), section on “Configuring X” states, “There are security implications to this, so do not do this if you do not need it.” Using a setting of 2 is discussed in a bit more detail by OpenBSD manual page for xf86, as that manul page says; “Note that this can cause some security problems, since the process that has access to the aperture driver can also access part of the kernel memory.”

Starting X

OpenBSD FAQ 11: X seems to suggest that the recommended process is not try not doing any additional configuration. So, let's just try that.

sudo startx
Other configuration

If X does need to be configured, then having the machine create a custom configuration file may be a great first step in many cases. To do that, use:

sudo X -configure

Yes, OpenBSD FAQ 11 (X), section on “Configuring X” states, “You will need to do this as root”. The big impact of running this command is that it will create a text file (which is a configuration file). It will also create some output, which may include lines like the following:

Your xorg.conf file is /root/xorg.conf.new
To test the server, run '/root/xorg.conf.new'

Note the filename that gets output. Then, the end user may try using:

X -config /root/xorg.conf.new

If that fixes things, then that configuration file will likely be preferred for future usage. If not, check the log file. When X.org starts, the terminal that started X will mention what log file is being used. Often, that message will be scrolled past the visible screen, so scrollback may be needed. Or, the default common log file location could just be checked: it is /var/log/Xorg.0.log (which has a zero near the middle of the filename).

If this doesn't work, see the “What if it isn't that "easy"?” section of OpenBSD FAQ 11 (X), section on “Configuring X on amd64 and i386”.

XFree86
...
VNC-included implementations

Some VNC server software has been designed to work with X. For instance, x11vnc will try to locate an existing X session, and can create an X session if it does not exist. (To do this, x11vnc does require an installed standard implementation of the X Window system. The x11vnc program may run the xinit command.)

For details, see: VNC Server software that is designed to work with X.

Window managers
IceWM

IceWM provides windows with “chrome” that includes a title bar that can be used to drag windows, and buttons for minimizing, maximizing, and closing applications. Re-sizing is done by dragging corners. All of that sounds like what people are familiar with, but IceWM doesn't just stop there. IceWM also provides a “Start” button, like what Microsoft Windows 95 made popular, as well as a task bar, and the lower-right corner may show a clock.

Another nice plus is the icewmbg program which can help make the background customized with a desired color and/or graphic.

On the minus side, the program's menus (accessible by using the IceWM button, or by right-clicking the root window) are configured in standard text files. That is not entirely terrible by any means, but it would be much nicer if the IceWM interface allowed a quick and easy way to allowed a user to modify the menu. So, a bit of configuration may be commonly desired for just that one simple aspect.

icewm software unofficial man pages

Ice-WM FAQ 3 mentions icewm-session

System startup customizations

As noted in the overview, there are a few commands that may be commonly useful for starting X.

If one of those commands does exist, but does not seem to work (and has exited back to a shell prompt), try re-running it as the superuser (“root”) account (simply by using sudo), as that has been known to cause success.

See: ~/.xinitrc (which might often not pre-exist) or, if that file does not pre-exist, /usr/X11/xinit/xinitrc. Or, ~/.xsession may seem to run when ~/.xinitrc does not. A list of possible filenames may be docuemnted at OpenBSD Manual Page for startx, Files section and/or OpenBSD Manual Page for initx, “Environment Variables” section.

More material: Wikibooks Guide to X11: Starting Sessions.

e.g.:

#!/bin/sh
 echo Starting preferred window manager
 icewm && fvwm && cwm && twm
 xmessage The window manager has been stopped.  Entering loop to keep X alive.
 while true ; do sleep 90 ; done

Or, as a variation, you could use:

#!/bin/sh
 echo Starting preferred window manager
 icewm && fvwm && cwm && twm
 xmessage The window manager has been stopped.  Entering loop to keep X alive.
 while true ; do sleep 15 ; icewm ; done

That will keep trying to run IceWM every 15 seconds, which will be a bit wasteful. If IceWM detects another window manager, IceWM will just cleanly exit. If IceWM detects that no alternate window manager has been started, then it will simply start up. (Note that there might be no real easy way to detect how far the loop is in the sleep cycle, so quitting a window manager might start IceWM very quickly. However, the loop will then sleep for 15 seconds before trying again.) This is not really a good implementation because, after the first window manager exits, this implementation wastes resources most of the time (when a window manager is running). However, hopefully this serves as a simple improvable demonstration.

Background image

The “root” window has the background. The default is traditionally a bunch of pixels alternating between black and white, with the following row being offset (alternating white and black). OpenBSD FAQ 11 (X), section on “Configuring X on amd64 and i386” calls this a “root weave”, and this that this “mesh pattern” is “very good for seeing how good your monitor REALLY is and also great for calibrating LCD displays”. (These uses of the word “root” has nothing to do with the common practice of referring to a Unix superuser account as “root”.)

xsetroot

Bundled with X.org. may use:

xsetroot -bg color -fg color -mod 16 16

This makes a grid of rectangles, using lines that are the fg color. The color of the rectangles are the specified bg color. The size of each rectangle is affected by the two numbers after -mod which can range from 1 to 16.

(To make the background a solid color, simply make the foreground and background colors the same. Another method may involve using -mod values of 1 (“ -mod 1 1”), as well as specifying desired color(s).)

or...

xsetroot -bitmap filenameOfMonochromeXBMfile

That will tile a graphic which is using the “XBM” bitmap format. The big disadvantage to this software is the file format's monochrome limit, followed by the inconvenience of using a rather custom file format. The only benefit that might offset those limitations is the fact that this software may be built-in. Neither of those limits are really a big deal if the actual goal is just to set a background color.

[#icewmbg]: icewmbg (bundled with IceWM)

Note that this does not require using the IceWM window manager. (It does generally require having the IceWM window manager installed, because this software is bundled with IceWM. However, this does not require the IceWM window manager to be used/running.)

IceWM image formats, IceWM background color/image, IceWM FAQ: Where are the configuration files?, unofficial manual page (online as a web page)

ls -l ~/.icewm

After backing up any pre-existing configuration file...

mkdir ~/.icewm
 echo DesktopBackgroundColor=\"rgb:55/00/00\" | tee -a ~/.icewm/prefoverride
 echo DesktopBackgroundImage=\"file\" | tee -a ~/icewm/prefoverride
 echo DesktopBackgroundCenter=\"1\" | tee -a ~/.icewm/prefoverride
 echo DesktopBackgroundScaled=\"1\" | tee -a ~/.icewm/prefoverride
 icewmbg &&

Notice the notes on the official documentation. Particularly note that commenting out the DesktopBackgroundColor and DesktopBackgroundImage options “does not have the intended effect.”

To tile the image, set DesktopBackgroundCenter="1" and DesktopBackgroundScaled="0" (or, instead of setting it to zero, simply do not use DesktopBackgroundScaled in which case the default will be zero).

There may be more options: see “icewmbg --help”. (Perhaps also see: Reported bug/issue: SupportSemitransparency option breaking icewmbg.)

feh

Mentioned by LinuxQuestions about icewmbg alternatives.

Others

Recommended by LinuxQuestions about icewmbg alternatives. (There does not seem to be an OpenBSD port/package for this.)

recommendation to try pcmanfm, recommention mentioning nitrogen, xv to set bg

Virtual Desktops
Supporting multiple desktops

Some implementations include having multiple desktops for various users, such as a desktop created for an RDC session or Windows's Fast User Switching (Should the X forwarding section be moved here?).

The rest of this section, though, is mainly about multiple desktops being used by a single login session. (The ability to support this may be similar, at least in implementation, to the ability to support multiple monitors, which may involve using not only different ports on one video card, but possibly also using entirely different video cards.)

X Windows
Apple
Microsoft Windows
  • http://virtuawin.sourceforge.net/ (err, is this for X?)
  • See Deskman Virtual Desktop Manager, one of the PowerToys for Windows XP, Sysinternals Desktops for XP/Server-2003/newer.
  • Some graphics drivers may have specific implementations.
    • For nVidia cards, the software to support this may be named nView
Scrollable, oversized desktops

Wikipedia's article for “Viewport” says “With respect to virtual desktops, the viewport is the visible portion of a 2D area which is larger than the visualization device.” So supporting viewport technology means supporting a scrolling screen and having a viewport.

Graphics drivers that support multiple desktops will often support oversized desktops. (To avoid redundancy, they are not also being listed here, at least not for now.)

Wikipedia's article on the concept of a “Virtual Desktop”: section titled “List of notable Window Managers that provide scrolling desktops”, swm, tvtwm, Vtwm (“Virtual Tabbed Window Manager”)

X Window interfaces
This section is meant to describes various window managers. See also DOOM as an interface for system administration.
System user interfaces based on games

Content notice: The following material describes software which is more of a novelty than software that typically increases productivity. Also, the software may use interfaces that include content known to portray violence to an extent which has been controversial (e.g. Wikipedia's article on the video game DOOM: section entitled “Controversy”), or similar content. (Even if the specific implementations are historical and are not currently discussed as frequently as they used to be, largely due to being considered aged and primitive compared to newer implementations of games, there continue to be fans of such entertainment as well as critics concerned about societal impact.)

Even if these brief blurbs are considered relevant topics for brief discussion, there may be some considerations with the software in this section. For example, instructors who are financially sponsored by an organization, using using physical environments and/or equipment with sponsorship and/or (current and/or prior) funding by people who may object to such content, may wish to have some sort of limitations of presentations and/or demonstrations of this software. Even though the “the aftermath” page of one of the solutions shows the solution, which was developed by a college, being presented at the ACM's Computer-Human Interaction 2001 conference (SIGCHI CHI 2001), people with some outlooks/viewpoints may find such content to be entirely inapproprirate for some other settings. A rather neutral stance dictates that respect should be given to the simple fact that people do have different outlooks/viewpoints, and so this warning/disclaimer is appropriate so that choices may be made in an informed manner.

[#dmsysadm]: DOOM as an interface for system administration
The “research”

psDooM is based on some research made famous by Slashdot article: “Kill -9 With a Doom Shotgun” which referenced Dennis Chao's site “Doom as a tool for system administration”. (On that site's main page, Dennis noted that he would “like to thank the Adaptive Computation Group at UNM for providing a supportive environment in which one can claim one is doing research while playing Doom for two days.” (Hyperlinks unaltered, even though the UNM hyperlink seemed to point to the Computer Science department rather than the main page of the University of New Mexico.)

Doom as an Interface for Process Management says “The violence inflicted upon the monsters reflects the violent terminology of UNIX commands.”

Shortly after the Slashdotting, Dennis managed to post an update on a page titled Doom: the aftermath which stated, “The Doom as a tool for system administration web page was Slashdotted before I had a chance to wrap it up. However, I suppose that's not a bad thing because now thousands of people are thinking about it, and probably hundreds are hacking away at the code.” The Aftermath page provided some additional information, including answers to some questions about the project. (The “Doom as an Interface for Process Management” page's section on “Results” also has some information about the feedback received from the project, and a changes made in response to the feedback. (The reference to “the largest monsters in the game” is likely just referring to the shareware version of the game.)

“Certain processes are vital to the computer's operation and should not be killed. For example, after I took the screenshot of myself being attacked by csh, csh was shot by friendly fire from behind, possibly by tcsh or xv, and my session was abruptly terminated.” In fact, “Doom as an Interface for Process Management” page's section on “Results” found this to be a real issue with the software: “A significant problem with the current implementation of PSDoom is that monsters are much more likely to attack each other than expected. This causes many windows to mysteriously disappear as the program runs. For the same reason, the computer is prone to crashing because certain processes are vital to the computer's operation and should not be killed.” (The psDooM prevents this problem with special supporting code, although pain lovers may note that the “ -nopssafety” command line switch can be used to insanely remove this essential protection. Note that this does not prevent monsters from visibly appearing to attack each other, but the attacks are simply ineffective.)

Some of the findings:

Slide #7 of Dennis's talk notes, “System administrators are familiar with Doom.” However, such administrators may find (as noted by Slide #8 of Dennis's talk) that “It is easy, and even tempting, to kill the wrong process.” On the subject of the evil of staff members (being tempted to do something they should not do), the main page noted, “It is difficult to tell if your employees are doing real work or just goofing off when tools and games have the same GUI.”

Slide #16 of Dennis's talk offers a suggestion that games that reward player interactions could be modified to use a reward system when maintenance tasks are properly being taken care of. (In practice, this is likely implemented on a wide scale simply by using visual indicators, such as colors or graphics that represent cartoon faces that portray various emotions.)

Implementation(s)
psDooM “(aka: DooM for Sys A's) is a tool for system administrators.

psDooM “(aka: DooM for Sys A's) is a tool for system administrators. psDooM compilation error notes, “The psDooM binaries are built on an Red Hat 5.2 i486 system. They may not work on other distributions with different libraries.” The main README file for psDooM says, “psDooM can probably be made to work on any version of UNIX which runs XDoom.” Some specific requirements are given. A note is made, “psDooM has been tested on” “Linux x86 2.0.x, X11, and [S]VGA” and “Solaris SPARC 2.6, X11”.

The documentation of various command line arguments (such as “ -nopssafety” and -psuser username1 optional-additional-username” and “ -nopslev” and “ -respawnitems”, though there are also more) are rather spread out in various locations in that document.

OS X/X11 port
DOOM: the aftermath has hyperlinks to some various resources. One of them was labelled “OS X/X11 port”, although the hyperlinked site at http://resourcefork.com/WWWserver/software/psDoom/ does not seem to exist any longer. Wayback Machine @Archive.org's archive does have information and software downloads. The web page has “A Word of CAUTION” (with CAUTION in red letters): “Please note that by killing a monster with a name above its head WILL kill the process. It will not ask you to sake your work, so if you lose something you worked very hard on, don't blame me. I didn't shoot your program with the BFG, you did.”

Thoughts: The main problem noted by the interface is when game mechanics, particularly the artifical intelligence, applied to monsters causes the monsters to accidentally experience an undesirable fate (namely death). Although that may be remedied by psDooM (unless the “ -nopssafety” command line switch is used), could the situation be reversed instead of just disabled? What is meant by that is simply allowing the system's interactions to affect how the monsters behave.

This is probably the basis of much of the feedback (summarized where “Doom as an Interface for Process Management” page's section on “Results” noted that 23% of the feedback “offered suggestions for improving PSDoom”). The page notes some possibilites, “Processes that take more memory could appear wider, while those that take more CPU time can appear taller.” However, as for affecting behavior, “Sleeping processes could be represented by napping monsters.” Passive opponents seem to be what is shown by most of the units shown by the screenshots on the main page of Dennis Chao's site “Doom as a tool for system administration”. However, DOOM is a violent game, and so it would seem appropriate (for the environment) if monster interaction was to be affected by more than just napping. Some ways that the objects in DOOM could be affected by system interactions include:

  • If one process causes another to be ended, could the DOOM creature representing the killed process stick around as the corresponding DOOM creature of the parent process responds by hunting down and attacking the child process?
  • Documentation (for psDOOM?) suggests that ended processes disappear: It would be more logical for them to die (screaming, and remaining a corpse until the corpse is cleaned up, either after time or on an as-needed basis to not cause the DOOM interface to slow down).
  • Logged in users could be represented as other player characters: if they end a process then perhaps the avatar of that player could be automated to show the process dying. A user who is logged off could be rendered as a killed player. (A user who is banned could always become a splat.) (If a process was responsible for the logout, the appropriate monster could kill the player. Actually, it might be appropriate to represent that with a BFG, as once the player dies, the weapon could attack the monsters over a large area. The affected monsters would be the processes that get killed when the user is forcibly being logged off. Use of the killall command could also trigger such an attack.)
  • A player who is disconnected, but who has background processes running, might be transported to another location out of sight.
Marathon Process Manager for Mac OS
This “project based on the Marathon 2 source, Marathon Process Manager is an attempt to implement a Macintosh version of Dennis Chao's Doom-based process management system for Linux” (hyperlink to a relevant resource added). Similar to the implementation that uses DOOM source code, a player can attack a monster and “by killing the monster the player also kills the process associated with” the monster. (Regarding the game, Wikipedia's page on Marathon 2: Durandal makes note of the The Trilogy Release: Bungie.org's downloads of Marathon. (Bungie.org notes, “We are NOT Bungie Studios, but we like 'em a lot.”)
Brutal File Manager
Java based, meant to use an interface resembling a “first person shooter”. BFM links page (section for “other” hyperlinks) referred to psDoom as “A great insperation to BFM that showed us that managing your computer can be fun!”
L3DGEWorld
L3DGEWorld 2.3
Speech
See: User interface basics: Speech, User Speech

User Interface Environment

The following was starting to be a separate page, but would be better off just getting mixed into this page.

For some more details about using user interfaces, see user interface basics.

System shutdowns/restarts
System reboots/restarts
See: system startup process and the other sub-sections that are here.
[#sysstop]: System shutdowns

Shutting down a system often involves either rebooting, powering off, or performing some other action like hibernation and/or suspension.

Power-down
Power up
Wake on...
Wake on LAN, Wake on Ringer, Wake on Timer
Responding to power outage
A system may be set to power on once it receives power. Whether this is true or not may be a setting in the BIOS/CMOS setup. A UPS might be able to be remotely accessed, and may be able to provide an interface (using a data cable connected to the UPS) that allows a person to remotely affect which individual outlets are actively providing power.

After the system is powered on, the system goes through the system startup process.

File associations

Extentions often hint that a specific file format is being used. A user environment may use that fact to start a specific program, along with a reference to a file to use, when a user tries to “open”/“run” a file. For instance, trying to “run” a movie may cause a video player to open up and start using the data file that the user wanted to start using. For images, the user environment might open up an image viewer or an image editor, and provide the requested filename to the program.

FType and Assoc commands may exist. This may be an internal command, built into the command line interpretor? Windows XP product documentation: FType command, Windows XP product documentation: Assoc command, also as an internal command by JP Software). (See: Windows Components: Default Programs.

Network Software Human Interface

See: Network Software Human Interface.