Re: several important questions

[Howard Chu <hyc@troy.la.platsol.com>]

   >  2) MiNT "kill process"
   >
   >     According to 3 books on Unix I've read, Control-D is the standard
   >     "kill process" command, but MiNT uses Control-C.  Any reason?
   >     Since Control-C was already reserved by GEM for Clipboard, it would
   >     make more sense to stick to the Unix standard, wouldn't it?
   >
   >The 3 books on Unix you read must have been written by CP/M experts.
   >The default interrupt character in Unix is the pound-sign ('#'). Normal
   >practice on BSD systems is to reassign it to Ctrl-C. Ctrl-D is reserved
   >for EOF, and has never been commonly used as the interrupt character.

  An example, quoted from "Rescued by Unix, p.24 (A.Hansen), Jamsa Press":

  "To log out, you can use the 'exit' command. [...] An alternative that 
  works on most systems is Ctrl-D. This key combination sends a code that
  stops a running program, such as your shell."

  I wasn't aware that CP/M has different shorcuts. This could explain 
  the oversight/mistake if any, though. :)

The reference to CP/M was a joke, meaning that the authors don't know shit
about Unix. The text is misleading and badly written. Indeed, they are
describing the use of Ctrl-D as an EOF character. The character only has this
special meaning when it is the first character in an input stream. I.e., it is
not a special interrupting character. If you type e.g. "ls^D" you are not
logged out; the EOF condition is not recognized in these cases.

The C shell has a built-in variable called ignoreeof; if this is set, then
EOF will not log you out. The sentence "An alternative that works on most
systems is Ctrl-D" was clearly written by a person who doesn't have even the
faintest clue of how the shell works or what Ctrl-D actually means.

Here's a brief summary - interrupt and quit characters are recognized by the
tty driver, and generate SIGINT and SIGQUIT i(respectively) in any attached
processes. If the attached processes do not explicitly set a signal handler
to catch these signals, the processes are killed. With SIGQUIT, the process
generates a core dump before it dies. These signals are generated
asynchronously, as soon as the tty driver receives the special characters.

The EOF character is also recognized by the tty driver, but it is synchronous
in its behavior; it will not have any effect until the running program tries
to read from the tty. Also, it has no special effect unless it is the first
character in the input buffer. When these conditions are met, the program that
reads will get 0 bytes returned, signifying that no more input is available to
be read. It is up to the program code to decide what to do at this point - most
Unix code is written in a filter style, and so will exit when this EOF
condition occurs. Other programs that are meant to be used interactively will
generally ignore this condition, and keep running until given an explicit QUIT
command. The C-shell can behave either way, depending on how you set ignoreeof.

An example of a program that does not recognize EOF is the BSD ftp client.
(Try it sometime - type Ctrl-D at the ftp prompt, you will just get another
prompt right away.) Personally I think the ftp client is broken in this
respect. You cannot use it in a normal pipeline because of this behavior;
unless you explicitly feed a quit command down the pipe, it will go into an
infinite loop when the EOF hits. Likewise if you start an ftp session, send
it into the background, and then logoff - the ftp session continues in the
background until the transfer finishes, and then the command input routine
goes into an infinite loop trying to read from the tty that you are no longer
connected to. Very annoying, and vivid proof that the Ctrl-D character has
no special ability to terminate a running program.
  -- Howard

PS: Sorry for the length. I just can't stand to see ignorant people publishing
their ignorance and profiting from it, as these so-called Unix experts do when
they sell their books.