|
|
lock-keyboard-for-baby 20080706 (Default branch)
07-06-2008
lock-keyboard-for-baby is a utility for thosetimes when a baby/toddler wants to bash away atyour keyboard. It grabs the keyboard until youtype a phrase (which hopefully the baby won'ttype), but without blocking the screen like ascreensaver.License: GNU General Public License (GPL)Changes:|
|
BABY(1) General Commands Manual BABY(1) NAME
baby -- create new process from two parents SYNOPSIS
baby -sex [m|f] [-name name] DESCRIPTION
baby is initiated when one parent process polls another server process through a socket connection in the BSD version or through pipes in the System V implementation. baby runs at low priority for approximately forty weeks and then terminates with a heavy system load. Most systems require constant monitoring when baby reaches its final stages of execution. Older implementations of baby did not require both initiating processes to be present at the time of completion. In those versions the initiating process which was not present was awakened and notified of the results upon completion. It has since been determined that the presence of both parent processes result in a generally lower system load at completion, and thus current versions of baby expect both par- ent processes to be active during the final stages. Successful completion of baby results in the creation and naming of a new process. Parent processes then broadcast messages to all other processes, local and remote, informing them of their new status. OPTIONS
-sex define the gender of the created process -name assign the name name to the new process EXAMPLES
baby -sex f -name Jacqueline completed successfully on July 9, 1992 at 9:11pm. Jacqueline's vital statistics: 8 pounds 3 oz, 20 inches, long dark hair. The parent process, Kim Dunbar, is reportedly doing fine. SEE ALSO
cigar(6), dump(5), cry(3). BUGS
Despite its complexity, baby only knows one signal, SIGCHLD, (or SIGCLD in the System V implementation), which it uses to contact the par- ent processes. One or both parent processes must then inspect the baby process to determine the cause of the signal. The sleep(1) command may not work as expected on either parent process for some time afterward, as each new instance of baby sends inter- mittent signals to the parent processes which must be handled by the parents immediately. A baby process will frequently dump core, requiring either or both parent processes to clean up after it. Despite the reams of available documentation on invoking and maintaining baby, most parent processes are overwhelmed. AUTHORS
From a man page by Joe Beck, <beck@cs.ualberta.ca>. BABY(1)