The problem was that system calls got restarted after a signal,
instead of returning EINTR. Thus the read builtin, had no way to
know that a signal occured that could change the course of execution.
Since the code has sprinkled checks for EINTR all over the place,
it is supposed to work properly with non restartable syscalls.
The fix is to use siginterrupt(signo, 1), before setting a signal
handler, to make sure that system calls don't get restarted.
Rewrite man page in mandoc format rather than nasty man format.
Fix a ton of parsing errors, and generate proper .Xr's.
document all known environment variables.
suggest ksh rather than bash.
The last two fix PR #1966. Wheee!
Somebody with access to the POSIX spec needs to go in here, and document
our adherence, or lack thereof.
from Brian C. Grayson <bgrayson@marvin.ece.utexas.edu> in [bin/3932]
* don't depend on a fallthrough in one case; explicitly return like
all other cases.
* include "stat_flags.h" instead of "ls.h" and "extern.h"; other
programs use this file and don't need the other cruft.
We need not wait for a while any longer after pressing ESC or ^D.
Problem description:
If a user types characters during performing completion (ESC)
or listings (^D), the chars are inserted at weird position of
the command line.
This makes the command line unusable and irritates the user.
I noticed this on 386BSD(98), probably six years ago.
This change fixes the bug by implementing salvage of the characters.
The salvaged chars are added at the end of the command line.
An extra ioctl(FIONREAD) is required to work-around a glitch on
kernel tty driver.
even if mkdir(2) failed. At best this caused two (different)
error messages to be printed. At worst, it changed the mode of
an existing file/directory.
