Design document

Overview

This is a description of the design principles that have been used to design fish. The fish design has three high level goals. These are:

1. Everything that can be done in other shell languages should be possible to do in fish, though fish may rely on external commands in doing so.
2. Fish should be user friendly, but not at the expense of expressiveness. Most tradeoffs between power and ease of use can be avoided with careful design.
3. Whenever possible without breaking the above goals, fish should follow the Posix syntax.

To achive these high-level goals, the fish design relies on a number of more specific design principles. These are presented below, together with a rationale and a few examples for each.

The law of orthogonality

The shell language should have a small set of orthogonal features. Any situation where two features are related but not identical, one of them should be removed, and the other should be made powerful and general enough to handle all common use cases of either feature.

Rationale:

Related features make the language larger, which makes it harder to learn. It also increases the size of the sourcecode, making the program harder to maintain and update.

Examples:

• Here documents are too similar to using echo inside of a pipeline.
• Subshells, command substitution and process substitution are strongly related. fish only supports command substitution, the others can be achived either using a block or the psub shellscript function.
• Having both aliases and functions is confusing, especially since both of them have limitations and problems. fish functions have none of the drawbacks of either syntax.
• The many Posix quoting styles are silly, especially $''.

The law of minimalism

The shell should only contain features that cannot be implemented in a reasonable way outside of the shell. A large performance decrease, as well as some program complexity increase is acceptable in order to improve separation.

Rationale:

A modular project is easier to maintain since smaller programs are far easier to understand than larger ones. A modular project is also more future proof since the modules can be individually replaced. Modularity also decreases the severity of bugs, since there is good hope that a bug, even a serious one, in one module, does not take the whole system down.

Examples:

• Builtin commands should only be created when it cannot be avoided. echo, kill, printf and time are among the commands that fish does not implement internally since they can be provided as external commands. Several other commands that are commonly implemented as builtins and can not be implemented as external commands, including type, vared, pushd and popd are implemented as shellscript functions in fish.
• Mathematical calculations, regex matching, generating lists of numbers and many other funtions can easily be done in external programs. They should not be supported internally by the shell.

The law of minimalism does not imply that a large feature set is bad. So long as a feature is not part of the shell itself, but a separate command or at least a shellscript function, bloat is fine.

Configurability is the root of all evil

Every configuration option in a program is a place where the program is too stupid to figure out for itself what the user really wants, and should be considered a failiure of both the program and the programmer who implemented it.

Rationale:

Different configuration options are a nightmare to maintain, since the number of potential bugs caused by specific configuration combinations quickly becomes an issue. Configuration options often imply assumptions about the code which change when reimplementing the code, causing issues with backwards compatibility. But mostly, configuration options should be avoided since they simply should not exist, as the program should be smart enough to do what is best, or at least a good enough approximation of it.

Examples:

• Fish allows the user to set various syntax highlighting colors. This is needed because fish does not know what colors the terminal uses by default, which might make some things unreadable. The proper solution would be for text color preferences to be defined centrally by the user for all programs, and for the terminal emulator to send these color properties to fish.
• Fish does not allow you to set the history filename, the number of history entries, different language substyles or any number of other common shell configuration options.

A special note on the evils of configurability is the long list of very useful features found in some shells, that are not turned on by default. Both zsh and bash support command specific completions, but no such completions are shipped with bash by default, and they are turned of by default in zsh. Other features that zsh support that are disabled by default include tab-completion of strings containing wildcards, a sane completion pager and a history file.

The law of user focus

When designing a program, one should first think about how to make a intuitive and powerful program. Implementation issues f"> Configurabill>

type returns a zero exit status if the specified command was found, otherwise the exit status is one.

Example

type fg outputs the string 'fg is a shell builtin'.

Back to index.

---

ulimit - set or get the shells resource usage limits

Synopsis

ulimit [OPTIONS] [LIMIT]

Description

The ulimit builtin is used to set the resource usage limits of the shell and any processes spawned by it. If a new limit value is omitted, the current value of the limit of the resource is printed.

Use one of the following switches to specify which resource limit to set or report:

• -c or --core-size The maximum size of core files created. By setting this limit to zero, core dumps can be disabled.
• -d or --data-size The maximum size of a process's data segment
• -f or --file-size The maximum size of files created by the shell
• -l or --lock-size The maximum size that may be locked into memory
• -m or --resident-set-size The maximum resident set size
• -n or --file-descriptor-count The maximum number of open file descriptors (most systems do not allow this value to be set)
• -s or --stack-size The maximum stack size
• -t or --cpu-time The maximum amount of cpu time in seconds
• -u or --process-count The maximum number of processes available to a single user
• -v or --virtual-memory-size The maximum amount of virtual memory available to the shell. If supported by OS.

Note that not all these limits are available in all operating systems.

The value of limit can be a number in the unit specified for the resource or one of the special values hard, soft, or unlimited, which stand for the current hard limit, the current soft limit, and no limit, respectively.

If limit is given, it is the new value of the specified resource. If no option is given, then -f is assumed. Values are in kilobytes, except for -t, which is in seconds and -n and -u, which are unscaled values. The return status is 0 unless an invalid option or argument is supplied, or an error occurs while setting a new limit.

ulimit also accepts the following switches that determine what type of limit to set:

• -H or --hard Set hard resource limit
• -S or --soft Set soft resource limit

A hard limit can only be decreased, once it is set it can not be increased; a soft limit may be increased up to the value of the hard limit. If neither -H nor -S is specified, both the soft and hard limits are updated when assigning a n