Command-line shell

Related articles

From Wikipedia:

A Unix shell is a command-line interpreter or shell that provides a traditional user interface for the Unix operating system and for Unix-like systems. Users direct the operation of the computer by entering commands as text for a command line interpreter to execute or by creating text scripts of one or more such commands.

List of shells

Shells that are more or less POSIX compliant are listed under #POSIX compliant, while shells that have a different syntax are under #Alternative shells.

POSIX compliant

These shells can all be linked from /usr/bin/sh. When Bash, mkshAUR and zsh are invoked with the sh name, they automatically become more POSIX compliant.

  • Bash — Bash extends the Bourne shell with command-line history and completion, indexed and associative arrays, integer arithmetic, process substitution, here strings, regular expression matching and brace expansion.
https://www.gnu.org/software/bash/ || bash
  • Dash — Descendant of the NetBSD version of the Almquist SHell (ash). A fast POSIX-compliant shell that aims to be as small as possible.
http://gondor.apana.org.au/~herbert/dash/ || dash
  • KornShell (ksh) — The KornShell language is a complete, powerful, high-level programming language for writing applications, often more easily and quickly than with other high-level languages. This makes it especially suitable for prototyping. ksh has the best features of the Bourne shell and the C shell, plus many new features of its own. Thus ksh can do much to enhance your productivity and the quality of your work, both in interacting with the system, and in programming. ksh programs are easier to write, and are more concise and readable than programs written in a lower level language such as C.
http://www.kornshell.com || See the article.
  • Oil Shell (OSH) — Oil Shell is a Bash-compatible UNIX command-line shell. OSH can be run on most UNIX-like operating systems, including GNU/Linux. It is written in Python (v2.7), but ships with a native executable. The dialect of Bash recognized by OSH is called the OSH language.
https://www.oilshell.org || oil

      Alternative shells
      • C shell (tcsh) — Command language interpreter usable both as an interactive login shell and a shell script command processor. It includes a command-line editor, programmable word completion, spelling correction, a history mechanism, job control and a C-like syntax.
      https://www.tcsh.org || tcsh
      • Elvish — Elvish is a modern and expressive shell, that can carry internal structured values through pipelines. This feature makes possible avoiding a lot of complex text processing code. It features an expressive programming language, with features like exceptions, namespacing and anonymous functions. It also has a powerful readline which checks the syntax while typing, and syntax highlighting by default.
      https://elv.sh || elvish

                      Changing your default shell

                      After installing one of the above shells, you can execute that shell inside of your current shell, by just running its executable. If you want to be served that shell when you login however, you will need to change your default shell.

                      To list all installed shells, run:

                      $ chsh -l

                      And to set one as default for your user do:

                      $ chsh -s full-path-to-shell

                      If you are using systemd-homed, run:

                      $ homectl update --shell=full-path-to-shell user

                      where full-path-to-shell is the full path as given by chsh -l.

                      If you now log out and log in again, you will be greeted by the other shell.

                      Uninstalling shell

                      Change the default shell before removing the package of the shell.

                      Alternatively, modify the user database.

                      Use it for every user with zsh set as their login shell (including root if needed). When completed, the package can be removed.

                      Login shell

                      A login shell is an invocation mode, in which the shell reads files intended for one-time initialization, such as system-wide /etc/profile or the user's or other shell-specific file(s). These files set up the initial environment, which is inherited by all other processes started from the shell (including other non-login shells or graphical programs). Hence, they are read only once at the beginning of a session, which is, for example, when the user logs in to the console or via SSH, changes the user with sudo or su using the parameter, or when the user manually invokes a login shell (e.g. by ).

                      See #Configuration files and the links therein for an overview of the various initialization files. For more information about login shell, see also Difference between Login Shell and Non-Login Shell? and Why a "login" shell over a "non-login" shell? on Stackexchange.

                      Configuration files

                      To autostart programs in console or upon login, you can use shell startup files/directories. Read the documentation for your shell, or its ArchWiki article, e.g. Bash#Configuration files or Zsh#Startup/Shutdown files.

                      See also Wikipedia:Unix shell#Configuration files for a comparison of various configuration files of various shells.

                      /etc/profile

                      Upon login, all Bourne-compatible shells source /etc/profile, which in turn sources any readable files in : these scripts do not require an interpreter directive, nor do they need to be executable. They are used to set up an environment and define application-specific settings.

                      Standardisation

                      It is possible to make (some) shells configuration files follow the same naming convention, as well as supporting some common configuration between the shells.

                      See the article about this and the related repository. See also xsh.

                      Input and output

                      See also GregsWiki and I/O Redirection.

                      • Redirections truncate files before commands are executed: will therefore not work as expected. While some commands (sed for example) provide an option to edit files in-place, many do not. In such cases you can use the sponge(1) command from the package.
                      • Because cat is not built into the shell, on many occasions you may find it more convenient to use a redirection, for example in scripts, or if you care a lot about performance. In fact does the same as .
                      • POSIX-compliant shells support Here Documents:
                      • Shell pipelines operate on stdout by default. To operate on stderr(3) you can redirect stderr to stdout with or, for Bash 4, .
                      • Remember that many GNU core utilities accept files as arguments, so for example is replaceable with .
                      gollark: Well, you won't see with Macron, because it doesn't exist.
                      gollark: Your entry is Macron?
                      gollark: We've already completed phase π/2.
                      gollark: Just run your webserver in WASM, bee.
                      gollark: Idea: make it use a 4x4 grid.

                      See also
                      This article is issued from Archlinux. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.