Shell package guidelines

From ArchWiki
Jump to navigation Jump to search
Arch package guidelines

32-bitCLRCMakeCrossDKMSEclipseElectronFontFree PascalGNOMEGoHaskellJavaKDEKernelLispMesonMinGWNode.jsNonfreeOCamlPerlPHPPythonRRubyRustShellVCSWebWine


For users to change shells, the shell must appear in /etc/shells. Most shell packages have install scripts like below:

post_install() {
    grep -Fqx /bin/shellname /etc/shells || echo /bin/shellname >>/etc/shells
    grep -Fqx /usr/bin/shellname /etc/shells || echo /usr/bin/shellname >>/etc/shells

post_upgrade() {

post_remove() {
    sed -i -r '/^(\/usr)?\/bin\/shellname$/d' etc/shells

Shell completions

Most shells provide a built in set of completions for a few common commands while also scanning at least one system directory for functions that may be supplied by other packages. The following table is a summary of where packages may place completion files and what the files should be named.

Shell Directory File
Bash /usr/share/bash-completion/completions binary_name
fish /usr/share/fish/vendor_completions.d
Zsh /usr/share/zsh/site-functions _binary_name

Other shells:

  • Elvish provides some default completions, but does not have a system-wide directory where completions can be provided yet[1]. For packages that generate Elvish shell completion functions, one solution would be to package them /usr/share/elvish/completions/binary_name.elv and use a post_install() function to print a tip for users to symlink it to their $XDG_CONFIG_HOME/elvish/lib/ directory.
Tip: As a general rule, packages should have neither depends nor optdepends on shells. Just because they happen to supply completions for them does not imply a package dependency relationship any way. The exception is packages that do not supply their own completions; the completions do not exist in the default shell package, but they are provided by the supplemental collection packages bash-completion or zsh-completions. When completion files exist in these packages, add them to optdepends.