Related:

• hell [orig. Multics n. techspeak, widely propagated via Unix] 1.
  [techspeak] The command interpreter used to pass commands to an operating system...
• exec: /eg-zek'/ vt., n. 1. [UNIX: from `execute'] Synonym for {chain}, derives from the `exec(2)' call.
  2. [from `executive'] obs. The command interpreter for an {OS} (see {shell})...
• chain: 1. [orig. from BASIC's `CHAIN' statement] vi.
  To hand off execution to a child or successor without going through the {OS} command interpreter that invoked it....
• chain 1. vi. [orig. from BASIC's CHAIN statement] To hand off execution to a child or successor without going through the OS command interpreter that invoked it.
  The state of the parent program is lost and there is no returning to it....
• wizard mode: [from {rogue}] n. A special access mode of a program or system, usually passworded, that permits some users godlike privileges.
  Generally not used for operating systems themselves (`root mode' or `wheel mode' would be used instead)....
• cooked mode: [UNIX, by opposition with {raw mode}] n.
  The normal character-input mode, with interrupts enabled and with erase, kill and other special-character interpretations performed directly by the tty driver....
• c file: /R-C fi:l/ [UNIX: from the startup script `/etc/rc', but this is commonly believed to have been named after older scripts to `run commands'] n.
  Script file containing startup instructions for an application program (or an entire operating system), usually a text file containing commands of the sort that might have been invoked manually once the system was running but are to be executed automatically each time the system starts up....
• demon: n. 1. [MIT] A portion of a program that is not invoked explicitly, but that lies dormant waiting for some condition(s) to occur.
  See {daemon}. The distinction is that demons are usually processes within a program, while daemons are usually programs running on an operating system....
• deadlock: n. 1. [techspeak] A situation wherein two or more processes are unable to proceed because each is waiting for one of the others to do something.
  A common example is a program communicating to a server, which may find itself waiting for output from the server before sending anything more to it, while the server is similarly waiting for more input from the controlling program before outputting anything....