fish is meant to be used for interactive shell tasks on a modern UNIX-like workstation. It is much more important for me to keep the code maintainable, readable and bug free than to support esoteric old hardware, software or wetware. As such, the program is often wildly inefficient in its use of memory and CPU cycles. On my system, fish uses a little less than half a megabyte of memory, a number that could be significantly reduced with a little effort. fish performs a lot of linear searches of things that could be done in logarithmic time, does not usually cache file system data or other search result, and uses the fork() call promiscuosly. None of these things matter because fish is still fast enough to be perceived as instantaneous on a semi-modern computer thanks to the miracles of copy-on-write, OS-level caching and Moores law, and it only uses a fraction of the memory used by most terminal emulators to display it. If this program was anything other than an amusing hobby for me, I would of course feel otherwise, but since my time is limited, this is the way it must be.This also means that I rely on terminfo, and on the terminal providing several capabilities which are not universal, but which should be supported by most terminal emulator.
A design goal in fish was not to include any code in the program which could be run in a separate executable. This excludes creating special builtins for such standard UNIX commands as echo, time, kill or printf, which are provided by many other shells, such as bash. There is simply no reason to provide a builtin version of i.e. echo, as it will simply confuse the user that the manual for echo does not match the actual behaviour. It also increases the severity of bugs, since crashes in one of these builtins may take the shell down with it. There are two drawbacks to this approach:
fish, so functions won't be expanded, etc.
The former, I don't care about since fish is fast enough for interactive needs, the latter is a problem which I don't feel is important enough to warrant including code which doesn't belong in fish.
fish regularly performs a large set of sanity checks to make sure it is in a sane state. If not, the program will terminate before it can do any harm.
Do not edit the file builtin_help.c, it is automatically generated.
fish is written for Doxygen. All header files are pretty heavily commented.Since it was desirable to use the same text files for producing the HTML documentation as for producing the internal help output, some rather ugly kludges had to be used for writing the documentation for the builtin commands.
The directory doc_src contains a file called doc.hdr, containing various general documentation for fish, and a large number of .txt files. Each txt file contains the documentation for one fish builtin. When creating the main doxygen documentation, all these files are concatenated into one file, called doc.h. When creating the internal documentation, each of the .txt files is converted to a .h file by supplying a doxygen header/footer. These headers are then converted into man style manuals, which in turn are converted to C code by a script called gen_hdr.sh. The resulting C-file, builtin_help.c, can then by linked into fish. This method is probably not the most robust, elegant or clever method for generating documentation. If someone has a suggestion of how to do i better, please notify me.
1.4.3-20050530