Talk:Comparison of command shells/Archive 1

Pointless Article

This is a pointless article. Shouldn't we delete it? Or else find a set of comparisons that doesn't create a table saying Bash:Yes, cmd.exe:no. —The preceding unsigned comment was added by 193.91.90.242 (talk • contribs) 2005-03-12T05:22:44 – Please sign your posts!

After reading this talk page, I think that the previous comment is outdated and can be removed. Someone needs to go through here and fix some of the other outdated comments. --Whiteknox 14:09, 25 August 2006 (UTC)

Commented out old comment —The preceding unsigned comment was added by Stevage (talk • contribs) 2006-11-15T17:51:46 – Please sign your posts!

bash vs cmd is pointless

i agree: this comparison is pointless. ksh vs zsh vs bash vs whatsoever would be more useful. —The preceding unsigned comment was added by 213.235.241.194 (talk • contribs) 2005-06-08T10:20:08 – Please sign your posts!

no it's useful —The preceding unsigned comment was added by 83.171.212.51 (talk • contribs) 2005-06-14T23:10:01 – Please sign your posts!

It can be made useful. As is, it is not. But let's see.

First, there is a strong legacy of Unix shells, both csh-derived (csh, tcsh etc) and sh-derived (sh, bash, ksh etc) which are compared in several Computer Science books and textbooks. Second, there are Microsoft shells such as command.com from DOS, cmd.com from NT and its family, the recently developed msh (Monad) etc, and these can be compared too. The latter comparison can (and should) include Unix shells ported to MS Windows.

A good comparison should include both a discussion of the technical capabilities and a summary review of user experiences.

This will make the comparison useful and interesting. Can be a good exercise for a freshman-to-junior level computer science student. Cema 06:39, 25 February 2006 (UTC)

The comparison is still pointless, because it doesn't give any indication of the relative power and ease-of-use of the languages. Not to mention that it's omitting wsh (VBscript and Jscript, theoretically others), osascript (AppleScript, plus others, but nobody uses them), zsh, and tcsh.

• Bash, zsh, etc. are full scripting languages, perfectly designed for interacting with the shell, but with weird and arcane syntax. (Pretty much the same goes for csh derivatives.)
• Windows Scripting Host and osascript provide full scripting langauges with familiar syntax, but weird limitations on interactions with the shell (getting argv or pwd, running commands or other scripts, etc.).
• Windows Power Shell (or whatever it's called this week) is a full scripting language designed explicitly for interaction with the shell, but new, and often disturbingly different from what anyone is used to. (The same goes for tclsh, that experimental python-based shell-scripting language I can't remember the name of, and every other radical new shell design, almost by definition.)
• Cmd is a heavily limited language that, despite major improvements from its DOS ancestry, is still barely usable for all but the simplest tasks.

Or, put another way: You can write a web server in bash, but you don't want to. You can pretty easily write a web server in VBscript, but it's hard to pipe the output of grep to less. You can easily write a web server in Monad--well, actually, you can't, and neither can anyone else, but once people really learn the language they should be able to, and it should be easy. You can't write a web server in cmd. Falcotron 01:57, 8 July 2006 (UTC)

Job control

Is this correct to have "no" under cmd.exe? The "AT" command schedules jobs for NT-based OSes. zoney ♣ talk 12:09, 9 November 2005 (UTC)

I'm changing this to "yes" - as one can indeed control jobs on NT-based Windows via the "at" command (the command appears in the "help" list at the console). zoney ♣ talk 15:21, 15 November 2005 (UTC)

Ah - furthermore, there's a more complicated task scheduling tool in the cmd shell - SCHTASKS, which supersedes AT. Type "schtasks /?" at the command prompt. zoney ♣ talk 12:42, 16 November 2005 (UTC)

I'm changing this back, because that's not even close to what job control means. Job control means being able to control background processes from the shell. See the jobs, bc, and fg commands in sh-related shells. To the best of my knowledge, cmd.exe has no such thing. Being able to schedule tasks to run in the future is completely different, and is not part of the shell. Falcotron 01:20, 8 July 2006 (UTC)

bc is an executable that can be run from the command shell. Did you mean bg? When you want command-line job control in Windows, you might use NET START, NET PAUSE, NET STOP. If you wanted to stop a process that was not running as a service, you might use TSKILL. Are these commands part of the standard command shell? It depends a bit on what you mean. Fortunately, no-one reading this would seriously think that the NT command shell didn't support a Job Control Language. Would they? 203.206.162.148 (talk) 08:53, 9 June 2009 (UTC)

This is a comparison of command shells and their built-in features. External 3rd party executables and commands should not be included, especially when they are not necessarily installed as well such as TSKILL etc. This is a good explanation of what is meant here: Job control (Unix). Ghettoblaster (talk) 20:04, 9 June 2009 (UTC)

That is a fair position: although I'm not sure it's useful to come here and read that the NT shell has no job control, I'm sure no one who comes here believes it anyway. I see only two problems:

(1) C shell and Bourne shell. (When I was a boy) the C shell and the Bourne shell didn't have built in commands fg and bg and jobs. Has that been changed? Should C shell and Bourne shell be the same as CMD shell?

(2)Python, (I currently use Python for job control). The Python shell does not have job control built in, but you can load modules that come with the shell in order to do job control. Python should be the same a CMD, which ever way that should be.203.206.162.148 (talk) 06:25, 2 February 2010 (UTC)

Subshells

I'm also changing this to "yes" for cmd.exe - as you can indeed run nested instances of "cmd.exe" inside a cmd.exe console. zoney ♣ talk 15:25, 15 November 2005 (UTC)

Yes, you can, but this is mostly useless. In *nix shells, you can spawn a subshell and use its output directly within a command, with the backtick. For example, "grep f.*o `ls`" will run grep on the output of ls. There is no way to do this with cmd. And sh can also assign the return code to a variable; cmd can only match on the most recent return code with its ERRORLEVEL stuff. Falcotron 01:57, 8 July 2006 (UTC)

Not sure what you mean, but cmd.exe does have a form of backquoting, the most useless implementation ever conceived (probably), but still, it's there. E.g. [code]for /f "usebackq delims=" %i in (`dir`) do @echo %i[/code]. In this command each line from "dir" (you can pick out individual fields if you want) is passed as argument to "echo". Alfps 11:06, 8 July 2006 (UTC)

I didn't realize you could do that. (I've tried very hard to avoid being a DOS/.bat/.cmd expert....) Does the backtick spawn a new instance of cmd.exe (so you can do `foo 2>&1` or however err->out redirects work in DOS)? Either way, it might be worth splitting the line on subshells into three lines: subshells (yes), subshell output substitution/backtick (limited?), and subshell return value substitution (no, but ERRORLEVEL can substitute sometimes). Falcotron 19:53, 11 July 2006 (UTC)

Not only does cmd.exe have (granted rather harrowing) facilities for using the output of another command, but it has always been possible (even with command.com under MS-DOS) to pipe the output of command.com to another command. Also, cmd.exe (unlike command.com) accepts an exit code as an argument to the exit command.
—überRegenbogen (talk) 01:54, 9 April 2009 (UTC),.

In command.com (shown as no sub-shells), you run a sub_shell in order to get an independant environment. Since the communication with the sub-shell is almost non-existant, you give the sub-shell a batch file to run, and you read the output from a disk file. It's been decades since I've done that: I'd change it if I could be bothered looking for a URL with an example, but I probably won't. —Preceding unsigned comment added by 203.206.162.148 (talk) 06:34, 2 February 2010 (UTC)

Subroutines

Does the "Call" command available in cmd.exe not fit into this category? zoney ♣ talk 12:44, 16 November 2005 (UTC)

No, it doesn't. The "call" command runs one batch file from within another; it doesn't call a function defined in the shell. In bash, you can define a function in a shell script and then call it from within the same script. Or define it in your bashrc or profile and then call it from one-liners you type on the command line. Or define it in a helper file and then call it from scripts that source your helper file. You can't do this in cmd. Falcotron 01:57, 8 July 2006 (UTC)

The "call" command can indeed run a subroutine defined in a batch file, and works in tandem with the "exit" command. It can not, however, call a function, since there's no support for defining functions. Subroutines in [cmd.exe] batch files work a lot like early Basic subroutines; a label is a subroutine if used as a subroutine, there's no special syntax to define a subroutine. Given Bill Gates' early work on Basic this is perhaps not surprising. Other Basic-inspiration is e.g. the "rem" command for comments. Since I'm not an experienced Wikipedia contributor I don't think it would be right for me to check the current text and perhaps correct it. But I hope this information can help. Alfps 11:00, 8 July 2006 (UTC)

Example:

@echo off
echo.Starting...
setlocal

for %%x in (alfa, beta, gamma) do call :writeline %%x
goto :finished

rem Subroutine 'writeline', arg: text to write
:writeline
echo.%*
exit /b

:finished
endlocal
echo.Finished

Alfps 15:00, 8 July 2006 (UTC)

Just in case you didn't know, DR-DOS' COMMAND.COM and 4DOS both support GOSUB, and even normal MS-DOS and compatibles can simulate such with .BATs CALLing themselves with user-specified parameters which are tested for matches (see http://student.vub.ac.be/~dvandeun/batcoll.all under Procedure calls).
Armslurp 02:44, 27 April 2007 (UTC)

Find and replace on variables in cmd.exe

This also was incorrect. Cmd.exe allows find and replace on variables, through use of the set command. Type "set /?" at the prompt. Feedback is as follows:

Environment variable substitution has been enhanced as follows:

    %PATH:str1=str2%

would expand the PATH environment variable, substituting each occurrence
of "str1" in the expanded result with "str2".  "str2" can be the empty
string to effectively delete all occurrences of "str1" from the expanded
output.  "str1" can begin with an asterisk, in which case it will match
everything from the beginning of the expanded output to the first
occurrence of the remaining portion of str1.

May also specify substrings for an expansion.

    %PATH:~10,5%

would expand the PATH environment variable, and then use only the 5
characters that begin at the 11th (offset 10) character of the expanded
result.  If the length is not specified, then it defaults to the
remainder of the variable value.  If either number (offset or length) is
negative, then the number used is the length of the environment variable
value added to the offset or length specified.

    %PATH:~-10%

would extract the last 10 characters of the PATH variable.

    %PATH:~0,-2%

would extract all but the last 2 characters of the PATH variable.

zoney ♣ talk 12:54, 17 November 2005 (UTC)

irrelevant features compared

cmd.exe greatest drawback is lack of general quoting (it has an escape character, the caret, and I've corrected that in the table). The second greatest drawback is lack of a standard set of small commands (e.g. something like 'cat' is missing, the built in 'type' command translates text). On the features listed it compares well, but that impression is extremely misleading. —The preceding unsigned comment was added by Alfps (talk • contribs) 2006-07-07T02:45:09 – Please sign your posts!

I added quoting as a row. However, I still agree that this is mostly useless, for the reasons I mentioned above. Anyway, now the chart is more accurate, and more complete; if people want to expand it from here, go ahead, but I'd rather see it gone. Falcotron 01:57, 8 July 2006 (UTC)

Python and Ruby Shells?

Since I'm not sure what the point of this page is in the first place, I'm not sure what belongs here. But Python and Ruby interactive environments are not the same thing as shells. We might as well throw in the Smalltalk environment. This is getting ridiculous.

Can we also add clojure, scheme, ghci, wish, twisted manhole, and this thing on my hard drive that I've been meaning to push to github? — Preceding unsigned comment added by 97.120.76.224 (talk) 04:30, 16 September 2011 (UTC)

I won't add a VfD for the page, because of the arguments above that this page might become valuable if left long enough to grow into whatever it's supposed to become--but I will say that it doesn't show any signs of doing so (even after I did my part to help). Falcotron 20:38, 19 July 2006 (UTC)

Unicode

What do you mean on limited unicode support in Powershell? —The preceding unsigned comment was added by 81.182.88.142 (talk • contribs) 2006-08-07T09:47:14 – Please sign your posts!

Maybe the item should be changed from "Unicode" to "I18n" support - some shells only support ASCII or 8byte character encodings, others only support Unicode (which is bad since the chinese government prefers zh_CN.GB18030 over zh_CN.UTF-8) or have Unicode-cetric features which are useless for non-Unicode locales and others have full multibyte locale support (which means: Any locale and any charatcer encoding within the scope of the POSIX multibyte API). Gisburn 02:30, 4 July 2007 (UTC)

PS supports unicode character handling, but most of the time, it's not able to display them because it's UI relies on the CONSOLE subsystem (which can't display nor read unicode). I guess that's why it was written that PS only has a limited support for unicode (BTW, it's the same with cmd.exe). Maybe it should be written back, even though the next PS release (v2) will contain an early implementation of an unicode enabled console. — Tey' 02:30, 4 May 2008 (UTC) —Preceding unsigned comment added by 82.241.8.181 (talk)

The limitation you mentioned is a limitation of the Windows CONSOLE not of PowerShell. You can see this by using PowerShell_ISE.exe which is a Shell with an Integrated Scripting Environment. It displays Unicode. Jsnover (talk) 20:11, 29 November 2009 (UTC)

Fair comparisation?

Is it fair to campare bash with the powershell this way? I mean, the bash is not only what the built-in features offer, but the whole power of a UNIX-Shell (including whatever you can install), while the PowerShell is feature rich by beeing mostly some sort of ".NET-Shell" with many known cmd and unix sh features, but not even close the scale of external applications (well, you can use nearly all of the GNU things when using mingw or cygwin, but that's cheating ;-) ) ... However, I think it is not so easy to compare the shells this "simple-table-way"... The shells are not only some nice products... Espacially the UNIX-Shells... --PSIplus Ψ 00:15, 25 September 2006 (UTC)

Agree, this is not fair. The UNIX shells are almost always used in an environment where the common UNIX tools are available. This will give them features like regular expressions.

I don't know why a Windows feature, like managed code is included here.

Some features, like "Automatic command parameter binding" and "Extended Type System" should really be defined. It is not obvious from reading the article what this is.

In summary, the table looks like an ad for PowerShell. Ahy1 16:16, 25 September 2006 (UTC)

This discussion is pointless with arguments like this. Next time cmd.exe users start to complain that comparing bash with cmd.exe is unfair, because UNIX ships with so many powerful external tools.

I agree that PowerShell has many features of the .NET-Framework built-in, but this doesn't mean that you can't use external applications as well. Infact you can use all GNU apps that have been ported to Windows or even DOS (e.g. awk, grep, sed) and do your text parsing just like in bash.

I don't understand why this is called cheating when done using PowerShell.

In my opinion this is a comparison on shells and built-in shell features. Most of the external GNU apps that bash and other shells use have their own wiki article which elaborately describe the respective features. If you think that some features like regular expressions are missing in the bash column, then you probably should add something like "Yes (with external software like awk)" to the table. You might also add a detailed explanation as a footnote.

Also note that managed code is NOT a 'Windows feature'. Shells that are using Mono on UNIX or BSD also use managed code. However, I agree that this should probably be renamed to 'Bytecode' which is a more general term in my opinion.

The reason that the meaning of features like "Automatic command parameter binding" and "Extended Type System" is not clear from reading the article is that there are no wiki articles about them yet. In my opition these are quite useful features that could be added to bash or BeanShell as well. I can try to add some explanation or definition on them (when time permits). In case you are interested, you can lean more about the benefit of these features by reading the PowerShell documentation and the Windows PowerShell SDK. However I'd like to add that features like "Here documents" and "Quoting" are also not obvious to novices after reading this article.

In summary, I don't agree that this table looks like an ad for PowerShell. Infact 'features' like for example being written in managed code instead of native machine code doesn't necessarily mean that this is an advantage. From my own experiences I can say that PowerShell needs more time to start up than any other shell that is listed here.

If you can think of any other relevant features that are missing in this comparison, please feel free to add them and I'll be happy to help filling the gaps in the table. -K.S. —The preceding unsigned comment was added by 84.140.45.217 (talk • contribs) 2006-09-29T11:52:18 – Please sign your posts!

The UNIX shells are almost always used in an environment where things like grep, awk and sed are already installed. No separate installation needed. They can be considered a part of the standard API for shell scripts, which happen to run in a separate process.

The managed code concept is a part of .NET which was developed for Windows. I know about Mono, which is an implementation for other operating systems. I called it a Windows-feature, because it is primarily a part of Windows. The important point here, which I didn't managed to make clear, is that the ability to run managed code is an OS feature, not a shell feature. Any shell that can execute external processes is able to run managed code, other byte code formats, machine-code, interpreted scripts and all other program types supported by the operating system.

A comparison of computer shells should not be a table listing the ability to interact with a specific operating environment, but an overview of what features are provided and the different designs.

BTW, I don't think "Here documents" and "quoting" should be part of this table either. Those concepts are only syntax details. Ahy1 11:56, 1 October 2006 (UTC)

I agree that "A comparison of computer shells should [...] [be] an overview of what features are provided and the different designs." And if you dip into PowerShell, then you will notice that PowerShell has a quite different design than shells like bash. Useful features like regular expression support are built-in, they are part of the scripting language of the shell. No need to rely on external tools that run in a seperate process.

Rephrasing what you said, one might infact call an environment – which has things like grep, awk and sed installed as part of the standard API – a UNIX-feature, because it is primarily a part of UNIX-like operating systems. No reason to call this comparison "not fair". From my point of view, the basic design approaches and the built-in features of the shell should be compared in an objective table like this – whith explanations in footnotes when needed.

Also, in my opinion the point is not wheather a shell is able to run byte code formats by executing external processes. This is no big deal and possible on any OS by using things like the Java Virtual Machine or Mono. The point is that there are now shells that are able to go even further. PowerShell for instance can execute all kinds of code (machine code and bytecode) in external processes just like bash, but it also and has direct language support to access bytecode/managed code at the command line and in scripts in process. This is a distinct feature that should be mentioned in my opinion.

As I said before, I do agree that the row "managed code" should probably be renamed by a more general term describing the distinctions in the implementation of the shells. In my opinion it should be mentioned wheather the shell is implemented in machine code or in some sort of intermediate code. There are various pros and cons for both designs like for instance performance and portability.

Furthermore, I wouldn't call features like "Here documents" only syntax details. As the table suggests some shells don't seem to support this concept at all. I also think it is OK to mention different syntax for similar concepts in a comparison of computer shells where it fits into the table. -K.S. —The preceding unsigned comment was added by 84.140.13.23 (talk • contribs) 2006-10-03T05:53:35 – Please sign your posts!

Sure, but the splitting into different jobs (many small tools do specific jobs very good instead of single big jobs) is a UNIX-Philosophy, and Microsoft goes nearly anywhere the opposite way by providing monolithing appications and libraries, witch for example, forced in past people to create statically linked apps and ship basic system libraries, because it could happen that they are not present... This unix-style, that basic system tools available to the shell in POSIX-compatible environments provide specific abilities IS UNIX-Style.

However... How could one really compare this in a table? As others wrote before: Both Shells meight be command-environments, but putting the features in tables is like comparing apples with pears... --PSIplus Ψ 00:48, 7 November 2006 (UTC)

In addition, I added the "POSIX Environment" line... It fair to do this, because UNIX-Shells usually run in UNIX-Environments witch provide more (unnumbered) features... And there are many more possibile ways... What I want to say: Such a comparisation is not a matter of a two dimensional table, more of a ten-dimensional one ;-) --PSIplus Ψ 00:56, 7 November 2006 (UTC)

I don't know if this is the place or now but table looks like an ad for PowerShell. I didn't know that so many people would be saying this already. —Preceding unsigned comment added by Nathan Dbb (talk • contribs) 21:40, 25 April 2008 (UTC)

I think you should not only compare the features, but also the given dates when these shells were first introduced. It is not surprising that zsh (1990) has much more features than for instance csh (1978). And it is also not surprising that 4DOS (1989) has a lot more features than COMMAND.COM (1980). PowerShell (2006) was clearly influenced by quite a few existing and successful command line shells/programming languages. The PowerShell team makes no attempt to hide any of this from the rest of the world ([1]). In fact, Microsoft would have been really stupid not to take the best of both worlds (e.g. ksh and cmd.exe) and add some more useful features/ideas from other successful environments such as .NET, DCL, Perl, Ruby/LISP, CL, SQL, ... Ghettoblaster (talk) 20:13, 28 April 2008 (UTC)

Err actually -"Microsoft would have been really stupid not to take the best of both worlds"- I believe they are. Why don't they load Windows WITH a Korn Shell or BASH or Ruby or all of them and contribute back to the giants who's backs they are stabbing. But that's not the Microsoft way is it? They have their own implementation of the wheel, you know. Looks really technical and expensive. Shows potential, but they still have trouble getting it to turn. Should fly off the shelves! 81.174.174.31 (talk) 22:06, 21 July 2009 (UTC)

Used in POSIX environment

It would be better to change the "Used in Unix/POSIX environment" criteria to something like "Usual platform". The YES/NOs really look like features/deficiencies, whereas the fact that cmd.exe is not used on Unix is not a deficiency. Stevage 23:30, 15 November 2006 (UTC)

Korn Shell

Why is the Korn Shell missing? (BTW, it is now freely available, with source code, from AT&T here http://www.kornshell.com/) topher67 08:28, 16 November 2006 (UTC)

Dunno, I found that weird too since some people refer to it as the most powerful shell. Armslurp 02:44, 27 April 2007 (UTC)

Should be fixed now. Gisburn 04:23, 4 July 2007 (CEST)

It still isn't on there... -PatPeter 01:18, 5 January 2010 (UTC)

Built-in Window

Perhaps a footnote should be added to the Windows shells (command.com, cmd.exe, & powershell.exe) that they include a built-in window with them whereas other shells require a separate program to contain the shell in a window (e.g. xterm). I mention this because the window that cmd.exe creates does not support ansi.sys and hence you cannot have color prompts like you can in command.com windows. topher67 08:28, 16 November 2006 (UTC)

Command.com allows ansi.sys colouring, but cmd.exe doesn't? I didn't know that you could still run command.com, but I just checked, and yeah...interesting. Are you sure that the "window" is actually in command.com though? Isn't that just Windows automatically wrappering any old DOS program with a window? Talking totally out of my arse here...Stevage 09:10, 16 November 2006 (UTC)

cmd.exe runs in a Win32 console window—which is not the same thing as a DOS window, nor is cmd.exe a DOS app. Support for that window is part of the OS; cmd.exe is merely using the facility. Console apps are full fledged Win32 apps that opt for a text only interface. They have full access to the Win32 API. DOS and 16-bit Windows apps are confined to a virtual machine (NTVDM). It is possible to colour text in a console window (Cygwin does it); but cmd.exe doesn't offer an interface to do more than change the colours of the entire screen at once. It is also possible to make the text space any size (i tend to use a 120x1200 space in a 120x30 window), whereas DOS apps are limited to VGA text mode screen sizes. (With an odd size, it is immediately apparent when calling a DOS app, as the window snaps to a VGA size for the duration of the old app's run.)
—überRegenbogen (talk) 02:58, 9 April 2009 (UTC)

"Filters"

Pipes AND filters? You gotta be kidding me. 80.233.255.7 20:48, 30 November 2006 (UTC)

cmd and "start-up scripts"

Assuming it's things like .bashrc meant here, I changed it to "yes". From the MS docs:

If you do not specify /d in string, Cmd.exe looks for the following registry subkeys:

HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor\AutoRun (REG_SZ) 
HKEY_CURRENT_USER\Software\Microsoft\Command Processor\AutoRun (REG_EXPAND_SZ)

If either one or both registry subkeys are present, they are executed before all other variables.

Basically you set the key to "%USERPROFILE%\cmdrc.cmd" (or .bat if you prefer old-school) and put any start-up commands in that file. Like, say, set HOME=%USERPROFILE%, path %HOME%\bin;%PATH%, and doskey man=help $*.  :) —The preceding unsigned comment was added by 80.233.255.7 (talk) 09:56, 7 December 2006 (UTC).

When the computer starts, the c:\autoexec.bat file is executed by command.com. Is this a startup script? —The preceding unsigned comment was added by Michaeldadmum (talk • contribs) 2007-08-03T07:30:47 – Please sign your posts!

Strange "features"

The last few items in the table don't appear to be features in any technical sense. The "Usually used interactively in POSIX/Unix-Environment" item is the closest to one, in the sense that integration/bundling with the POSIX command set can be said to be a sort of feature. At the same time, POSIX commands can be run from any shell, so this is really more of a system issue than a shell issue. The "available as statically linked, independant single file executable" item is also more of a system issue, inasmuch as virtually anything can be built as a statically linked binary, assuming source code is available, if for some reason you really want to throw all the libraries into a single file. Whilst that may be of value in particular niche situations, it isn't really relevant to a normal desktop shell.

The "Platform-Independent" and "FSF 'Free Software'" items are undoubtedly of value, especially in certain situations, but aren't really features, and referring to the Free Software Foundation's rather specialised and non-intuitive (not to mention political) definition of "free software" is bound to confuse some, as demonstrated by a recent edit marking PowerShell as such (which was swiftly corrected). The issue of platform independence is a nebulous one as well, given that POSIX-based shells are only platform independent in the sense that a large number of systems offer the POSIX API. On systems where this is not the primary API, however, it typically offers degraded functionality vis-à-vis the native API, hence anything running on top of it (such as a shell) is also degraded. Insofar as the primary purpose of a shell is to interact with the underlying platform, it's difficult to consider any shell truly platform independent, unless "platform" is taken to mean a particular implementation of a platform (eg the Linux implementation of POSIX, versus the BSD or Unix implementations).

On the whole, whilst these "features" generally have value in some sense or another, they don't belong in a technical comparison, with the possible exception of integration with the POSIX command set. In that case, however, I agree with earlier comments that if a particular feature is provided via external commands which are normally distributed with the shell itself, this should be indicated under the relevant feature (eg indicating it is provided by an external command, which is normally packaged with the shell). This broad "Usually used interactively in POSIX/Unix-Environment" item is really rather ludicrous. —The preceding unsigned comment was added by 84.238.25.76 (talk • contribs) 2007-02-06T12:57:15 – Please sign your posts!

As a final point, I'm not familiar enough with PowerShell to be certain, but my impression from reading about it is that a fair number of the features it offers (eg concerning manipulation of strings) are not features of the shell at all, but are part of the .NET library, which the shell simply provides access to. If this is correct, these features could also be said to be external, much like the external POSIX commands offered by POSIX shells. An important difference is that .NET methods exposed by PowerShell are executed within the shell process address space, whereas external POSIX commands are executed in their own address spaces, but this is simply down to the designs of the respective platforms, with POSIX using the process address space for memory protection, whereas .NET uses type safety instead. —The preceding unsigned comment was added by 84.238.25.76 (talk • contribs) 2007-02-06T13:11:37 – Please sign your posts!

Possible revision comments

I don't think CMD is available as a statically linked binary. The version that ships with Windows is certainly not statically linked: for example, there are 31 DLLs loaded by a cmd.exe process I just looked at under Windows XP. Unless a reliable source is provided, I'll probably change this attribute, although I'd rather remove the row entirely, since this doesn't really belong in a comparison of shells.

The POSIX-environment feature should perhaps be changed from a Boolean item to a choice of standard command sets, e.g. 'POSIX' for bash, ksh, etc., 'Win32' for CMD and '.NET' (or '.NET + Win32') for PowerShell. This would better reflect the nature of a command-line shell as part of a larger collection of command-line tools. Indeed, perhaps this article should even be changed to a comparison of command-line environments, rather than shells. Shalineth 00:20, 4 March 2007 (UTC)

I agree, and have replaced "Usually used interactively in POSIX/Unix-Environment" with "Usual environment". Ahy1 00:44, 4 March 2007 (UTC)

Why don't you think CMD belongs in a comparison of shells? —EncMstr 01:23, 4 March 2007 (UTC)

I think he/she meant the row about "available as statically linked, independent single file executable". CMD clearly belongs in a comparison of shells. Ahy1 22:54, 7 March 2007 (UTC)

Does PowerShell really qualify as a statically-linked, single file executable? I thought it required over 100 megs of .NET stuff just to start up.... Charles dye (talk) 16:32, 13 March 2008 (UTC)

table headings

I'm not familiar enough with the wikicode for tables to do this myself, but can we get the table headings repeated every 10 rows or something? At the moment it's hard to keep track of what shell has what as the names are way off the top of the screen once you get halfway down the table. Modest Genius ^talk 20:03, 26 March 2007 (UTC)

I don't know how to do that either, but it is definitely necessary. Is there anyone who knows how to do that? — SepidarX42 212.144.128.213 18:48, 3 September 2007 (UTC)

I see that someone has fixed that203.206.162.148 (talk) 06:40, 2 February 2010 (UTC)

COMMAND.COM and command history

I would disagree that COMMAND.COM implements a command history "with and without DOSKEY.COM", on two grounds. First, the buffer used by the F1/F3 keys is not a true command history as it only retains a single line. (Not even that, if the transient portion of COMMAND.COM is trashed and reloaded.) And second, the F1/F3 feature is not implemented in COMMAND.COM anyway. It's a feature of the DOS kernel, available to any program which calls 21/0A, e.g. DEBUG or EDLIN. There are DOS shells with a proper command history, but COMMAND.COM has never been one of them. Charles dye 15:29, 23 April 2007 (UTC)

Make that the F1,F2,F3,F4,F5,left,right,ins,del (aka line-editing) feature. ;)
—überRegenbogen (talk) 03:18, 9 April 2009 (UTC)

Why not different versions of COMMAND.COM?

I would personally prefer that COMMAND.COM was referred to explicitly as the one from e.g. MS-DOS 6.22 instead of implying that they're all the same (though I do consider that one to be the weakest because it's probably oldest and, hence, not that useful to list here, especially without more DOS variants).

Also, I would much appreciate having FreeDOS' FreeCOM on there, plus maybe (E)DR-DOS' COMMAND.COM (with explicit version numbering). And 4DOS should be separated from 4NT because they aren't really the same, IMO. And 4DOS is indeed open source, just confusingly so.
Armslurp 02:44, 27 April 2007 (UTC)

AmigaDOS

If someone was really bored, they could add AmigaDOS to this page. It has a fairly simple scripting language, which I forgot long ago, but it can do a few things. Probably about on par with cmd.exe. -- Lawrence Manning (lawrence AT aslak.net) —The preceding unsigned comment was added by 82.69.176.148 (talk • contribs) 2007-05-10T11:23:19 – Please sign your posts!

Many of these features are dependent on the underlying operating system

During the early 1990s the MKS toolkit contained a very good rewrite of the Korn shell, that ran under MS-DOS. But, obviously features, like concurrent pipes, that weren't supported by the underlying operating system weren't supported by the port. -- Geo Swan 23:00, 18 June 2007 (UTC)

"Blocking of unsigned scripts" row is useless

As this feature is only in Powershell, it's not very useful as a comparison-- there's no need to have a row for every conceivable capability, but rather for capabilities that are shared between multiple different shells. —The preceding unsigned comment was added by 24.8.176.51 (talk • contribs) 2007-07-21T13:18:18 – Please sign your posts!

You know what, I got an even better idea! Let's just compare capabilities that ALL of the shells mentioned on this page have in common. Thus we'd have a big green box – what an awesome effect. And also don't forget how usefull this would be for the reader: No more facts that can hurt you! —The preceding unsigned comment was added by 85.179.98.139 (talk • contribs) 2007-07-23T18:04:22 – Please sign your posts!

I agree with you. Obviously, a shell with the capability to block scripts probably written to implement the horde of viruses written to exploit the myriad security vulnerabilities in a system that has such gaping holes as a result of ridiculously poor design should be listed as a feature in order to have a balanced presentation. I'm on your side, amigo. —The preceding unsigned comment was added by 208.250.65.158 (talk • contribs) 2007-08-15T15:11:41 – Please sign your posts!

Can you elaborate more on what the myriad security vulnerabilities and the ridiculously poor design of an operating system have to do with a presentation of specific shell security layers?

I wonder how how other command line shells validate the integrity of published scripts before executing them. Can they restrict script execution based on the identity of the script publisher? Are there any experts here that could add the missing information? — SepidarX42 212.144.128.213 18:41, 3 September 2007 (UTC)

I'm not very familiar with Powershell, but based on what I could find out about this feature doing a quick google search ([2], [3]) I'd say it's really worth mentioning it here. As a matter of fact specifics on security features is something which is currently lacking completely in this comparison. 194.97.209.100 19:43, 30 August 2007 (UTC)

I agree, the basic concept seems to be useful in certain environments. I'll reintroduce the row to the table since this feature is not depending on the underlying operating system. -- Richard Koch —Preceding unsigned comment added by 149.225.2.138 (talk) 14:47, 9 September 2007 (UTC)

I think the burden of proof is on the affirmative party here - in what circumstances is it useful? Why should unauthorized scripts be running anyway? What possible use case does this have, except to be buzzword compliant? (Which hardly seems a valid reason to transform an article into a laundry list.) 142.177.234.33 20:43, 11 September 2007 (UTC)

This technology is used in situations where you need to grant someone the rights to execute scripts, but you also want to make sure that only scripts of trusted publishers (e.g. from your IT department) are executed. Code signing in general is used in environments where code can not be exchanged over a secure channel. It can ensure that you're not running code that has been altered or corrupted since it was signed by use of a checksum.

Code signing is not a buzzword. Companies like Sun, Apple, IBM and most Linux distributions use it to safely distribute and deploy code like updates and scripts.

See also: Digital signature#Benefits of digital signatures —The preceding unsigned comment was added by 217.185.12.38 (talk • contribs) 2007-09-17T09:23:00 – Please sign your posts!

Digital signatures are for the endpoints of a data transfer, where something could have been tampered with or corrupted. Companies like Sun, Apple, IBM, and Linux distros use digital signatures for endpoints of non-encrypted, verifiable traffic. The Windows PowerShell usage is completely different - it is used as a method of verifying and enforcing scripts executing at a privilege level after the transfer and on disk, where, even according to the official docs, it is only used to prevent damage from the scripts themselves, despite the fact that the user running the scripts from the same level poses the _same threat_. It certainly poses no security benefit, except in the corner case of executing scripts across a network share.142.177.233.133 00:54, 24 October 2007 (UTC)

I think the wording is wrong for this row, it should be something like this. Control of execution. As this is not domain specific. Also as it stands 'blocking of unsigned scripts', is operating system dependent. Moreover other operating systems have other ways of controlling by whom or what scripts can be executed. —Preceding unsigned comment added by 123.243.163.103 (talk) 05:05, 23 April 2008 (UTC)

This is not operating system dependent. Code signing is the process of digitally signing executables and scripts to confirm the software author and guarantee that the code has not been altered or corrupted since it was signed by use of a cryptographic hash. Ghettoblaster (talk) 11:56, 23 April 2008 (UTC)

Native CIM/WBEM support

In what sense does PS implement CIM/WBEM support? And in what sense does a Linux-based shell with http://sourceforge.net/projects/sblim not do so? The word "native" to identify aspects of the associated applications and libraries doesn't seem helpful when comparing shells. Should this row be removed? --NealMcB 03:45, 27 July 2007 (UTC)

The PowerShell language has built in syntax elements to access the CIM repository to work with CIM classes and instances. You can also query the CIM repository using Microsoft's built-in implementation of the CIM Query language (which is similar to Sun's implementation called Solaris WBEM Query Language (WQL) [4]).

# get a CIM class and assign it to a PowerShell variable
PS> $CIM_Class = [wmiclass]'CIM_MediaAccessDevice'
# access properties of the CIM class
PS> $CIM_Class.__DERIVATION
CIM_LogicalDevice
CIM_LogicalElement
CIM_ManagedSystemElement
PS> $CIM_Class.__PATH
\\HAL9000\ROOT\cimv2:CIM_MediaAccessDevice
# invoke a CIM class method
PS> $CIM_Class.GetRelatedClasses()
CIM_StorageExtent

# using the integrated CIM Query Language
PS> $CIM_Query = [wmisearcher]'SELECT Name FROM CIM_PointingDevice WHERE NumberOfButtons > 2'
PS> $CIM_Query.get()
...
PS> $CIM_Query = [wmisearcher]'SELECT Name, BlockSize FROM CIM_StorageExtent'
PS> $CIM_Query.get()
...
PS> ([wmisearcher]'SELECT * FROM CIM_TemperatureSensor WHERE Status="OK"').get()
...
PS> ([wmisearcher]'SELECT * FROM CIM_MediaAccessDevice WHERE Caption LIKE "%iPod%"').get()
...

# create CIM instances (management objects), access their properties and invoke instance methods
PS> ([wmi]"\\127.0.0.1\root\cimv2:Win32_Process.Handle='$PID'").ThreadCount
7
PS> $CIM_Instance = [wmi]"\\localhost\root\cimv2:Win32_Process.Handle='$PID'"
PS> $CIM_Instance.GetOwner()
...
# pipe CIM instances to other commands, which then can access all CIM properties and even methods
PS> [wmi]'\\HAL9000\root\cimv2:Win32_VideoController.DeviceID="VideoController1"' | select Name, Current*Resolution, CurrentNumberOfColo*, Driver*
Name                        : ATI MOBILITY RADEON X300
CurrentHorizontalResolution : 1920
CurrentVerticalResolution   : 1200
CurrentNumberOfColors       : 4294967296
DriverDate                  : 20041203213426.000000-000
DriverVersion               : 6.14.10.6483

Note that the features mentioned above are integrated in the shell, whereas WBEM clients like Purgos or SBLIM are a third party applications that need to be installed seperately. Of course you can also run these external commands in a similar way as Linux-based shells do, but running external applications is a basic feature that is implemented in literally every shell on earth.

Should features like built-in pseudorandom number generators be removed if bash was the only shell that implemented this feature? I don't think so. I can run a PRNG using any shell I want, but some shells have native ways to get a pseudorandom number.

What about regular expressions? Recent bash versions have native regex support built-in right into the language so you do not need start up a new process for every regex. —The preceding unsigned comment was added by 78.51.113.191 (talk • contribs) 2007-07-29T10:00:27 – Please sign your posts!

regex should stay, as it is a useful part of a shell - it hardly makes sense to use another binary to provide matching for data held by the shell. On the other hand, the PRNG, spellchecking and Native CIM/WBEM support are special-use scenarios, and are probably not general enough to be used in this article. Blocking of unsigned scripts is also a bizarre addition, as scripts shouldn't be executing without some level of user permission unless the OS/shell is seriously broken, and bytecode really _shouldn't_ make a difference. Are we comparing shells, or are we just trying to push individual features from their respective articles to this chart? 142.177.233.227 16:29, 5 August 2007 (UTC)

I would suggest a simple numeric criterion: Any row with fewer than three 'yes' columns is probably too abstruse to be worth including. Charles dye 15:30, 11 September 2007 (UTC)

IMHO a plain numeric criterion as you suggest it would just not be appropriate for a broad comparison of computer shells. What you're suggesting would effectively suppress innovative features like integrated spell checking, array slicing, CIM access and lambda functions just because they are not implemented in many shells yet. I think inclusion of features should depend more on whether they provide notable benefits to the user or not. —Preceding unsigned comment added by 78.51.76.96 (talk) 19:55, 12 September 2007 (UTC)

This is operating system specific and therefor should be removed as a row. —Preceding unsigned comment added by 123.243.163.103 (talk) 05:12, 23 April 2008 (UTC)

This is not operating system specific. WBEM is based on Internet standards and DMTF open standards: CIM infrastructure and schema, CIM-XML, CIM operations over HTTP, WS-Management. There are plenty of implementations for many major Unix-like operating systems (Web-Based_Enterprise_Management#Implementations). Ghettoblaster (talk) 11:49, 23 April 2008 (UTC)

OK enough already!
"What you're suggesting would effectively suppress innovative features like integrated spell checking, array slicing, CIM access and lambda functions just because they are not implemented in many shells yet."
May be that would be the realm of a full language like Perl or C (and the line should be drawn IMHO) but innovative? Please!
"Blocking of unsigned scripts" is a specific implementation of a security feature which is (let's face it) the result of viral vbscripts running dangerous ActiveX controls. All of which is spawned from the Microsoft house.
The point is different shells have their own security features (or not :-) or use the underlying OS security so a maybe we should add that PowerShell doesn't have an execute bit or a sticky bit or doesn't have the ability to run restricted to a single filesystem or other features which are missing from the underlying OS.

Yes, that might be useful

Rename it please and stop defending obvious flag flying. 81.174.174.31 (talk) 21:59, 21 July 2009 (UTC)

Perhaps the same row could be altered to show that CMD and presumably Powershell don't honour the 'execute' permission in the same way that *nix shells do, that is, they don't read the first line of a script, and then decide what to do based on that - which is a both a well known security flaw, and a feature that is missing from other shells.

command.com startup scripts

Regarding the current discussion whether autoexec.bat is a shell startup script or not I'd like to add some of my thoughts: First of all, I can't remember if autoexec.bat will run again when you start another command.com instance at the DOS prompt. However, on Windows systems that ship with both command.com and cmd.exe (e.g. WinXP) autoexec.bat does not run at all no matter how often you start command.com, so IMHO autoexec.bat is just an OS startup script. Furthermore, I wouldn't call config.sys a startup script because AFAIK you can't run other process that way. The config.sys is more like an *.ini file for DOS if I remember correctly. 78.49.13.216 18:45, 10 September 2007 (UTC)

In most versions of DOS, AUTOEXEC.BAT is handled only by the initial or 'primary' shell -- the one launched with the /P option. If you later start another copy of the command shell using e.g. COMMAND /P, then that shell will re-process AUTOEXEC.BAT. It will also effectively disable the EXIT command, leaving no easy way to terminate the secondary shell.

CONFIG.SYS is not a shell script; in fact, one of its functions is to specify the name and path of the command shell. Charles dye 15:40, 11 September 2007 (UTC)

Remove Python and Ruby

The Python and Ruby on this page should be removed. They are really not “shells” in its typical meaning of a cmd line interface to OS. They are simply interactive interface of the language. Also, scsh should be added because it is by nature a OS shell (and secondary a scheme lang implementation). The only consideration of its omission might be that it doesn't actually offer interactive feature. Xah Lee 02:57, 12 September 2007 (UTC)

I may be wrong, but last time that I checked this article was called "comparison of computer shells" and not "comparison of operating system command line interpreters in its typical meaning". Python shell and Ruby shell really are computer shells and can certainly be used as system shell ("command line interface to the OS"). In fact both, include more features than some of the "traditional" Unix shells listed on this page.

"IPython can be used as a system shell replacement, especially on Windows, which has a minimally capable shell. Its default behavior is largely familiar from Unix shells, but it allows customization and the flexibility of executing in a live Python environment." —Preceding unsigned comment added by 78.51.76.96 (talk) 19:22, 12 September 2007 (UTC)

What about Tcl Shell (tclsh) or wish? Should they be included? Nick (talk) 13:49, 23 November 2008 (UTC)

Why not. If you know something about those command shells, please be bold and add it to the table. Ghettoblaster (talk) 16:58, 23 November 2008 (UTC)

DEC operating systems are not represented

I mean RT-11, RSX-11 and OpenVMS--Dojarca 16:08, 7 October 2007 (UTC)

Thank you for your suggestion. When you feel an article needs improvement, please feel free to make those changes. Wikipedia is a wiki, so anyone can edit almost any article by simply following the Edit this page link at the top. The Wikipedia community encourages you to be bold in updating pages. Don't worry too much about making honest mistakes — they're likely to be found and corrected quickly. If you're not sure how editing works, check out how to edit a page, or use the sandbox to try out your editing skills. New contributors are always welcome. You don't even need to log in (although there are many reasons why you might want to). —The preceding unsigned comment was added by 194.97.209.126 (talk • contribs) 2007-10-08T10:18:06 – Please sign your posts!

Colored Yes/No in Open Source column

I see red/green colored boxes in the open source column as a violation of NPOV, and I've replaced them with neutral-colored text. It's a small issue, but I don't believe it's the place of Wikipedia to say that open source is better than closed - they're different philosophies, both with supporters and detractors. --mcpusc 06:07, 22 October 2007 (UTC)

... If you assume that red and green mean "good" and "bad". Certainly the licensing status is going to be more important to many people than some of the more abstruse features; it's worthy of color-coding. Suppose "yes" and "no" were blue and yellow instead? 129.24.38.145 22:17, 22 October 2007 (UTC)

I'm not sure that it's simply an "assumption" that green/red are good/bad; western culture generally sees the two that way, which is why red and green were used for yes/no in the first place - for a feature list, the positive/negative connotations are fine. But I don't think they're fine here. Two neutral colors would work, but I worry that the tables would soon be a rainbow of different colored boxes that no longer convey quick meaning.

How about expanding the "open source" column to a more verbose "license", naming the specific license for each product. That would sidestep the good/bad problem and add value to the article. --mcpusc 06:56, 23 October 2007 (UTC)

Yep, I think the last row should be split into two separate rows source model and license. I guess introducing new blue/yellow colors or would make the situation even worse.

Also, what is available as statically linked, independent single file executable supposed to mean? Why is this "good" or "bad"? In my opinion this a violation of NPOV as well since it hardly counts as a shell feature. —Preceding unsigned comment added by 85.181.242.248 (talk) 21:56, 24 October 2007 (UTC)

I suppose the point of having something about availability as a static executable may be to address shells' usability in embedded environments and/or environments where normally expected facilities (e.g. standard libraries) are broken. Busybox and Sash come to mind. However, this particular criterion is by itself not too useful for comparing usability for these purposes:

• The statically compiled binary may include half the libraries on the system- size does matter esp. for embedded.
• Different shells depend to varying amounts on other programs and facilities to be useful.
• Whether the program is (or can be compiled as) one file is largely irrelevant. --Prodicus 03:01, 9 November 2007 (UTC)

Exception handling for command.com and cmd.exe

Wouldn't "errorlevel" count as exception handling? These have been integral parts of batch files for as long as I can remember, batch files would be (more) useless without them.--18.127.1.9 (talk) 17:38, 13 December 2007 (UTC)

I think ERRORLEVEL would be better described as an exit code; any normal program will return one when it exits. An exception is more like an interrupt; it's raised by the CPU itself in response to some serious error, and a correctly operating program should not generate any. 129.24.38.145 (talk) 19:31, 19 December 2007 (UTC)

compound variables

Would you mind providing some kind of definition or explanation for this feature you're suggesting?
Apparently there is no Wikipedia article (compound variable) for this yet. The REXX shell does have a feature of that name (REXX#Compound_variables), but according to that definition this seems to be just another name/syntax for an associative array or hash table and I think we already have those covered in the table. The struct definition (Object composition) that you mentioned in your summary seems to suggest that there is no big difference from a functional point of view? —The preceding unsigned comment was added by 78.51.102.167 (talk • contribs) 2007-12-19T20:01:33 – Please sign your posts!

I believe compound variable is ksh93 terminology. It's like an associative arrays with restriction on the key values but whose values can be of any type (including other compound variables)

 $ a=(b=(1 2 3) c=(a=1 b=2))
 $ echo ${a.c.a}
 1

It's quite limited and can be implemented otherwise like:

 $ a_b=(1 2 3)
 $ a_c_a=1
 $ a_c_b=2
 $ echo ${a_c_a}
 1

—Preceding unsigned comment added by 90.28.141.145 (talk) 13:17, 8 January 2008 (UTC)

There are compound variables in Windows PowerShell:

 PS C:\> $a=@{b=(1,2,3); c=@{a=1; b=2}}
 PS C:\> echo $a.c.a
 1

The syntax is slightly different, but the functionality is there. —Preceding unsigned comment added by 92.226.200.25 (talk) 20:56, 13 January 2008 (UTC)

Unless someone can give an example of compound variable usage that is not also possible using PowerShell syntax, I'm going to add this feature back to the associated column.

To the one who reverted my recent edits: Please use this page to discuss controversial questions instead of IRC before reverting the article again. It might also help to learn basics about PowerShell before editing this column in the future. Thanks. —Preceding unsigned comment added by 92.226.200.25 (talk) 23:07, 13 January 2008 (UTC)

Standard POSIX shell?

We have bash listed, but not the standard shell (sh) as defined by the POSIX standard(s). See Single UNIX Specification, for example. SkyDot (talk) 20:42, 8 January 2008 (UTC)

There is the Almquist shell, which is pretty close to the Bourne shell that has replaced the Thompson shell... but I was wondering, too, who did not include the Bourne shell in a shell comparison -- must be a Linux guy. ;-) —Preceding unsigned comment added by 78.54.97.117 (talk) 13:04, 10 May 2008 (UTC)

Hey! I'm a Linux guy, and I find the omission of the Bourne shell strange. I came here looking for an explanation of how the Almquist and Debian Almquist shells differ, and how they each differ from the Bourne shell. Evidently, this isn't noteworthy enough. --Rfsmit (talk) 20:30, 21 July 2008 (UTC)

The POSIX shell is based on the Korn shell, but the Korn shell includes much that is not a part of POSIX. The actual POSIX shell (or rather, the behavior that POSIX requires from a shell) should be listed before any of the myriad shells that attempt to implement it. 121a0012 (talk) 07:50, 15 November 2010 (UTC)

Default argument

How can default arguments be defined using bash and ksh? —Preceding unsigned comment added by 92.227.135.56 (talk) 22:52, 10 January 2008 (UTC)

Well, I don't really understand the concept of "default argument" in the context of a shell. A shell is a command interpreter. Arguments to commands, from the command's point of view is a list of string (char *argv[]). The command is free to decide how to parse the list of arguments, and the convention to parse argument (whether it's via options (--key value) or key=value lists...), and it's up to the command to decide what to do wrt to default value of arguments. And that also applies to commands defined within the shell as functions.

In Bourne-like shells, if you define a command as a function like:

 foo() {
   ...
 }

and you mean foo to expect in-between 0 and 2 positional parameters that are to be considered as the A and B arguments with default values for each, you could do:

 foo() {
   A=${1-default-A}
   B=${2-default-B}
   ...
 }

—The preceding unsigned comment was added by Stephane Chazelas (talk • contribs) 2008-01-30T12:32:29 – Please sign your posts!

"Aliases" in CMD.EXE, COMMAND.COM

Do macros in CMD.EXE really qualify as aliases? If I'm not mistaken, the macro substitution is performed only at the command line, not in a batch file. Charles dye (talk) 21:18, 7 March 2008 (UTC)

Dunno. In Command.com, DOSKEY was a DOS executable, and the alias's were stored in program memory, not in command.com memory. But in Win2000 plus, there is a kernel API for storing alias's, so DOSKEY may just be the data-entry point for a shell feature.

added alias method to command.com. Example:

 set fred=ping.exe
 %fred%
 Usage: ping [-t] [-a] [-n count] ... etc

Note that the "alias" is an shell variable, and can only be accessed using the shell syntax % or %%. Apart from that, it is just a shell alias: DOS used the keyword 'set' instead of 'alias'.

It is also possible to alias command lines using HKLM\SOFTWARE\Microsoft\CurrentVersion\App Paths That may be more limited: from the name of the key, it is only expected to alias app paths, so I don't know what it would do if you tried it on something that it wasn't going to execute. If it is special purpose, it wouldn't be the only one: there are a stack of special purpose alias things in different places.

Also, there is a whole stack of COM object and NET object and MANIFEST object aliasing available in modern versions of Windows. Since you can't use this from any non-windows command shell, I don't suppose anybody looking at this table would care.203.206.162.148 (talk) 08:47, 2 February 2010 (UTC)

FreeDOS's COMMAND

Do you agree with this?:(COMMAND.COM does not have any of these features: integer math, command history, aliases, startup scripts. (Exception: FreeDOS's, which is very atypical.)) Well, I disagree, it is still COMMAND. Helpsloose 18:10, 3 April 2008 (UTC)

FreeCOM is quite different from the COMMAND.COM in MS- PC- and DR-DOS and Win9X, by far the most common implementations. It's more like a poor man's 4DOS. There's no reason why it shouldn't be documented, of course, but it ought to get a column of its own rather than being confusingly lumped in with the more widely-used versions. (And note that even FreeCOM does not offer all of the features that had been incorrectly ascribed to COMMAND.COM; I'm pretty sure that it doesn't provide e.g. integer math or startup scripts.) Charles dye (talk) 16:20, 5 April 2008 (UTC)

Unix/Windows centric

I'm not very happy with this article, because it is very DOS/Windows/Unix (hereinafter DWU) centric. Now, undoubtedly, that is the mainstream of computing nowadays, but really this concept of a "shell" or "command line interface to an OS" has been around for a very long time, and has seen numerous different incarnations. And I think, to some extent, that concentrating on DWU gives a limited view of the possibilities or varieties here, simply because they are such similar systems. (COMMAND.COM/CMD.EXE/PowerShell all show heavy Unix-influence.)

If you want to get an idea of the variety of different shells out there, maybe consider the following systems:

• OpenVMS command line interface (DCL)
• TSO/E command line interface
• OS/400 CL command line interface
• VM/CMS command line interface
• CP/M command line interface

And there are numerous other systems I could mention here, such as VSE, MPE, Multics, MVS console interface (which is I understand a distinct CLI from TSO), Burroughs/Unisys MCP WFL, and there are numerous, numerous others. And many of these are more interesting, simply from the perspective that they are different from the DWU world. A comparison which ignores these systems inevitably ignores some of the ideas that make DWU a bit unique:

• many system commands run as external processes. Unix was a bit original (compared to many of its predecessors) in making many basic commands which on other systems would be built in to the shell actually run as external programs (e.g. cp, mv, ls). DOS/Windows shows a bit of this influence, although it doesn't go as far as Unix (e.g. COMMAND.COM/CMD.EXE includes basic commands like COPY & MOVE, yet still a great many basic system utilities are external programs). Conversely, PowerShell, BeanShell, etc., are a return more to the pre-Unix way of doing things.
• one consequence of making so many commands external is that it makes the code of the shell simpler, and arguably on old DOS systems it saved on memory [although, nowadays that is no issue]
• an alternative approach to using external processes, yet still keeping the shell modular/extendable, would be to make the shell commands be dynamically loadable libraries rather than processes. One obvious reason why Unix didn't go down this route is that the shell is older than support for dynamic linking. On the other hand, have you ever done "strace ls" on an empty directory? On my Linux system that results in 101 system calls, and most of them seem to be related to process startup code, e.g. loading dynamic libraries, etc. -- you could argue, a bit of an overkill just to get a directory listing. In some ways, PowerShell & BeanShell can be seen to implement exactly this idea, since commands are no longer necessarily external processes but rather .NET or Java classes executing in the same process. The security features of these managed execution platforms also makes loading command code into the same process as the shell potentially safer than it would be for native Unix/Windows processes.
• Unix was also a bit original in having most commands be simply files on the disk, and the task of executing a command is to search the disk (using a path) for a file with that name to execute. This contrasts to other systems where you need to define to the shell the command and then specify which file would be run by it -- often the shell would store all the command definitions in memory, or in a separate shell configuration file or database.
• One consequence of this is that whereas on other systems to start a process one would often type something like "RUN program", on Unix-derived systems one simply types "program"
• One disadvantage of having commands be simple on-disk files is that it makes it hard for the shell to know the command's syntax, and thus the shell is limited in its abilities as far as completion, context-sensitive help, globbing, etc. goes. A good comparison is to compare Unix shells with OS/400 CL -- in CL, every command (including those that start external programs) can have its syntax defined in a definition file. Thus, CL can display & validate fill-in forms on the screen for the command and its arguments. Some people would like Unix shells to have smarter features like tab completion of option characters -- but that is rather hard given the implementation approach. Now, something like PowerShell, I don't know if it has this kind of feature, but architecturally it wouldn't be hard to implement...

So, I think the current article, by ignoring some of these older, more esoteric nowadays systems, actually fails to get to the some of the essences of the shells it discusses, and seems to focus too much on feature list trivia rather than fundamental architectural differences. (e.g. I think whether a shell has built-in support for regexes or floating point arithmetic isn't really interesting from an architectural or OS design perspective, however useful a feature it might be in practice.)

Well, that's my rant for today. Feel free to mine the above for content to add to the article, if anyone agrees with me on this issue. --SJK (talk) 10:27, 6 May 2008 (UTC)

Someone already suggested adding the command line interpreters of RT-11, RSX-11 and OpenVMS to this comparison and I agree that we should add more of these "exotic"/historic CLIs to this article. Unfortunately, I don't know much about any of these non-DWU CLIs. If you have any detailed information on some of these shells, please contribute. In case this table gets too wide, I suggest splitting the table into multiple categorized tables like in the article Comparison of office suites. I'd very much like to do this, but this will involve some big changes and a lot of work since this table is already quite large. So I think we should discuss possible categories/layout changes etc. here first. Does anyone know a tool that helps creating/transforming wikipedia tables? Ghettoblaster (talk) 11:00, 6 May 2008 (UTC)

Unfortunately, when it comes to most of these old systems, all I know is what I have read (mostly on Wikipedia). I suppose I know enough to know this article has a bit problem, but I don't feel confident enough to be able to personally fix it.

I suppose I'd like to see the table have three new rows:

• External vs. Internal commands: are most commands builtin to shell or external processes? This isn't really a Yes/No question, its more of a nuance thing... e.g. Unix is more at the external end than DOS, and some "historical/exotic" OS's have been even further to the internal end. Also, the external processes v.s. classes distinction (e.g. cmd.exe vs PowerShell) is a related distinction, I'm not sure if it belongs under the same heading or a separate one...
• Commands as files vs. Commands as definitions: what I'm trying to capture here is the distinction I mentioned above between e.g. sh vs. CL or DCL -- sh knows nothing about command arguments except that they are a list of strings; CL or DCL knows the syntax of the command in more detail.
• Structured programming: does the shell support structured programming concepts, or just simple IF/THEN/GOTO? (Compare command.com or JCL to bash). I don't think we need to go into heaps of detail about exactly what structured programming concepts it supports.

I also think that the Unix-derived concept of a shell mixes the interactive and the batch-oriented. JCL, although not a shell in the interactive sense, certainly is a shell in the batch-oriented sense. So should we add JCL as a shell? Maybe we should also add CMS Pipelines as well -- again, not interactive, but its an interesting descendant of the Unix pipeline concept?

(BTW, I think comparing JCL to Unix is interesting. It supports in-stream datasets, which if you think about it are equivalent to heredocs. DUMMY is equivalent to /dev/null. More interestingly, I think, Unix processes support three main ways of passing startup parameters - the command line, the environment, and inherited file descriptors. I'm not aware of a JCL equivalent to the environment, but the command line is the PARM= parameter coded on an EXEC PGM=. And similarly, the equivalent of inherited file descriptors is DD. But the interesting bit is that Unix uses numbers to refer to the file descriptors (0, 1, 2, etc.), whereas JCL uses names (SYSIN,SYSOUT,etc.) And one wonders which one is more primitive, Unix or JCL? (OK, admittedly JCL's syntax is really sucky... but the idea is interesting.))

--SJK (talk) 13:01, 6 May 2008 (UTC)

Yes, this page is very DWU-centric, but the reader should expect that from the title. Very few, if any, non-DWU user interfaces refer to themselves as "shells." More common in the non-DWU world is simply "CLI" for the command-line interface. I would suggest that the title be changed to better reflect this DWU orientation. It makes sense to provide only DWU shells in this way, however, because many non-DWU interfaces solve similar problems in radically different ways. The DWU world generally solves similar problems in similar ways, so it makes sense to compare just how they were solved in each implementation. It doesn't make sense, I think, to ask whether a particular interface includes a particular feature, if that feature is the solution to a problem that the interface never had. In any event, I'm afraid that we'll have to wait for a different page to provide an objective comparison of non-DWU user interfaces. —Preceding unsigned comment added by 12.152.252.4 (talk) 19:15, 3 June 2008 (UTC)

Reoginzation and Simplification

• Divide the table into functional areas such as a) parameter handling, b) file redirection c) control flow language features (if, while, goto), d) subroutine handling (e.g., cmd.exe has decent subroutine handling but not an facility for functions with named parameters and enclosing {} charcters) and e) all other things.
• Combine the various UNIX shells (bash, csh, etc.) into one entry with the minor differences listed in the individual cells
• Allow for exceptional notes such as 'not supported directly by cmd.exe but supported in the built in vbscript scripting environment.
• Add in shells from widely used present and historical systems (VAX/VMS, AS/400, etc.). This is definitely lacking since long lived commercial platforms are ignored and only IBM, Microsoft, Apple and Unix/Linux are covered. The 1960s-1980s era mainframes are a good example (e.g, Univac). —Preceding unsigned comment added by 12.155.35.130 (talk) 14:43, 19 June 2008 (UTC)

• Use a WikiPedia table format that allows for the rearrangement (by dragging) of columns so that one can place the shell that you want to compare side-by-side. I don't know if there is such an object, but there should be.
• Allow for columns to be hidden. —The preceding unsigned comment was added by George OConnor (talk • contribs) 2008-08-30T01:25:27 – Please sign your posts!

A bit of confusion

in order to achieve Spreadsheet-like (e.g. Microsoft Excel) behavior in HTML in Wikitext, the Mediawiki engine must be supporting this. I don't think it supports such things, therefore, these things are impossible:

• columns to be hidden
• panes to be split/frozen
• there's no "WikiPedia table format that allows for the rearrangement (by dragging) of columns"

IMO, your suggestion is THE best I've seen for columns & rows & cells, & I do agree that more Spreadsheet-like behaviour of HTML through Mediawiki engine & Wikitext would be, for sure, liked by the community and casual readers! But, as always, somebody needs to program it... 193.173.39.45 (talk) 11:25, 18 February 2009 (UTC)

Lisp?

Should the Lisp REPL be included on this page? —Preceding unsigned comment added by 75.65.196.71 (talk) 18:42, 18 August 2008 (UTC)

Multiline editor

The article should say which shells have a multiline editor, particularly important for recalling a multiline command from the history. For instance, zsh has one, but not bash 3.x (I don't know if this has changed in bash 4.0). Vincent Lefèvre (talk) 03:33, 25 February 2009 (UTC)

Thank you for your suggestion. When you believe an article needs improvement, please feel free to make those changes. Wikipedia is a wiki, so anyone can edit almost any article by simply following the edit this page link at the top. The Wikipedia community encourages you to be bold in updating pages. Don't worry too much about making honest mistakes—they're likely to be found and corrected quickly. If you're not sure how editing works, check out how to edit a page, or use the sandbox to try out your editing skills. New contributors are always welcome. You don't even need to log in (although there are many reasons why you might want to). Ghettoblaster (talk) 18:33, 27 March 2009 (UTC)

MPW Shell

Should [MPW Shell] be included? It introduced a number of good and bad ideas including a more GUI-oriented approach: perhaps, but not certainly, of historical interest. Information on it is already present in another article 62.12.14.26 (talk) 14:06, 27 March 2009 (UTC)

Please go ahead and add a column for MPW Shell (and some rows when appropriate) if you know something about it. Ghettoblaster (talk) 18:33, 27 March 2009 (UTC)

Command.com subshelling and quoting

Command.com is listed as not supporting subshells. I take subshell to mean a shell spawned as a child process of itself. Command.com has been able to do this at least since MS-DOS (incl PC-DOS) 2.11. (Before the call command was introduced in MS-DOS 3.3, this was the only way to run another batch and have control return to the calling batch.)

Command.com has also supported basic quoting (of the " " sort) since version 6 (possibly 5 or 4) (albeit with some side effects pertaining to the quote characters themselves being included in the argument that they enclose, leaving the application to deal with stripping them).
—überRegenbogen (talk) 03:49, 9 April 2009 (UTC)

• Actually, DOS/windows passes the whole command line as one string, so the shell doesn't handle quoting at all. It's emulated by most applications (usually inside the C stdlib). Cbensf (talk) 19:29, 23 February 2010 (UTC)

History in Powershell?

I think the meaning of history is cross-session - this blog indicates, NO. -Zeus-^u|c 15:56, 13 April 2009 (UTC)

Command history Ghettoblaster (talk) 19:57, 9 June 2009 (UTC)

column organization

I think it would be beneficial to have related shells next to each other. E.g.: sh, ash, bash, ksh, zsh. This would be very helpful for people coming here to find differences between "flavors" of the "same" shell. ⇔ ChristTrekker 14:36, 12 June 2009 (UTC)

ansi code support

this article was useless to me, I think that there should be a column for whether the shells support ansi escape sequences. —Preceding unsigned comment added by 64.66.99.129 (talk) 19:58, 6 July 2009 (UTC)

Bash is king of ubiquity

Where's the Unix PowerShell. Oh there it is!
Whatabout Perl, PHP and Python? the run shell mode too. 81.174.174.31 (talk) 22:29, 21 July 2009 (UTC)

No sh?

So though this has bash, csh, tcsh, and zsh, it does not have sh, the original of them all. Anyone want to add it? I would but I have no idea what the specs on it are (so no one gives me a {{sofixit}}). Adding the Thompson shell has no use for those who think of that before the Bourne shell. -PatPeter 01:17, 5 January 2010 (UTC)

It has virtually no features and is honestly only a viable choice for piping commands into it. There are shells that deserve place in this table much more.

--Asmageddon (talk) 19:07, 7 November 2011 (UTC)

To the contrary, this article lists three of them, including the original Bourne shell (which nobody uses any more). 121a0012 (talk) 04:38, 11 November 2011 (UTC)

Korn shell with object oriented pipes?

I have reverted a revert. I removed the "objects" from "ksh93t+" column of the "pipes" row as I have seen no information that ksh93 suddenly acquired object-oriented pipes. Somebody reverted that change, claiming that "I could just do print -C" if I didn't trust it. I have searched wide and far for any information on this subject. So far no support for this claim. Yes, print may have an -C parameter, but that is a far stretch from having object pipes. How do commands stream object graphs? How do commands invoke methods on piped objects? What does the object model look like?. Useerup (talk) 16:12, 9 January 2010 (UTC)

Perhaps we need to qualify it a little? Like e.g. "ksh93t supports serialization of structured objects" - if that is what print -C does? Useerup (talk) 16:14, 9 January 2010 (UTC)

Finally found a link describing the "new" print -C option: http://stage.opensolaris.org/os/project/shell/shellstyle/#print_compound_variables_using_print_C

No, ksh93t has not acquired object oriented pipes. What it has got is compound variables - akin to Pascal record or (plain) C structs. And with ksh93t+ it can now "print" those compound variables out. No methods, no events, no properties (only fields). There is no member method concept, static or instance or otherwise. I suppose you could hide a script in a string value, but that would not qualify either. I stand by by reversion: ksh93 (even in the t+ version) does not have objects in the sense as any support for even the most basic OO concept. Not in script, not in pipesUseerup (talk) 17:37, 9 January 2010 (UTC)

the comment above is a "classical" Wikipedia issue: People remove or edit things WITHOOUT doing _any_ research. Thankyouverymuch. 1. ksh93 version 't' got support for object-oriented classes and types. David Korn has written a couple of papers about this, announced this in the ast-users and ast-developers mailing lists. 2. Types and classes can be defined via typeset -T classname=( class spec ) 3. objects from classes and types can be serialised into files and pipes via print -C obj and read back via print -C obj 4. Very simple example for using ksh93's new type+class system can be found athttp://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libshell/common/scripts/shircbot.sh —Preceding unsigned comment added by 84.59.79.230 (talk) 00:35, 10 January 2010 (UTC)

I clearly spelled out that I had searched wide and far for this. If David Korn has written papers on this why don't you cite them? It would have saved us several misunderstandings here. Yes, your linked example does demonstrate that compound variables may indeed contain methods - which would make them objects. And print -C / read -C (in ksh93t+) allows you to serialize those compound variables through the pipeline. However, that does not make the pipelines object-oriented much less object based. Commands which receive the piped "objects" need to know in advance that they will be objects that that they must be read using read -C - instead of the regular. Merely being able to manually serialize/de-serialize objects does not make the pipelines object based. I can see how the term "objects" may be ambigous. In ksh93 the pipes are still streams of text. In IPython (with IPipe) the pipes are native python objects - no manual serialization/deserialization. In PowerShell pipes are object based and old-style text-producing executables are producing a stream of System.String objects. I am changing the ksh94t column to reflect this. Useerup (talk) 10:39, 10 January 2010 (UTC)

84.59.79.230, talk to me here instead trying to get me banned. I have raised this issue: Merely being able to serialize compound variables (with functions) does not make the pipes object based or even object-oriented. I can see that if you choose to interpret "objects" as narrowly the capability to transmit objects (even in serialized form) you could defend the "object" qualifier. However, in the context of pipes - and in the light on what object pipes means in IPython/IPipe and PowerShell that would be a gross simplification of the concept. The object pipes of IPython and PowerShell are distinguishing features and the ability of other shells to explicitly serialize/deserialize compound variables is nowhere in the same ballpark. Consider the fact that all items passed through pipes in those shells are indeed objects. What you are saying is that because there exists two functions (print and read) which can encode and decode objects (if used explicitly), ksh93t should be considered to have object pipes. ksh93's pipes are basically text pipes. What ksh93t has got is two function by which you can tunnel objects through pipes. I use the term tunnel because commands that do not recognize that there may be objects (and thus do not use the read -C function) will not receive objects. Useerup (talk) 14:49, 10 January 2010 (UTC)

In the Unix word, a pipe is a pipe; there's no such thing as an "object pipe" or indeed a "text pipe". You put bytes (not characters) in at one end and they come out the other; what each end of the pipeline chooses to do with it is their own business, and has nothing to do with the shell, whose only involvement is in setting up the connection. 121a0012 (talk) 07:58, 15 November 2010 (UTC)

Date & time arithmetic

Looking over the ksh manual I can find no evidence that ksh93 can do datetime arithmetic. The "printf "%(%s)T" cited in the column "can be use to treat an argument as a date/time string and to format the date/time according to the date-format as defined for the date(1) command.". In other words it will parse argument string and reformat it according to the supplied format. No native date/time type and certainly no way to add or subtract months, minutes, years, weeks or otherwise, and no way to calculate date/time distances. In other words no date/time arithmetics. I am changing to "no".Useerup (talk) 13:13, 10 January 2010 (UTC)

Stream redirection

What is the difference between "Yes" and "arbitrary FDs"? Will someone please add a note to that row?

Also, I assume that "arbitrary fds" means "arbitrary file descriptors" only because Wikepedia doesn't have a relevant entry for "fds". If that is true, I suggest "arbitrary fd" or "arbitrary FD's" —Preceding unsigned comment added by 203.206.162.148 (talk) 07:20, 2 February 2010 (UTC)

In Bourne-derived shells, it is possible to redirect (or indeed open and close) arbitrary file descriptors. In the C shell and its derivatives, only descriptors 0, 1, and 2 can be redirected, and descriptor 2 can only be redirected simultaneously with descriptor 1 (the >& operator). 121a0012 (talk) 08:00, 15 November 2010 (UTC)

tcsh

The table says that tcsh does not have Implicit Directory Change - If command is dir name changes to it. But it does. It is enabled in the .tcshrc file with the 'implicitcd' option.

implicitcd (+)

If set, the shell treats a directory name typed as a command as though it were a request to change to that directory. If set to verbose, the change of directory is echoed to the standard output. This behavior is inhibited in non-interactive shell scripts, or for command strings with more than one word. Changing directory takes precedence over executing a like-named command, but it is done after alias substitutions. Tilde and variable expansions work as expected. —Preceding unsigned comment added by 187.105.140.115 (talk) 04:38, 23 June 2010 (UTC)

Rows like "binary prefix notation"

Considering you need one line* to have this, why is there even an own row?

* zsh: "prefix () { echo -n "2^"; echo $(( [#2] $1 )) | tr -cd '0' | wc -c }"

84.63.170.222 (talk) 23:56, 9 July 2010 (UTC)

PowerShell isn't platform-independent

The row "platform-independent" lists "Yes via Pash" for PowerShell. Pash isn't Powershell. This is like saying "NES games are platform independent because there are emulators available." Also, according to Wikipedia's own Pash article, Pash progress so far is:

• ~50% of public PowerShell classes defined.
• ~40% of framework functionality operational.

84.63.215.19 (talk) 00:21, 10 July 2010 (UTC)

Ok, made tentative corrections now. If someone knows how to better express the facts, shoot.

As an aside, this table is severely out of proportion. Someone impartial (i.e. not me) should prune it to stuff that isn't cherry-picked to display one's own favorite shell in the best light. 84.63.215.19 (talk) 13:30, 10 July 2010 (UTC)

Irrelevant information/ reduce size of table

This post is a continuation/combination of several previous topics

This table is far to large. It wont even display properly in my browser due to its size. I think the following changes should be made.

1. Lower the number of shells being discussed
   • We dont have to list every Unix shell. bash, csh, and ksh is enough to get the general idea across.
   • In the same vain, we don't need to list every windows shell. CMD.exe and PowerShell is enough
   • There is no need to list Python, Ruby, and other stand alone programming languages. Just list the top 2-3 for each major OS brand.(*nix, Windows, and Mac)
2. Lower the number of features discussed
   • We don't really need to include everything about each of these shells. For example, I think it's great that Scsh can do lambda functions, but it has no place in this article. That information can be discussed on the page for Scsh.
   • Important features to list are those that would separate the shells apart for a beginning user. Examples:
     1. Background information such as the usual environment(Posix, win32), license, and year created
     2. Platform Independence
     3. Unicode
     4. Functions
     5. Typing Discipline
     6. Pattern Matching
     7. Command History
     8. Whether or not arrays can be used, and whether or not arrays can be multidimensional
        • Array slicing may also be noteworthy.
     9. Aliases
     10. Ability to 'pipe' isn't import to list since all of them do it except BeanShell and RubyShell which shouldn't even be listed in this article.
         • Ability to comment and the ability to redirect streams should be left out also for the above reason.

P4lm0r3 (talk) 18:53, 11 August 2010 (UTC)

The table is certainly too big to be of any use. I also think that the "language" shells and more obscure shells should be removed or (language shells) moved into their own article. We could reference them here. Discussion of the remaining shells should focus on the areas where they differ or are interesting from some other perspective.

But it does raise the question of what exactly is the criteria for making it into this article? Prominence? Being default shell (or even distributed) with a prominent OS. It looks like we'll have to draw the line somewhere. Useerup (talk) 15:00, 19 August 2010 (UTC)

Sorry, but this idea that we remove established Unix shells such as tcsh and zsh just to keep the table manageable is just bonkers. Keep the table manageable by changing its formatting. For example, reverse the x and y axes and then split the list of features into several sections. That's how it's done on a variety of other comparison articles. Don't reinvent the wheel, just follow the best current practices. --Joy [shallot] (talk) 10:28, 20 August 2010 (UTC)

I was thinking more in the line of merging csh and tcsh into the same column. zsh certainly warrants its own column just because of its feature richness. It also is a current shell. Bash obviously because of it's pervasiveness. While I'm aware of other comparisons which have rotated the table, I really dislike that. It makes it hard to compare and hard to maintain. I would suggest a very compact table with the most prominent and current shells; each column really short and discussion/comments deferred to textual explanations below the table. I propose this:

Feature	bash	csh/tsch	ksh92t/pdksh	zsh	ash	PowerShell	cmd	VMS DCL

That would remove scsh, 4NT, command.com, 4DOS, OS/2 cmd.exe, rc and the "language" shells: beanshell, Python shell and Ruby shell from the table. We could still describe these in some other format Useerup (talk) 20:17, 20 August 2010 (UTC)

Again, no. I'll say it once again - reverse the x and y axes in the tables, and suddenly the "extra" shells stop being a problem. This article is in the same category with other comparison articles - have a look at some of them and see how it works. --Joy [shallot] (talk) 20:25, 20 August 2010 (UTC)

Ok, I see your point about the comparisons category. So if we were to clean this up we should rotate the table and split it into several tables, each with a grouping of topics. The table(s) will still be massive, so I still believe that we should consider

1. merging csh and tcsh which according to C_shell for all intents and purposes are the same (differences can be explained in cells)
2. merging cmd.exe (Windows, OS/2). Windows cmd.exe is a superset of the OS/2 one, superset can be explained in the relevant cells.
3. removing some of the non-current shells (DOS command.com, 4DOS)
4. moving the "language" shells into a separate topic.

On that note, what should we consider the criteria for inclusion as a command shell, when does it pass the notoriety test? I suggest the if that if any of the following is true it deserves to be here, otherwise not so much:

1. The shell is the default or commonly used shell for a common (current) operating system
2. The shell has historic value, e.g. it represents a milestone or a previous very popular shell
3. The shell is special in some way, especially if it builds on concepts not found in the other shells

Basically, if it is or was common enough that a lot of readers can relate to it, it is in. If it represent some achievement of historic interest, it is in. If it has something we can learn from it, it is in.

I'm willing to give the "big" modification a shot, but I have to know that my edits will not be reverted. Will this be acceptable? Useerup (talk) 11:58, 25 August 2010 (UTC)

Sorting Options

Many people coming to the page are only interested in comparing certain aspects to decide which to use. However, because the comparison table is multiple screens long, it is difficult for them to use it in this way since they cannot keep track of which column is which, so they find the page to be mostly useless. We need a way to allow the viewer to sort information and suppress what they don't need in order to increase utility.

This is a general comment applicable to all comparison articles. —Preceding unsigned comment added by 136.142.206.28 (talk) 22:44, 15 October 2010 (UTC)

Dash

Dash becoming the standard for some GNU/Linux releases (e.g. Debian 6.0 "Squeeze", replacing bash), it would be interesting to add it right after bash. Does anyone know some things to add for dash in the table? —Preceding unsigned comment added by 92.136.211.164 (talk) 20:23, 9 December 2010 (UTC)

dash is nothing more than Debian's private version of the Almquist shell ("ash"). Is there any reason to believe that it differs from the description of ash? 121a0012 (talk) 04:09, 11 December 2010 (UTC)

Proposed reorganization

I've created a draft at Talk:Comparison of command shells/Proposed reorganization which makes a stab at reorganizing the huge table into more manageable pieces. The "Programming features" table is still too long -- all of the tables should be transposed (one row per shell) but I'm out of energy for that tonight. Please have a go if you think you can organize it better. 121a0012 (talk) 05:09, 10 December 2010 (UTC)

I split up "Programming features" into three tables, and also added information about the Bourne shell. The tables still need to be transposed. 121a0012 (talk) 04:06, 11 December 2010 (UTC)

Hearing no comments on the proposed version, I copied it into the main article and have requested deletion of the temporary copy. The tables still need to be transposed. 121a0012 (talk) 22:48, 28 December 2010 (UTC)

Good job. Thanks 87.50.3.197 (talk) 11:19, 16 January 2011 (UTC)

Bourne Shell features

Ich someone believes that the Bourne Shell should not be described the way it currently behaves but the way it has been in 1977, I would like to see the description for the ksh from 1983 instead of the features for the ksh from today. As a hint: The Bourne Shell introduced job control in 1989, which is 22 years ago. So there have been only 12 years without job control and nearly twice as many years with job control in the Bourne Shell. --Schily (talk) 09:57, 21 January 2011 (UTC)

The Bourne shell (as written by Steve Bourne and introduced as the replacement for the Thompson shell in Seventh Edition Unix) is a historical relic. I added that column to show the ancestral condition of the other shells in that part of the table. Perhaps it is worth showing the System V shell as well, although I think it's already long enough. The relevance of the Bourne shell in this table is precisely the features that it lacked and were added in later implementations, particularly the contrast between it and the C shell, which was the first Unix shell to introduce job control, aliases, and so on. For all other purposes, the POSIX shell is a more useful point of comparison, since it is the current standard and nearly all modern Bourne-like shells implement it as their baseline. 121a0012 (talk) 15:44, 21 January 2011 (UTC)

If you like to see a list of features for the Bourne Shell that have been available in 1977, then feel free to create two columns for the Bourne Shell: One for the version from 1977 and anotherone for the current state. But if you do this, please create at least 3 columns for ksh, as ksh in 1983 did e.g. lack command line editing and many other things (ksh started AFAIK from the Bourne Shell sources) that have been added later. There is also ksh88 besides ksh93. --Schily (talk) 17:50, 21 January 2011 (UTC)

Sounds like a total waste of time to me. I know you're a big Solaris fan, but I have yet to be convinced that the "Bourne shell" column should describe the System V shell. Please provide a stronger, objective argument for its relevance. (As for ksh, recall that the POSIX shell was based largely on ksh; are there meaningful differences between POSIX and historical ksh in categories covered by this chart?) 121a0012 (talk) 03:32, 22 January 2011 (UTC)

Seems like deja vu all over again. I agree with 121a0012 and feel like I've had this same conversation myself with Schily. Actually, I have, here and here. I wouldn't be surprised to learn Schily is right, that Bourne shell code has continued to evolve and is much better than many imagine. But a chart where year of introduction is so prominent is not the place to do that. Here, the purpose should be to allow readers to see the history aspect of what influenced what and where features first appeared. I think the place to document that today's Bourne shell is way better than ever (assuming that's true and can be verified) is probably in a new section in the Bourne shell article, documenting the release history. It doesn't belong here. Msnicki (talk) 22:39, 22 January 2011 (UTC)

If the year of introduction is so important, then the ksh listing is wrong. A table only makes sense, if it contains comparable content for the various members. With this background, the Bourne Shell listing is wrong. If someone likes to add another column for the historical state of the Bourne Shell in 1977, feel free to do the work. --Schily (talk) 17:59, 31 January 2011 (UTC)

I was the one who posted that date for ksh along with the citations for it. But if you think the date's incorrect and you've got better citations that prove it, be bold. Msnicki (talk) 01:26, 1 February 2011 (UTC)

I am interested in a table that uses similar assumptions for all columns. This is definitely not the case for Bourne Shell vs. Korn Shell. ksh started in 1983, history editing was introduced in 1984, there is ksh88 and ksh93. While ksh93 is from 1993, ksh93t is from 2010. In case you don't know the history: It did take David Korn a long time to get the permission from AT&T to make ksh OSS. He told me that the permission is only for ksh93, so there will be no new name and the name ksh93 will prbably stay for ever even though e.g. ksh93t is a very different product than ksh93. In case that this table continues to list ksh93t for ksh, we definitely need to describe the current stage of the Bourne Shell which is very different from what the table currently says. --Schily (talk) 10:00, 1 February 2011 (UTC)

For what it's worth, I agree that (for consistency) the ksh column should not describe the very most recent version of ksh93 but rather, the common base of features that all ksh93 installations have. If there are any particularly notable features added in recent versions of ksh93, they should be either relegated to footnotes, or noted in the table as "{{yes|since VERSION}}" or "{{yes|since DATE}}". There are probably parts of the description of the POSIX shell that require the same treatment. 121a0012 (talk) 22:04, 1 February 2011 (UTC)

I could live with that but I think it's more useful, especially for showing how thought evolved and how one shell influenced the next, if the columns describe the shells more-or-less as they existed when introduced. I'm pretty sure David Korn announced his ksh shell in 1983 and I gave the citations. It seems entirely possible that he didn't add history editing 'till 1984 but so what? How many people ever saw the build that didn't have it? And how much time elapsed in between? At most, we're talking a few months and, likely enough, a continuous development activity in between by the original author. By contrast, Schily reports that job control was added to the Bourne shell in 1989. But that was 12 years after its introduction and it seems unlikely that it resulted from a continuous development effort by Steve Bourne that whole time. The two situations don't seem comparable to me. Msnicki (talk) 00:21, 2 February 2011 (UTC)

Or in other words, the Bourne Shell includes e.g. functions and aliases since 29 years and job control since 22 years. I doubt that more than very few peope still remember how the Bourne Shell behaved in 1977 or are able to test it's historical behavior today. The last OS that shipped the old Bourne Shell was NextStep and that died in the 1990s. I ask for equal rules for all shells in the table, otherwise it does not allow to compare. --Schily (talk) 10:04, 2 February 2011 (UTC)

Can you live with 121a0012's idea? Msnicki (talk) 03:54, 4 February 2011 (UTC)

Not one entry for only one of the other shells needs to be changed in order to make the able consistent, but the entry for the Bourne Shell. If you still like to explain what the features of the original Bourne Shell have been in 1977, you may add another column for that state. --Schily (talk) 09:44, 4 February 2011 (UTC)

Why no "Usually invoked" For PowerShell?

Why "Usually invoked" for PowerShell is "?" ?, type 'powershell' in to cmd and see PowerShell run.

ECat200 (talk) 18:52, 30 January 2011 (UTC)

Not everyone uses Windows. The editor who added that row to the table, for one. Please edit the table if you are certain of this. 121a0012 (talk) 03:16, 31 January 2011 (UTC)

Dash needs to be added

Dash has replaced bash as the init start-up shell in Debian Linux, since Squeeze. Reasons I have heard refer to Dash requiring fewer resources than Bash. Since (apparently) the additional features in Bash are not required it has been removed from use as the default interpreter. The symlink that associated /bin/sh with /bin/bash, is now a symlink to /bin/dash. (There is a symlink from /bin/sh.distrib to /bin/bash.) Kernel.package (talk) 03:58, 25 February 2011 (UTC)

dash is just Debian's version of ash, which is already listed. Unless they differ significantly in details covered by this article, it should not be added. 121a0012 (talk) 04:24, 11 March 2011 (UTC)

External links modified

Hello fellow Wikipedians,

I have just added archive links to one external link on Comparison of command shells. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

• Added archive https://web.archive.org/20130308014436/http://ridiculousfish.com:80/shell/user_doc/html/index.html to http://ridiculousfish.com/shell/user_doc/html/index.html#completion

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

Y An editor has reviewed this edit and fixed any errors that were found.

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 09:44, 10 January 2016 (UTC)

I have replaced the archive URL by the new official URL. Vincent Lefèvre (talk) 16:01, 10 January 2016 (UTC)