thumb|Screen shot of a terminal showing various [[Bash (Unix shell)|Bash commands and resulting output.]]

This article catalogs comparable aspects of notable operating system shells.

General characteristics

{| class="wikitable sortable sticky-header sort-under" style="width: auto; text-align: center; font-size: smaller;"

|-

! Shell

!

!

!

!

!

!

! License

!

!

! Mouse support

! Unicode<br>support

! ISO 8601<br>support

!

! Stream redirection

! Configurability<!-- yes/no/which, persistent via config files, registry, temporary via env vars, startup scripts - might require a table of its own -->

! Startup/shutdown<br/>scripts

!

! Logging<!-- - might require a table of its own -->

!

|-

!Thompson shell

|UNIX

|sh

|1971

|

|UNIX

|UNIX

|

|

|Text-based CLI

|

|

|

|

|

|

|

|

|

|

|-

!Bourne shell 1977 version

|7th Ed. UNIX

|sh

|1977

|

|7th Ed. UNIX

|7th Ed. UNIX,

|

|

|Text-based CLI

|

|

|

|

|<br>

|<br>

|<br>

|<br>

|

|

|-

!Bourne shell current version

|Various UNIX

|sh

|1977

|

|SunOS-5.x, FreeBSD

|SunOS-5.x

|

|

|Text-based CLI

|

|

|

|

|<br>

|<br>

|<br>

|<br>

|

|

|-

!POSIX shell

|POSIX

|sh

|1992

|

|

|POSIX

|

|

|Text-based CLI

|

|<br>

|

|

|<br>

|<br>

|

|

| ( or to follow symlinks)

|-

!ash

|?

|?

|

|

|

|

|-

!CCP

|

|

|

|

|

|

|-

!COMMAND.COM

|

|

|

|<br>

|

|

|-

!OS/2 CMD.EXE

|

|

|

|<br>

| (only in command)

|

|-

!Windows CMD.EXE

| (only through and )

|

|

|<br>

| (only in command)

| (via command, or, where available, indirectly via subdir option)

|-

!4DOS

| (through variable functions , extended environment variable processing, various string commands and and )

|

|

|<br>

| (via attribute and description options and size, time, date, and file exclusion ranges)

| (via command, or indirectly via command or, where available, subdir option)

|-

!4OS2

|?

|

|

|?

|?

|?

|-

!TCC (formerly 4NT)

| (through variable functions , extended environment variable processing, various string commands and and )

|

|

|<br>

| (via attribute and description options and size, time, date, owner, and file exclusion ranges)

| (via command, or indirectly via command or, where available, subdir option)

|-

!PowerShell

|<br>

|

|<br>

|<br>

|?

|?

|-

!rc

|?

|?

|<br>

|

|

|

|-

!BeanShell

|?

|?

|

|?

|?

|?

|-

!VMS DCL

|

|

|

|

|

| (via )

|-

!fish

|<br>

|

|<br>

|<br>

|

| ()

|}

Inter-process communication

{| class="wikitable sortable" style="width: auto; text-align: center; font-size: smaller;"

|-

!Shell

!Pipes

!Command substitution

!Process substitution

!Subshells

!TCP/UDP connections as streams

!Keystroke stacking

|-

!Bourne shell

|

|

|

|

|

|

|-

!POSIX shell

|

|

|

|

|

|

|-

!4OS2

|

|?

|?

|?

|

| (via )

|-

!TCC (formerly 4NT)

|

|<br>

|?

| (via and )

| (via , , , , , and , client only)

| (via )

|-

!PowerShell

|

|

|

|

|

|?

|-

!rc

|

|

|<br>

|

|

|?

|-

!BeanShell

|

|?

|?

|?

|

|?

|-

!VMS DCL

|

|

|

|<br>

|<br>

|

|-

!fish

|

| ()

|

|

|

|

|?

|

|

|

|-

!POSIX shell

|

|

|-

!csh

|

|

|

|-

!ash

|

| (only under DR-DOS, if files are password-protected for read and/or execute permission)

|

|

|-

!OS/2 CMD.EXE

|

|

|

|

|

|-

!Windows CMD.EXE

|

|

|

|

|

|-

!4DOS

| (via or )

| (only under DR-DOS via syntax)

|

|

|

|

|-

!rc

|

The shells bash, zsh and PowerShell offer this as a specific feature. Shells which do not offer this as a specific feature may still be able to turn off echoing through some other means. Shells executing on a Unix/Linux operating system can use the external command to switch off/on echoing of input characters. In addition to not echoing back the characters, PowerShell's option also encrypts the input character-by-character during the input process, ensuring that the string is never represented unencrypted in memory where it could be compromised through memory dumps, scanning, transcription etc.

Execute permission

Some operating systems define an execute permission which can be granted to users/groups for a file when the file system itself supports it.

On Unix systems, the execute permission controls access to invoking the file as a program, and applies both to executables and scripts.

As the permission is enforced in the program loader, no obligation is needed from the invoking program, nor the invoked program, in enforcing the execute permission this also goes for shells and other interpreter programs.

The behaviour is mandated by the POSIX C library that is used for interfacing with the kernel. POSIX specifies that the <code>exec</code> family of functions shall fail with EACCESS (permission denied) if the file denies execution permission (see ).

The execute permission only applies when the script is run directly. If a script is invoked as an argument to the interpreting shell, it will be executed regardless of whether the user holds the execute permission for that script.

Although Windows also specifies an execute permission, none of the Windows-specific shells block script execution if the permission has not been granted.

Restricted shell subset

Several shells can be started or be configured to start in a mode where only a limited set of commands and actions is available to the user. While not a security boundary (the command accessing a resource is blocked rather than the resource) this is nevertheless typically used to restrict users' actions before logging in.

A restricted mode was evaluated for the POSIX specification for shells, but not included. However, most of the Linux/Unix shells support such a mode where several of the built-in commands are disabled and only external commands from a certain directory can be invoked.

PowerShell supports restricted modes through session configuration files or session configurations. A session configuration file can define visible (available) cmdlets, aliases, functions, path providers and more.

Safe data subset

Scripts that invoke other scripts can be a security risk as they can potentially execute foreign code in the context of the user who launched the initial script. Scripts will usually be designed to exclusively include scripts from known safe locations; but in some instances, e.g. when offering the user a way to configure the environment or loading localized messages, the script may need to include other scripts/files. One way to address this risk is for the shell to offer a safe subset of commands which can be executed by an included script.

Notes

References