Talk:Comparison of computer shells

From Wikipedia, the free encyclopedia

 This article is within the scope of Computing WikiProject, an attempt to build a comprehensive and detailed guide to computers and computing. If you would like to participate, you can edit the article attached to this page, or visit the project page, where you can join the project and/or contribute to the discussion.
??? This article has not yet received a rating on the quality scale.
??? This article has not yet received an rating on the importance scale.

Contents

[edit] bash vs cmd is pointless. But can be made useful

i agree: this comparison is pointless. ksh vs zsh vs bash vs whatsoever would be more useful.

no it's useful

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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] irrelevant features compared

Alfps 07:53, 7 July 2006 (UTC): 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.

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)

[edit] 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.

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)

[edit] Unicode

What do you mean on limited unicode support in Powershell?

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)

[edit] 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. 18:50, 29 September 2006
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. 12:50, 03 October 2006
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. 25 april 2008 —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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] "Filters"

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

[edit] 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?

[edit] 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.

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.

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] "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.

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!
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. --some dude.
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?
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.
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)
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
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)

[edit] Native CIM/WBEM support

In what sense does PS implement CIM/WBEM support?

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

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.

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 this row be removed? --NealMcB 03:45, 27 July 2007 (UTC)

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.
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)

[edit] 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)

[edit] 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)

[edit] 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).

[edit] 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)

[edit] 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)

[edit] 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?

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)

[edit] 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)

[edit] 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}
   ...
 }

[edit] "Aliases" in CMD.EXE

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)

[edit] 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)

[edit] 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)