Here I will collect features and strangenesses in Unix and Unix-like systems which I suppose to be explicit bugs and flaws, not appeared due to principal design, but which could probably be made better.
I shall tell immediately a disclaimer that I still suppose Unix world is best for me now ("all XXX sucks but this one sucks less"). But moreso itʼs pity to see the situation which can be described, after a Russian poet, "Youʼre richer than others; youʼre poorer than yourself".
This article is subject for often changes, including deep restructuring and refactoring. If you want to perceive it seriously, check for updates regularly.
Non-blocking operation mode is set on ofile object (I use early Unix term — ofile is instance which is created on open() but all descriptiors after dup() or fork() points to the same ofile object; its flags are changed using fcntl with F_SETFL; two separate open() return different ofile objects). This leads to a set of side effects when this ofile object is used simultaneously or sequentially by different processes. For example, a process sets nonblocking mode on terminal, then dies on signal; a parent process shall restore terminal settings, including ofile flags, before using it again. This is too often forgotten by programmers.
Generally say, I suppose the most correct approach is to specify non-blocking operation behavior in the operation directly. The proof is that non-blocking mode radically changes way to write the code; the same code can be too seldom used for both blocking and non-blocking operations. This is implemented in some flavors; e.g. Linux recv() and send() accept flag `MSG_DONTWAIT' which prevents this call from blocking. But this is too rare and non-portable.
But it shall be explicitly said that even current problematic interface is much more simple and usable for sequential objects (sockets, pipes, serial ports, etc.) than e.g. analog in WinAPI which requires constructing of signaled event and/or completion routine, and which is more appropriate for explicit AIO operation (as needed for disk files and raw disks).
There is no standard way for a process to iterate own file descriptors. In conjugation with dubbing the whole descriptor set on fork() and passing to new program via exec() (excluding some explicitly removed from this), this leads to a situation when process canʼt know what does it carry in itself.
Some programs try to work around this using explicit closing cycle (from 3 to maximal supposed value, got from getrlimit()). Good examples are sendmail and uucico. But this makes their start more slow.
I supposethe best variant how to fix this is to have variant to call fcntl() with constant named similarly to F_NEXTFD as second argument. It shall return the smallest open descriptor larger than first argument, or -1 otherwise.
Modern FreeBSD uses special call to close all descriptors with numbers greater than specified one. This isnʼt finally correct but closes the nearest issue I described.
Open() and similar operations which create new descriptor shall return the smallest free descriptor (this is hardcoded in Posix). First, this interferes with usage of descriptors 0-2 for special purposes (stdin, stdout, stderr) hardcoded in standard library (e.g. heap-management functions can write their warnings to stderr). To prevent possible side effects, a process shall keep descriptors 0-2 open and safe for any write or read (the simplest way is to open /dev/null on them). The most dangerous situation appear in case of multithreaded process. According to Posix, if close() fails, it is unspecified whether descriptor continues to exist, or it was removed from the process. So, if close() failed, the thread canʼt event check reliably whether the descriptor was closed, because other thread can be as fast as to reuse the descriptor for a new opened object. And, itʼs impossible in multithreaded process to guarantee safety of operation which changes any predefined descriptor (including 0-2); even dup2() isnʼt defined as safe for this operations because it can fail with closing of old file.
So, in current implementation, any operation with fixed descriptors (including standard 0-2) shall be made when all other threads are stopped or donʼt exist. For most programs, this is limited to startup time.
Comparing with Windows implementation of separate marking of file handles (via SetStdHandle()), I think Windows variant is much better. Also it hasnʼt problem with undefined result of close() in case of error return.
Itʼs common now to add options to file descriptor creating calls (open(), accept(), etc.) to set FD_CLOEXEC atomically during creating. The goal of this is to exclude race condition between creating in one thread and fork+exec in another thread.
Instead, the proper solution (but impossible now due to legacy) is to set this flag by default without any extra flag. If an agent needs to pass some descriptors through exec(), it shall drop FD_CLOEXEC explicitly. This would also solve problem with unknown descriptor set passed through exec() (see above).
There is a common method to feed a program with output of another program using unnamed unidirectional pipe, usually created by pipe() syscall. It is often presented as most distinctive example of Unix approach of inter-process communication.
Two problems of this approach exist:
1. If a pipe writer fails, and protocol doesnʼt suppose explicit mark of successful termination, the reader of this pipe canʼt distinguish whether the input data is complete or not. If the pipe reader is final action in script, which result check canʼt affect anything (e.g. it sent mail), script canʼt prevent action on incomplete results.
2. There is no good way to get status of all commands in pipe. Comp.unix.shell FAQ lists some methods for it, but portable way is too cumbersome and expensive.
So, now a script which wants to perform all actions with pipelines reliably shall 1) check result of all intermediate commands in quite cumbersome way, 2) avoid using of pipes before final actions and use temporary files instead (with littering temporary storage and using extra disk operations).
I wish to see here a way to specify either exit status of write process passed by kernel along the pipe, or possibility to send some out-of-band mark which can be used to signal correct finish of passing data by pipe writer. First variant is badly compatible with multiple writers, second variant requires changing of all current code base.:(
For multiple exit status, itʼs reasonable to standardize getting of the whole pipe exit status by calling shell, including "fast" check whether any non-zero status has been got.
Select(), poll() and others allow to specify descriptor which isnʼt allowed by design to be "readable" or "writable" in usual way, itʼs for disk file (or raw disk) descriptor. Any read or write operation on such descriptor shall include additional information, as offset and length. AIO syscall set reflects this properly, unlike select().
This is minor issue, but lack of proper documentation often confuses non-experienced programmer. Better variant is to treat disk file (raw disk) descriptor as invalid for selecting. Or at least note this in documentation carefully.
If a program is started using fork()+exec(), it inherits a wide and unpredictable bunch of characteristics from its parent, including, but not limited to:
The main problem is that each system can expand this list to its own local additions. One canʼt predict result of execution with uncontrolled legacy. This generally isnʼt problem for usual programs, but is huge problem for credentials gateways (suid and sgid executables). More and more security holes are stably found in them.
The only safe approach is to improve maximal limiting of actions performed in credentials gateways. E.g. mail submission program (as `sendmail -bm') shall put file with the letter to incoming directory (group-writable; submission program has only sgid to needed group) and signal corresponding daemon to start processing. Password changer (`passwd') in Owl Linux TCB have only sgid to separate group which allows to maintain userʼs shadow line.
There is no reliable and portable way to check whether a process is alive for another process which isnʼt parent of first one, knowing only its pid or without explicit action from the first process. Also, parentʼs way to get this is destructive: if child is terminated, waitpid() and wait4() gathers rusage immediately. Multithreaded process needs special handler in a thread to send child status to threads which wait for it, and race condition has place here: child can terminate before parent registers child in supervisor thread.
Two methods can be used to fix this. First one requires getting of an unique process identificator (e.g. pid + start time up to microseconds) and atomic actions against it (e.g. variant of kill()). Second one requires getting a file descriptor which internally points to another process, and allowing a bunch of operations against it.
Serial port interface isnʼt adopted to standard RS-232 implementations (including 8250/16550/etc.):
Most Unixes follow now principal design of Mach VM. Its main idea can be simply expressed as "RAM is disk cache" and covers almost all use cases. Program "text" is cache of needed pages of main binary file and library files (with small changed part of cross-library links). Changeable data is cache of swap area (this part really is exception due to implementation details, but formally it doesnʼt jut out). Among with techniques as copy-on-write, zero-fill-on-demand, lazy commit, this allows to reduce memory consumption (in some cases, in order of magnitude) and time consumption for operations as fork.
Reverse side of this design is inability to have exact estimation of consumed memory and to predict its exhaustion.
Example 1. System has 100M of virtual memory; the appication process occupied 50M. It allocates yet another 100M... and obtains them successfully (due to "lazy commit"). Then it starts to write into this new memory... when a page is written first, it is committed. When summary size of committed page exhausts 50M, system canʼt allocate virtual memory for new page, and, because it canʼt simply return failure code, it kills process (implementations vary in details of this killing, but general concept is common for all flavors).
Example 2. System has 100M of virtual memory; the appication process occupied 80M. It forks; after fork, two processes occupy the same 80M (with small reducing of page catalog for the new process). Then, processes work separately, and each modifies pages which was shared between them; after this modify, page dubs and separate copies are created for each process. When summary size of all personal pages and all shared pages reach system limit (100M), the exhaustion occurs and some process is killed.
There are many implementations of another approaches to memory handling, but generally all they fall into requiring virtual memory (i.e. expanding swap area) according to uncommitted requested space and shared pages, counted for each process separately.
Shell uses wildcard mechanisms for easy specifying of group of
names using mask. E.g. `a*' matches all files (directories, etc.)
which names start with `a'.
There is wildcard expression `*' to match all names except ones
starting with `.'.
There is no expression to match all names including ones starting
with `.' (yes, itʼs usual need).
There is no expression to match all names including ones starting
with `.' but excluding `.' and `..' (yes, itʼs yet another usual need
and even more important than previous one).
Generally, the globbing theme needs separate description. Itʼs known that using globbing in shell simplifies writing programs which simply iterates list of their arguments. But, there are no strong disadvantages against having the same globbing implemented in standard library and called from each program in quite simple way (if the program supposes a globbing can be used here, it can call library function for this). This also has advantage because simple list canʼt carry per-file marks. E.g. a program determine file type by default using its suffix; if you want to process all files in directory as mp3 files, you canʼt use `-mode=mp3 *', but instead shall provide "inserting" into forced mode and "exiting" from it: `-force-mode=mp3 * -exit-force-mode'. If program processes wildcard by itself, it can use more simple approach and treat expansion results internally.
Another problem is that shell by default passed wildcard expression directly, if canʼt find a name which conforms to it. As a result, `touch *' in empty directory creates file named `*'. This is definitely another effect than supposed by command issuer.
Modern shells try to deal with these problems. For example, bash supports:
All these options fix only part of problem. For example, if one want to match either a* or b*, no shell support this. The closest one is bash with its possibility to match {a*,b*} using "brace expansion" as two expressions, but failglob option leads to fail on the whole expression even if there is match for other part. Seems this is problem of concrete implementation, but standard variant doesnʼt allow even such incomplete variant.
Bash option `dotglob' makes `*' at begin of expression matching also files starting with `.'. I suppose itʼs much simpler to use `**' for this.
Shell has standard option `-e' which causes it to fail script when a command which result is unchecked in this script fails in any way (has non-zero exit status). It isnʼt turned on by default.
I treat its "default off" status as flaw because itʼs too often for non-experienced coder to ignore problems reported by script contents.
This is detailedly described above, in kernel interface section.
$Id$