Talk:Comparison of command shells: Difference between revisions

Revision as of 13:30, 10 July 2010

Latest revision as of 14:40, 26 April 2025

(308 intermediate revisions by 64 users not shown)

Line 1:

{{WikiProject Computingbanner shell|class=List|importance=|software=yes|software-importance=}}

{{WikiProject Software |importance=Low}}

{{WikiProject Linux |importance=Mid}}

}}

{{archive box|

* [[/Archive 1]]

* [[/Archive 2]]

}}

==What about safety?==

== Pointless Article ==

''Safety'' is for protecting the user against his own clumsiness (as opposed to ''security'', which is for protecting the system against malevolent users).

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. {{unsigned-r|2005-03-12T05:22:44|193.91.90.242}}

A few safety features of Fish I've stumbled upon:

* Variable in the zero'th argument: Fish refuses to execute the result of a variable expansion, unless adding the ''eval'' keyword. This can prevent the user from accidentally executing an incomplete command line.

* Unmatched glob (e.g. touch *.c): This is an error in Fish; the example would not have executed touch at all. Contrast this to Bash, which thinks it's okay to pass the unmatched glob literally, which would cause touch to create a literal *.c file in this example. Alternatively, bash can be told to expand unmatched globs to zero arguments (shopt -s nullglob), which would cause touch to barf in this example.

* Sanity checked environment variables: Fish warns when adding a nonexisting path to $PATH. <span style="font-size: smaller;" class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/84.209.119.158|84.209.119.158]] ([[User talk:84.209.119.158|talk]]) 19:48, 5 August 2014 (UTC)</span><!-- Template:Unsigned IP --> <!--Autosigned by SineBot-->

::I agree about the unmatched glob: replacing it by the literal is probably the most stupid POSIX feature (and that's why Bash does that). Zsh regards this as an error by default.

::But concerning the addition of a nonexisting path to $PATH, I disagree: in setups where several machines are involved (e.g. NFS on an heterogeneous network), this can occur for good reasons. Having such a check as an option is fine, however it is easy to write a function to do the same thing.

::Zsh has other safety features: sh word-splitting is disabled by default (arrays make it unnecessary); and <code>[[</code> compound command, which avoids the ambiguities of the <code>test</code> command.

::[[User:Vincent Lefèvre|Vincent Lefèvre]] ([[User talk:Vincent Lefèvre|talk]]) 22:39, 5 August 2014 (UTC)

== Many feature issues ==

: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. --[[User:Whiteknox|Whiteknox]] 14:09, 25 August 2006 (UTC)

''Non-path/file argument completion'' is just as well supported by Bash/Zsh as PowerShell - Everything built-in is supported by the original developers, and everything third-party ''may'' be supported by that third-party developer. Or is anyone saying that PowerShell magically creates argument completion from third-party packages?

::Commented out old comment {{unsigned-r|2006-11-15T17:51:46|Stevage}}

''Wildcard completion'' is not explained - The word "wildcard" is not mentioned anywhere in the linked section. And if TAB-completion of [[Glob_(programming)|glob patterns]] is meant, that is supported at least as far back as Bash 3.0 (2004). Try for example <code>cd /[e]*&lt;tab&gt;</code>.

== bash vs cmd is pointless ==

''Directory history'' is another feature which has been supported since at least Bash 3.0 - Try <code>cd -</code> and <code>pushd</code>/<code>popd</code>.

i agree: this comparison is pointless. ksh vs zsh vs bash vs whatsoever would be more useful. {{unsigned-r|2005-06-08T10:20:08|213.235.241.194}}

Looks like another case of rampant fanboyism. ''If you don't know whether a shell supports a feature, you have to indicate that with a question mark ('''?''')! Setting it to '''No''' detracts from the usefulness of this wiki.''

:no it's useful {{unsigned-r|2005-06-14T23:10:01|83.171.212.51}}

I think we can all agree that every popular shell out there has literally thousands of features, and as such this page will have to be incomplete to be useful. Choosing which features to compare should be the main job of the editors here.

:: 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. [[User:Cema|Cema]] 06:39, 25 February 2006 (UTC)

[[User:Engmark|l0b0]] ([[User talk:Engmark|talk]]) 12:08, 11 April 2013 (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.

:'' Or is anyone saying that PowerShell magically creates argument completion from third-party packages? '' Yes. Not magically, but at least PowerShell ''automatically'' generate completions for any cmdlet, function or script. Cmdlets, func

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

:Fixed "wildcard completion" for bash and zsh. [[User:Useerup|Useerup]] ([[User talk:Useerup|talk]]) 11:38, 10 May 2013 (UTC)

:::* 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. [[User:Falcotron|Falcotron]] 01:57, 8 July 2006 (UTC)

:I agree about the "Directory history" point. Zsh is another that has <code>pushd</code>/<code>popd</code>, and I'm wouldn't be surprised if there are many more on that list. [[User:Yb2|Yb2]] ([[User talk:Yb2|talk]]) 02:54, 24 May 2013 (UTC)

== Job control ==

::pushd and popd do not constitute directory history, they implement a directory ''stack''. Also pushd and popd are not interactive features. Directory history is when the shell automatically keeps a history list of visited directories akin to the way many shells automatically keep a history list of entered commands. Look at fish, it has an automatic directory history ''as well as'' directory stacks. I'm sure we could fit in directory stack somewhere in a table, it's just not an interactive feature as it also works for scripts (where history would be unreliable). [[User:Useerup|Useerup]] ([[User talk:Useerup|talk]]) 06:26, 25 May 2013 (UTC)

Is this correct to have "no" under cmd.exe? The "AT" command schedules jobs for NT-based OSes. [[User:Zoney|'''zoney''']] <font size=+1 style="color:green;">&#09827;</font> [[User talk:Zoney|'''talk''']] 12:09, 9 November 2005 (UTC)

== Reopen of "Python and Ruby Shells?" discussion ==

: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). [[User:Zoney|'''zoney''']] <font size=+1 style="color:green;">&#09827;</font> [[User talk:Zoney|'''talk''']] 15:21, 15 November 2005 (UTC)

I've just found the section

:Ah - furthermore, there's a more complicated task scheduling tool in the cmd shell - SCHTASKS, which supersedes AT. Type "schtasks /?" at the command prompt. [[User:Zoney|'''zoney''']] <font size=+1 style="color:green;">&#09827;</font> [[User talk:Zoney|'''talk''']] 12:42, 16 November 2005 (UTC)

[http://en.wikipedia.org/wiki/Talk:Comparison_of_command_shells/Archive_1#Python_and_Ruby_Shells.3F]

which doesn't ever to have seemed to have been resolved.

While I'm a fan of Python, I really don't think the Python shell belongs here. Sure you can do some nice admin type stuff (os.walk spring to mind), but the Python shell is not a command shell. Similarly the Ruby shell. As previously discussed, they are programming environments, not command shells.

::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. [[User:Falcotron|Falcotron]] 01:20, 8 July 2006 (UTC)

Are there any significant points I've missed?

:::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? [[Special:Contributions/203.206.162.148|203.206.162.148]] ([[User talk:203.206.162.148|talk]]) 08:53, 9 June 2009 (UTC)

Any great objections to me removing those shells from this page?

::::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)]]. [[User:Ghettoblaster|Ghettoblaster]] ([[User talk: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:

[[User:Peterl|peterl]] ([[User talk:Peterl|talk]]) 13:10, 27 June 2013 (UTC)

:::::(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.[[Special:Contributions/203.206.162.148|203.206.162.148]] ([[User talk:203.206.162.148|talk]]) 06:25, 2 February 2010 (UTC)

:Agreed --[[User:Useerup|Useerup]] ([[User talk:Useerup|talk]]) 23:51, 28 June 2013 (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. [[User:Zoney|'''zoney''']] <font size=+1 style="color:green;">&#09827;</font> [[User talk:Zoney|'''talk''']] 15:25, 15 November 2005 (UTC)

::Actually, [[IPython]], being a generic shell, probably should be here. [[Special:Contributions/50.53.15.59|50.53.15.59]] ([[User talk:50.53.15.59|talk]]) 11:51, 18 April 2014 (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. [[User:Falcotron|Falcotron]] 01:57, 8 July 2006 (UTC)

== Should POSIX shell be removed from comparison? ==

::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". [[User:Alfps|Alfps]] 11:06, 8 July 2006 (UTC)

The "POSIX shell" is just a standard and not an actual piece of software, right? If so, should it be removed? I'm leaning toward "yes" since, per the article, "A command shell is a command line interface computer ''program''" (emphasis mine). [[User:Proxyma|Proxyma]] ([[User talk:Proxyma|talk]]) 02:50, 9 August 2013 (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). [[User:Falcotron|Falcotron]] 19:53, 11 July 2006 (UTC)

:I would like to remove it too. It is not a real shell (real as in ''realized'' in e.g. sh). [[User:Useerup|Useerup]] ([[User talk:Useerup|talk]]) 05:56, 9 August 2013 (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.<small><br>—[[User:Brian Patrie|überRegenbogen]] ([[User talk:Brian Patrie|talk]]) 01:54, 9 April 2009 (UTC),</small>.

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. <span style="font-size: smaller;" class="autosigned">—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/203.206.162.148|203.206.162.148]] ([[User talk:203.206.162.148|talk]]) 06:34, 2 February 2010 (UTC)</span><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->

::It isn't a real shell, but can be regarded as a class of (real or not) shells (common features supported by these shells). IMHO, information related to it is useful. This can also give an idea about shells that claim to be POSIX-compliant but are not listed here (e.g., dash). [[User:Vincent Lefèvre|Vincent Lefèvre]] ([[User talk:Vincent Lefèvre|talk]]) 00:51, 30 October 2013 (UTC)

== Subroutines ==

:::Given that it would be of far too great a scope to list and compare the details of every POSIX implementation of sh, I agree, the entry serves both a practical and relevant purpose. [[User:ArabOrange|ArabOrange]] ([[User talk:ArabOrange|talk]]) 15:15, 14 October 2021 (UTC)

Does the "Call" command available in cmd.exe not fit into this category? [[User:Zoney|'''zoney''']] <span style="color:green; font-size:larger"> &#09827;</span> [[User talk:Zoney|'''talk''']] 12:44, 16 November 2005 (UTC)

== PowerShell advertising copy ==

: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. [[User:Falcotron|Falcotron]] 01:57, 8 July 2006 (UTC)

In addition to the "General Characteristics" section above which discusses two columns that were only "yes" for PowerShell (one of which has thankfully been removed), there are also three columns in the "Interactive Features" table that are only true for PowerShell. In addition, PowerShell is mentioned 53 times on the page, compared to for example 16 for Bash. In total, these make this page feel more like advertising copy for PowerShell than a genuine comparison of shells. I propose that we separate the non-platform-independent shells from the platform independent ones to make it easier for people who will never actually use the single platform PowerShell supports to find the information they're looking for --[[User:Sean r lynch|Sean r lynch]] ([[User talk:Sean r lynch|talk]]) 04:37, 4 October 2013 (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. [[User:Alfps|Alfps]] 11:00, 8 July 2006 (UTC)

Geez, and I hadn't even gotten to the ridiculous "security features" section, with a table only two columns of which are "yes" for any shell other than PowerShell. That's just abusive. I don't see how anyone who's even slightly objective can look at this page and think that it's remotely balanced. I'd edit it, but I'm not nearly as motivated as the PowerShell fanatics clearly are. --[[User:Sean r lynch|Sean r lynch]] ([[User talk:Sean r lynch|talk]]) 04:55, 4 October 2013 (UTC)

Example:

:Agreed - it's apparent that [[WP:SPA|single-purpose authors]] have more time than anyone else. [[User:Tedickey|TEDickey]] ([[User talk:Tedickey|talk]]) 08:57, 4 October 2013 (UTC)

@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

::[[User:Alfps|Alfps]] 15:00, 8 July 2006 (UTC)

::Agreed. [[User:Hopugop|Hopugop]] ([[User talk:Hopugop|talk]]) 15:18, 13 October 2013 (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''). <br> [[User:Armslurp|Armslurp]] 02:44, 27 April 2007 (UTC)

:If one shell is advancing the art and the others aren't, pointing that out doesn't seem like "advertising copy" it seems exactly like what a comparsion of command shells page is useful to understand. How are you thinking about it? [[User:Jsnover|Jsnover]] ([[User talk:Jsnover|talk]]) 03:17, 26 October 2013 (UTC)

== Find and replace on variables in cmd.exe ==

:For example, "Workflow" as a bare assertion without relating it to the state of the art in command-shells, is merely advertising jargon [[User:Tedickey|TEDickey]] ([[User talk:Tedickey|talk]]) 10:03, 26 October 2013 (UTC)

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:

::That makes perfect sense. Would a solution be to have a short paragraph of what is meant by the category and how it relates to command-shells? [[User:Jsnover|Jsnover]] ([[User talk:Jsnover|talk]]) 17:38, 26 October 2013 (UTC)

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.

:perhaps, taking into account relevant guidelines such as [[WP:RS]], [[WP:FRINGE]], [[WP:OR]] [[User:Tedickey|TEDickey]] ([[User talk:Tedickey|talk]]) 22:22, 26 October 2013 (UTC)

[[User:Zoney|'''zoney''']] <span style="color:green; font-size:larger"> &#09827;</span> [[User talk:Zoney|'''talk''']] 12:54, 17 November 2005 (UTC)

::Thanks for the pointers - I was unaware of these. I'll educate myself. [[User:Jsnover|Jsnover]] ([[User talk:Jsnover|talk]]) 15:54, 27 October 2013 (UTC)

== irrelevant features compared ==

:::Also, if you are the [http://www.jsnover.com Jsnover] I am thinking of (and your cordial style leads me to think so), you may also want to consider [[WP:COI]]. It is not that you wouldn't be able to edit the article, but you would have to do so very carefully and be prepared to be challenged. If you are indeed the big gun Jsnover you may be more valuable as a primary source on PowerShell than as an editor of a comparison article. For instance, we would value your input on where you do not think PowerShell has a feature (e.g. does PowerShell allow TCP connections as streams?) [[User:Useerup|Useerup]] ([[User talk:Useerup|talk]]) 16:11, 28 October 2013 (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. {{unsigned-r|2006-07-07T02:45:09|Alfps}}

::::Thanks for pointing that out. I don't know about big guns but I am the architect of PowerShell. I've been nervous about making edits because I respect the integrity of Wikipedia and would never want to do anything that called it into question. This thread has prompted me to start getting educated about how to do Wikipedia right. I'll defer from making any more edits until I have a chance to absorb the COI and am sure I know the rules of the road. Thanks and please don't ever hesitate to point out if I get it wrong. [[User:Jsnover|Jsnover]] ([[User talk:Jsnover|talk]]) 01:53, 29 October 2013 (UTC)

: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. [[User:Falcotron|Falcotron]] 01:57, 8 July 2006 (UTC)

:::::Please note that [[WP:COI]] does *not* apply to talk pages - as long as you are transparent about who you are and your role. Given your established expertise on command shells, your input on talk pages would certainly be valuable (very!). This is a comparison article and as such it is already in slightly controversial territory, so I would recommend against you making direct changes to the page. However, if you spot errors, please do not hesitate to point them out here on the talk page.[[User:Useerup|Useerup]] ([[User talk:Useerup|talk]]) 16:54, 29 October 2013 (UTC)

As a neutral passer-by with working knowledge of csh, bash, cmd.exe, and powershell, I have to say this article very obviously reads like an ad for powershell:

== Python and Ruby Shells? ==

* Obvious marketing weasel words and phrases including references to non-powershell shells as "traditional", feature lists ending with "...and more" or "...etc".

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.<br />

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). [[User:Falcotron|Falcotron]] 20:38, 19 July 2006 (UTC)

* The "feature" sections are obviously cherry-picked powershell-only idiosyncrasies, and follow a "them vs. us" advertising pattern of beginning with vague, generalised descriptions of how "a shell" or "shells" or "the linux/unix shell" work followed by lots of upbeat powershell-specific detail making it out to be special and better.

== Unicode ==

* An entire Automatic Suggestions section -- separate from the Completions section, and complete with its own animated gif -- just to promote the fact that, in a particular IDE, powershell displays a dropdown list of options during completion, and then even uses a Microsoft brand name to refer to the feature.

What do you mean on limited unicode support in Powershell? {{unsigned-r|2006-08-07T09:47:14|81.182.88.142}}

* On that note, IDE features in an article about shells? Seriously, "Snippets"? Come on.

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). [[User:Gisburn|Gisburn]] 02:30, 4 July 2007 (UTC)

I know and use powershell and agree that it's great and should be included on this page. Perhaps there should even be a separate Powershell section pointing out some of its unique idiosyncrasies, although that's maybe more appropriate on the actual Powershell article. Regardless, this article as it stands is nothing but an ad. [[Special:Contributions/203.28.14.129|203.28.14.129]] ([[User talk:203.28.14.129|talk]]) 02:40, 25 September 2014 (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) <small>—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/82.241.8.181|82.241.8.181]] ([[User talk:82.241.8.181|talk]]) </small><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->

I've removed some of the obvious powershell advertisements but there is still a lot left. I encourage any better writer than me to clean it up farther. I've removed some sections (e.g. "native" CIM/WBEM; obviously trying to move the goalposts from CIM/WBEM by specifying it must be completely native, and nonetheless it's a very strange feature to expect from a shell. I doubt anyone came to this article looking for comparisons of CIM/WBEM support between different shells). I've merged some sections (PS had 3 sections on how it blocked untrusted scripts, and "snippets" is clearly part of the IDE that it advertises as one of its features). [[Special:Contributions/80.189.144.187|80.189.144.187]] ([[User talk:80.189.144.187|talk]]) 23:23, 17 July 2015 (UTC)

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. [[User:Jsnover|Jsnover]] ([[User talk:Jsnover|talk]]) 20:11, 29 November 2009 (UTC)

:IMHO, "Progress indicator" is another PowerShell advertisement. Under Unix, I don't see any reason why it would be related to the shell. A command that can provide progress information can always output it to the terminal directly (when connected to the terminal) or output such information in another way (e.g. in a graphical dialog box). [[User:Vincent Lefèvre|Vincent Lefèvre]] ([[User talk:Vincent Lefèvre|talk]]) 00:19, 18 July 2015 (UTC)

== Fair comparisation? ==

::Agreed with the progress indicator. `pv` and `zenity` are examples of how you'd get a progress indicator done traditionally, and that's using an external process. I think advertising it as a function of the shell is a little disingenuous when it's just "not done that way" in other shells. If someone sticks a web browser in a shell then adds "HTML5 Support" "Flash Support" "Javascript Support" "DOM manipulation" (...) to the table because their shell supports it, it doesn't make it a "shell feature" if you see what I mean there, and I think this is what's been done (but in a subtler way) with PowerShell. [[Special:Contributions/80.189.144.187|80.189.144.187]] ([[User talk:80.189.144.187|talk]]) 11:38, 18 July 2015 (UTC)

:: Agreed. Many of the features on this page are either biased towards PowerShell, or so oddly defined as to be nonsensical. For example, in the `Programming Features' section, Bash is listed as being unable to do Arithmetic -- and yet echo $[2+2] (a shell builtin) returns 4. Admittedly it's only integer arithmetic, but still. I have no idea why this is missing. Likewise, in the comparison of features section, Syntax highlighting is listed as being "no" for everything except PowerShell "(In ISE)". This is like writing "Yes (In Vim)" by Bash, or anything else you care to mention. It's also the case that one can define syntax highlight quite easily in most of the UNIX shells, if desired. It's just not enabled by default at the prompt. This article needs attention. [[Special:Contributions/81.110.99.109|81.110.99.109]] ([[User talk:81.110.99.109|talk]]) 21:57, 19 September 2015 (UTC)

::: For Bash, it is said Yes concerning Arithmetic. [[User:Vincent Lefèvre|Vincent Lefèvre]] ([[User talk:Vincent Lefèvre|talk]]) 00:06, 20 September 2015 (UTC)

::No, PowerShell has a separate channel for conveying progress information. Think distinction between stdout and stderr in Unix. Rather than the 2 from the OS, PowerShell has Success output, Errors, Warning messages, Verbose output, Debug messages and information messages. The shell has special support for displaying the progress messages semi-graphically and to avoid polluting the regular output with the progress messages. If you write <tt>Write-Progress "Creating users"</tt> the shell will display a box with the text "Creating user. Processing" along with a progress bar. It will be displayed until another progress message is displayed, or until the script ends, at which point the message will disappear. This will work across remote connections as well a for background jobs, i.e. the progress messages are not just output to an output stream, rather they are marshalled to the ultimate controlling interactive shell and used to display progress information there. Given that command shells are often used to create long running scripts - even spanning multiple hosts or managing multiple background jobs - the ability to marshal back reliable progress information as it happens is clearly a valuable feature. [[Special:Contributions/91.199.208.219|91.199.208.219]] ([[User talk:91.199.208.219|talk]]) 05:37, 5 August 2015 (UTC)

:::Under Unix, one can use file descriptors other than 0 (stdin), 1 (stdout) or 2 (stderr), so that progress information can be sent wherever one wishes (this can be done without any interaction at all). Shells with arbitrary stream redirections (e.g. POSIX shells and compatible/enhanced) will have no issues; the other ones may be more limited. When the shell script runs in a terminal, it is also possible to use terminal escape sequences (but one needs to make sure that no processes output data to the terminal in the background at the same time). So I don't see what is missing (at least for the modern Unix shells), given the fact that depending on the context, one can choose the most convenient solution. — [[User:Vincent Lefèvre|Vincent Lefèvre]] ([[User talk:Vincent Lefèvre|talk]]) 17:41, 23 February 2021 (UTC)

::::And there are other convenient ways to pass information without having to use the standard output (stdout) or error (stderr) stream of the shell script, for instance [[named pipe]]s (e.g. with the POSIX <code>mkfifo</code> command). So a shell script can use one to pass progress information, and the progress indicator program can read such information from this named pipe. See also various solutions proposed on ''Stack Overflow'' in [https://stackoverflow.com/questions/238073/how-to-add-a-progress-bar-to-a-shell-script ''How to add a progress bar to a shell script?''] (not all of them work under any conditions). Remember that Unix shells can be run from anywhere: with or without a text terminal, with or without a graphical interface..., so that there cannot be a single interface for progress information. — [[User:Vincent Lefèvre|Vincent Lefèvre]] ([[User talk:Vincent Lefèvre|talk]]) 18:35, 23 February 2021 (UTC)

:For Unix shells, "Untrusted script blocking" should probably change from "No" to "N/A" (ditto concerning "Execute permission" with a change from "Yes" to "N/A") because these are not shell features and blocking the execution isn't even permitted at this level. In any case, permission control is better done upstream, e.g. at the kernel level, in particular because this could be implemented only once and this is not specific to scripts. [[User:Vincent Lefèvre|Vincent Lefèvre]] ([[User talk:Vincent Lefèvre|talk]]) 00:45, 18 July 2015 (UTC)

== The main problem ==

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... --[[User:PSIplus|PSIplus]] [[User_talk:PSIplus|&Psi;]] 00:15, 25 September 2006 (UTC)

Most of the discussions on here seem to focus on one specific issue: the article structure seems to be written to favor PowerShell. This is certainly a valid concern, but it isn't the root of the problem. This article's flaw is that it fails to incorporate the [[Unix_philosophy|Unix design philosphy]] in any way. The reason PowerShell seems so much more robust (or the apparent reason) is because Unix shells are only written to do as much as they need to, allowing the more abstract and complex tasks to be performed by external programs. PowerShell needs to be able to do more because it doesn't have the external support Unix shells have.<br />

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

This should be noted in some way. I think it would be best to mention it at the top of the article, and pehaps it could be noted in the table where a common external program exists for the purpose (where common is defined as being installed by default on a certain number of flavors of Unix or something that is installed on a large number of Unix machines, the secure prompt field on the security table being a very good example). [[User:KamikazeScotsman|KamikazeScotsman]] ([[User talk:KamikazeScotsman|talk]]) 16:38, 6 November 2013 (UTC)

: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. [[User:Ahy1|Ahy1]] 16:16, 25 September 2006 (UTC)

:Valid point. If some shells have built-in support for a certain feature and other (Unix?) shells do not, but is commonly distributed alongside tools that provide such feature, it does seem fair to mention that. If we then also explained in note/text the difference, it would probably make the article more interesting as well. As long as we do not start to introduce more exotic external tools I'm all for it. [[User:Useerup|Useerup]] ([[User talk:Useerup|talk]]) 21:21, 6 November 2013 (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. {{unsigned-r|2006-09-29T11:52:18|84.140.45.217}}

::Actually, there is a clear UNIX bias to this article, right from the wording in the article title. --[[Special:Contributions/80.216.243.49|80.216.243.49]] ([[User talk:80.216.243.49|talk]]) 12:34, 10 February 2014 (UTC)

::: 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. [[User:Ahy1|Ahy1]] 11:56, 1 October 2006 (UTC)

== Market share ==

:::: 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. {{unsigned-r|2006-10-03T05:53:35|84.140.13.23}}

It would be interesting to know what kind of market share the various shells have, whether that's coming as the default for a particular operating system distribution, being chosen as the scripting language for a certain percentage of projects posted on a popular download site, job listings requesting that particular language as a skill, etc. -- [[User:Beland|Beland]] ([[User talk:Beland|talk]]) 15:15, 1 February 2014 (UTC)

::::: 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... --[[User:PSIplus|PSIplus]] [[User_talk:PSIplus|&Psi;]] 00:48, 7 November 2006 (UTC)

== What is "console redirection"? ==

::::: 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 ;-) --[[User:PSIplus|PSIplus]] [[User_talk:PSIplus|&Psi;]] 00:56, 7 November 2006 (UTC)

And how is this different than i/o stream redirection? Whoever added this column failed to add any indication what they meant. My guess (only a guess) is this is asking whether the given shell can be run with stdio redirected to a serial port, which all Unix shells can do. Is there something more interesting being asked here? [[User:Msnicki|Msnicki]] ([[User talk:Msnicki|talk]]) 23:29, 15 July 2014 (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. <small>—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[User:Nathan Dbb|Nathan Dbb]] ([[User talk:Nathan Dbb|talk]] • [[Special:Contributions/Nathan Dbb|contribs]]) 21:40, 25 April 2008 (UTC)</small><!-- Template:Unsigned --> <!--Autosigned by SineBot-->

: Basically yes. I added it as an extra property, because not all shells support it. It is "interesting", because some of the spartanity (like: no popup menus, no colors, no filename completion) of COMMAND.COM can be explained by it supporting this in the DOS environment with its very limited terminal control capabilities. In some of the discussions above it was proposed to illustrate the various shell capabilities also in the context of their different runtime environments and architectural differences. --[[User:Matthiaspaul|Matthiaspaul]] ([[User talk:Matthiaspaul|talk]]) 03:26, 16 July 2014 (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 ([http://blogs.msdn.com/powershell/archive/2008/02/10/the-semantic-gap.aspx]). In fact, Microsoft would have been really stupid not to take the best of both worlds (e.g. [[Korn shell|ksh]] and [[cmd.exe]]) and add some more useful features/ideas from other successful environments such as [[.NET]], [[DIGITAL Command Language|DCL]], [[Perl]], [[Ruby (programming language)|Ruby]]/[[Lisp (programming language)|LISP]], [[AS/400 Control Language|CL]], [[SQL]], ... [[User:Ghettoblaster|Ghettoblaster]] ([[User talk:Ghettoblaster|talk]]) 20:13, 28 April 2008 (UTC)

:: Then it seems to be apropriate to chose a different headline. I am still not sure whether I understand what you intend to say, but if you like to say that the typical interactice I/O can be any open file and not only a systemwide dedicated console, then I would propose to use something like "Pty aware" and to make it an explaning link into a section of this article. [[User:Schily|Schily]] ([[User talk:Schily|talk]]) 09:27, 16 July 2014 (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! [[Special:Contributions/81.174.174.31|81.174.174.31]] ([[User talk:81.174.174.31|talk]]) 22:06, 21 July 2009 (UTC)

::: No, an open file won't work, but any character device supporting both input and output will do. By default, STDIN, STDOUT and STDERR will be connected to the CON: device, but by giving the device name as a parameter on startup (<tt>COMMAND.COM COM1:</tt>) or using the <tt>CTTY COM1:</tt> command, you could attach the shell to, for example, a serial port. In the DOS world, this is typically known as "console redirection".

::: "Pty awareness" would be a related but still a different property.

::: Yes, an explanation can be added in the future.

::: --[[User:Matthiaspaul|Matthiaspaul]] ([[User talk:Matthiaspaul|talk]]) 11:27, 16 July 2014 (UTC)

== Used in POSIX environment ==

== Beanshell ==

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. [[User Talk:Stevage|Stevage]] 23:30, 15 November 2006 (UTC)

Should beanshell be included at all? This is after all a "Comparison of command shells", and beanshell seems to be more of an attempt at a Java REPL than a shell. One could easily include python as a shell under such a loose definition of "command shell". Its [[BeanShell|wiki page]] refers to it as a "Java-like scripting language" rather than a shell, and its [http://www.beanshell.org/ official website] calls it "Lightweight Scripting for Java" and states that "BeanShell is dynamically interpreted Java, plus a scripting language and flexible environment all rolled into one clean package". Nothing but the name suggests that it might be a command shell. [[Special:Contributions/80.189.144.187|80.189.144.187]] ([[User talk:80.189.144.187|talk]]) 21:15, 17 July 2015 (UTC)

== Korn Shell ==

== Remove the "ISO 8601 support" column? ==

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

IMHO, it is too vague. The date and time can be used for very different purpose, often via external utilities. So, the answer is not much meaningful. [[User:Vincent Lefèvre|Vincent Lefèvre]] ([[User talk:Vincent Lefèvre|talk]]) 16:02, 25 January 2016 (UTC)

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

:I would be happy with a removal. We should also check whether other columns that apparently have been added to let some Win-DOS shells look better should be removed. [[User:Schily|Schily]] ([[User talk:Schily|talk]]) 16:10, 25 January 2016 (UTC)

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

== Mandatory argument prompt ==

:::It still isn't on there... -[[User:PatPeter|'''Pat''']][[User talk:PatPeter|'''Peter''']] 01:18, 5 January 2010 (UTC)

I would say that this should be N/A for all Unix shells: the shell cannot know in advance what an arbitrary utility will require, and the utility can have code that checks its arguments. Prompting is then a standard feature of the terminal, not the shell. [[User:Vincent Lefèvre|Vincent Lefèvre]] ([[User talk:Vincent Lefèvre|talk]]) 16:41, 25 January 2016 (UTC)

== Built-in Window ==

:Correct: The description does not apply to any UNIX shell as this seems to be a requirement that a standard environment cannot implement: how should a shell know about whether an invoked utility may ask for more input later? [[User:Schily|Schily]] ([[User talk:Schily|talk]]) 17:02, 25 January 2016 (UTC)

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. [[User:Topher67|topher67]] 08:28, 16 November 2006 (UTC)

== Missing important differences between shells ==

: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...[[User Talk:Stevage|Stevage]] 09:10, 16 November 2006 (UTC)

The whole set of tables contains many features that do not apply to a standard (UNIX) environment at all, but there is not a single feature in the tables that would allow to distinct a POSIX shell from a SVr4 (1989) Bourne Shell.

::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.)<small><br>—[[User:Brian Patrie|überRegenbogen]] ([[User talk:Brian Patrie|talk]]) 02:58, 9 April 2009 (UTC)</small>

To get an impression about the differences in question, it might help to look at the enhancements that have been implemented in the Bourne Shell since 2006: http://schilytools.sourceforge.net/bosh.html [[User:Schily|Schily]] ([[User talk:Schily|talk]]) 17:11, 25 January 2016 (UTC)

== "Filters" ==

Important is also the Shell page from Sven Maschek: http://www.in-ulm.de/~mascheck/bourne/ [[User:Schily|Schily]] ([[User talk:Schily|talk]]) 19:08, 25 January 2016 (UTC)

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

== Archiving ==

== cmd and "start-up scripts" ==

I archived some discussions, but I left a few which seemed like they might have loose ends that could be tied up... basically a lot of debating around the appropriate way to compare Powershell and Unix shells, which have a different approach (with Powershell more monolithic). [[User:ImperfectlyInformed|<span style="font-family: Times">II</span>]] | ([[User_talk:ImperfectlyInformed|t]] - [[Special:Contributions/ImperfectlyInformed|c]]) 09:13, 17 October 2016 (UTC)

== We should mention Windows 8 and Windows 10 ==

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

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

<pre>HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor\AutoRun (REG_SZ)

HKEY_CURRENT_USER\Software\Microsoft\Command Processor\AutoRun (REG_EXPAND_SZ)</pre>

If either one or both registry subkeys are present, they are executed before all other variables.''</blockquote>

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, <code>set HOME=%USERPROFILE%</code>, <code>path %HOME%\bin;%PATH%</code>, and <code>doskey man=help $*</code>. :) <small>—The preceding [[Wikipedia:Sign your posts on talk pages|unsigned]] comment was added by [[Special:Contributions/80.233.255.7|80.233.255.7]] ([[User talk:80.233.255.7|talk]]) 09:56, 7 December 2006 (UTC).</small><!-- HagermanBot Auto-Unsigned -->

:When the computer starts, the c:\autoexec.bat file is executed by command.com. Is this a startup script? {{unsigned-r|2007-08-03T07:30:47|Michaeldadmum}}

I did a Ctrl-F of "Windows 8", "Win8", "Windows 10", and "Win10", and found no occurrences of any of those strings. Windows 7 is the latest version of Windows mentioned in this article. People who come to this article are likely curious about the roles of these two shells in the two latest versions of a very popular operating system, and the article currently lacks this information.

== Strange "features" ==

Does ReactOS have CMD.EXE and/or PowerShell? I am curious. Does anything else have either of these Microsoft shells, or emulate them?

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.

Should this article mention Cygwin as a way to get a Unix/POSIX shell on Windows?

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

I don't have any high-quality sources to cite, but I would say that CMD.EXE is clearly the default shell in Windows 8. It appears when you right-click on empty space in the File Explorer (in the menu), and PowerShell does not appear. CMD.EXE is also the default application to open .BAT and .CMD script files, much as Bash is the default application to open .SH files on MacOS or most flavors of GNU/Linux that have not been customized to do otherwise.

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. {{unsigned-r|2007-02-06T12:57:15|84.238.25.76}}

I'm honestly not sure what the default is in Windows 10, both CMD.EXE and PowerShell seem to be first class citizens. It appears that right-click on empty space now gives PowerShell in the menu (CMD.EXE has been removed), but it seems that .BAT and .CMD files are still by default executed by CMD.EXE on Windows 10, so they are each default in different contexts. In many respects, I feel that CMD.EXE is still more powerful and more widely used.

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. {{unsigned-r|2007-02-06T13:11:37|84.238.25.76}}

[[User:Fluoborate|Fluoborate]] ([[User talk:Fluoborate|talk]]) 15:29, 23 September 2017 (UTC)

==The Mashey shell, aka the Programmer's Workbench shell, is missing from the table==

== Possible revision comments ==

The [[Mashey shell]], aka the [[Programmer's Workbench]] shell, is missing from the table. Hmmm, why?

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.

There was an early split of UNIX versions, at Bell Labs, around 1976. The Programmer's Workbench was forked from Research Unix, around version six, prior to the development of version seven's Bourne Shell, with the intent that its users would be using it to manage the code they were developing for other systems.

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. [[User:Shalineth|Shalineth]] 00:20, 4 March 2007 (UTC)

I never saw it in use, but I read a couple of papers Mashey wrote on it. [[User:Geo Swan|Geo Swan]] ([[User talk:Geo Swan|talk]]) 01:56, 28 January 2019 (UTC)

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

==Recent removal of command shell features from comparision==

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

It seems that certain notable command shell features are being removed from this comparision with the only argument being "because the only thing mentioned was PowerShell" and "Power. Shell. Goodbye!". I think this is wong. If your favourite command shell does not have the maximum number of supported features then you alter the criteria? [[User:Ghettoblaster|Ghettoblaster]] ([[User talk:Ghettoblaster|talk]]) 17:37, 28 July 2021 (UTC)

:Yes. In this situation, PowerShell is the outlier in comparison to all other shells on this page in terms of its features.

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

:I believe adjusting or removing the irrelevant information on PowerShell is justified, not only because the overwhelming majority of this talk page agrees with me that this article is unnecessarily weighted towards PowerShell, or that there is a template message at the top of the page that further supports this.

:I would like to present Ghettoblaster's [http://en.wikichecker.com/user/?t=Ghettoblaster&l= edit statistics], which were retrieved from WikiChecker.

:Scrolling to the bottom of the page and opening the "Frequently edited pages" dropdown reveals that the majority of their many edits have been on Microsoft or Microsoft-related articles.

:PowerShell is a Microsoft product.

:I don't think it's unreasonable to say that it is very likely that this user has a bias towards Microsoft and its products, and has found it necessary to advertise their favourite command shell.

:I would like to note that I am not suggesting that the differences between PowerShell and the majority of other traditional shells be ''ignored'', I believe that the way the mentioned included in this article are irrelevant ''to the article''. I believe that they ''would'' be relevant on the article dedicated to [[PowerShell]], perhaps in the section comparing cmdlets to their similar equivalents on other systems.

:I am going to edit the article to rewrite and prune the information concerning PowerShell in an attempt to amend the article to reflect Wikipedia's standards. If anyone disagrees with this, please explain to me why that is. [[User:Wetsocks3499|Wetsocks3499]] ([[User talk:Wetsocks3499|talk]]) 17:36, 13 October 2022 (UTC)

::I agree. IMHO, various Windows shell features are not directly related to the shell and could be implemented elsewhere (in various ways) or could be meaningless as far as the shell is concerned. For instance, it is not clear what "Command builder" is and it probably doesn't make any sense with traditional shells. Ditto for "File/directory passwords". — [[User:Vincent Lefèvre|Vincent Lefèvre]] ([[User talk:Vincent Lefèvre|talk]]) 23:34, 13 October 2022 (UTC)

:::I think that it's also important to note that the PowerShell ISE is distinct from PowerShell itself, and is therefore not relevant when comparing its features to command shells. Please see [https://learn.microsoft.com/en-us/powershell/scripting/windows-powershell/ise/introducing-the-windows-powershell-ise?view=powershell-7.3 this link] to its documentation. Again, this information is useful, but ideally it should be placed in a different article. If anyone disagrees, please explain to me why. [[User:Wetsocks3499|Wetsocks3499]] ([[User talk:Wetsocks3499|talk]]) 13:37, 26 April 2023 (UTC)

== Consensus on external programs? ==

: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.... [[User:Charles dye|Charles dye]] ([[User talk:Charles dye|talk]]) 16:32, 13 March 2008 (UTC)

I'm wondering what people's opinion is on including external programs other than the shell itself in this article, notably in the sections mentioning progress indicators. the "Progress indicator" section itself seems to only exist to mention PowerShell's progress indicator builtin / API. None of the other shells listed in the article provide integrated progress indicators, the closest you can get is piping through a standalone program, which by definition is completely unrelated to the shell program itself.

== table headings ==

Does this need to be addressed by editing, or is explicitly mentioning that the indicator is external sufficient? [[User:Wetsocks3499|Wetsocks3499]] ([[User talk:Wetsocks3499|talk]]) 15:22, 21 October 2022 (UTC)

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. [[User:Modest Genius|<font face="Times New Roman" color="maroon"><b>Modest Genius</b></font>]] [[User_talk: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 [[User:212.144.128.213|212.144.128.213]] 18:48, 3 September 2007 (UTC)

::I see that someone has fixed that[[Special:Contributions/203.206.162.148|203.206.162.148]] ([[User talk:203.206.162.148|talk]]) 06:40, 2 February 2010 (UTC)

== The tables need some way of filtering ==

== COMMAND.COM and command history ==

It is incredibly hard to read and compare the shell features when they are presented as one overflowing table. Something similar to https://www.mediawiki.org/wiki/Extension:FilterableTables could be used for that, I don't know how to do that though. Right now those tables are virtually unusable for comparisons. [[User:Fyul e&#39;Cuest|Fyul e&#39;Cuest]] ([[User talk:Fyul e&#39;Cuest|talk]]) 17:51, 24 March 2024 (UTC)

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. [[User:Charles dye|Charles dye]] 15:29, 23 April 2007 (UTC)

:MakeWP thatis not the F1,F2,F3,F4,F5,left,right,ins,del place for the information in the article (akaair line-editingquotes) feature. ;)<small><br>—It should be deleted! [[User:Brian PatrieStevebroshar|überRegenbogenStevebroshar]] ([[User talk:Brian PatrieStevebroshar|talk]]) 0313:1835, 926 April 20092025 (UTC)</small>

== Default script shell ==

== Why not different versions of COMMAND.COM? ==

The first table currently says that bash is the default script shell in Linux. However, this is not true for all Linux distributions. In Debian and Ubuntu, this has been [[Debian Almquist shell]] (dash) since Ubuntu 6.10 (2006) and Debian 6 (2011). — [[User:Vincent Lefèvre|Vincent Lefèvre]] ([[User talk:Vincent Lefèvre|talk]]) 11:49, 16 August 2024 (UTC)

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

== What is a Graphical CLI? ==

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

[[User:Armslurp|Armslurp]] 02:44, 27 April 2007 (UTC)

PowerShell is noted as Graphical CLI. But, that seems a contradiction in terms. There's CLI, GUI and there's full-screen text (menuing), and CLI implies non-graphical. So, the term makes no sense. Further, PowerShell is the same UI as all other similar shells such as bash and cmd. It's CLI. [[User:Stevebroshar|Stevebroshar]] ([[User talk:Stevebroshar|talk]]) 14:40, 26 April 2025 (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) {{unsigned-r|2007-05-10T11:23:19|82.69.176.148}}

== 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. -- [[User:Geo Swan|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. {{unsigned-r|2007-07-21T13:18:18|24.8.176.51}}

: 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! {{unsigned-r|2007-07-23T18:04:22|85.179.98.139}}

::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. {{unsigned-r|2007-08-15T15:11:41|208.250.65.158}}

:::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 [[User:212.144.128.213|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 ([http://www.networkworld.com/subnets/microsoft/052107-ch4-code-signing.html?page=1], [http://www.informit.com/articles/article.aspx?p=729101&seqNum=7]) 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. [[User:194.97.209.100|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 <small>—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/149.225.2.138|149.225.2.138]] ([[User talk:149.225.2.138|talk]]) 14:47, 9 September 2007 (UTC)</small><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->

::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.) [[User:142.177.234.33|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]] {{unsigned-r|2007-09-17T09:23:00|217.185.12.38}}

:::: 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.[[User:142.177.233.133|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. <small>—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/123.243.163.103|123.243.163.103]] ([[User talk:123.243.163.103|talk]]) 05:05, 23 April 2008 (UTC)</small><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->

::::::This is not operating system dependent. [[Code signing]] is the process of digitally [[digital signature|signing]] [[executable]]s and [[scripting language|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 function|cryptographic hash]]. [[User:Ghettoblaster|Ghettoblaster]] ([[User talk: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? --[[User:Nealmcb|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)'' [http://docs.sun.com/app/docs/doc/816-4813/6mb0h03bp?q=WQL&a=view]).

# 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. {{unsigned-r|2007-07-29T10:00:27|78.51.113.191}}

:: 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? [[User:142.177.233.227|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. [[User:Charles dye|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. <small>—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/78.51.76.96|78.51.76.96]] ([[User talk:78.51.76.96|talk]]) 19:55, 12 September 2007 (UTC)</small><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->

::::: This is operating system specific and therefor should be removed as a row. <small>—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/123.243.163.103|123.243.163.103]] ([[User talk:123.243.163.103|talk]]) 05:12, 23 April 2008 (UTC)</small><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->

:::::: This is not operating system specific. WBEM is based on [[Internet standard]]s and [[DMTF]] [[open standard]]s: [[Common Information Model (computing)|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]]). [[User:Ghettoblaster|Ghettoblaster]] ([[User talk:Ghettoblaster|talk]]) 11:49, 23 April 2008 (UTC)

OK enough already!<BR>

"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."<BR>

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!<BR>

"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.<BR>

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

::Yes, that might be useful

Rename it please and stop defending obvious flag flying.

[[Special:Contributions/81.174.174.31|81.174.174.31]] ([[User talk: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. [[User:78.49.13.216|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. [[User:Charles dye|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. [[User:P0lyglut|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 shell]]s 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."'' <small>—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/78.51.76.96|78.51.76.96]] ([[User talk:78.51.76.96|talk]]) 19:22, 12 September 2007 (UTC)</small><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->

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

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

== DEC operating systems are not represented ==

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

:Thank you for your suggestion{{{{#if:notsubsted||subst:}}#if:{{{1|}}}|&#32;regarding [[:{{{1}}}]]}}. 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 '''{{MediaWiki:edit}}''' link at the top. The Wikipedia community encourages you to [[Wikipedia:Be bold in updating pages|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 [[Wikipedia:how to edit a page|''how to edit a page'']], or use the [[Wikipedia:Sandbox|sandbox]] to try out your editing skills. [[Wikipedia:Welcome, newcomers|New contributors are always welcome]]. You don't even need to [[Special:Userlogin|log in]] (although there are [[Wikipedia:Why create an account?|many reasons why you might want to]]). <!-- Template:Sofixit --> {{unsigned-r|2007-10-08T10:18:06|194.97.209.126}}

== 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. --[[User:Mcpusc|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? [[User:129.24.38.145|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. --[[User:Mcpusc|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. <small>—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/85.181.242.248|85.181.242.248]] ([[User talk:85.181.242.248|talk]]) 21:56, 24 October 2007 (UTC)</small><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->

::::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. --[[User:Prodicus|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.--[[Special:Contributions/18.127.1.9|18.127.1.9]] ([[User talk: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. [[Special:Contributions/129.24.38.145|129.24.38.145]] ([[User talk: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?<br />

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? {{unsigned-r|2007-12-19T20:01:33 |78.51.102.167}}

: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

:<small>—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/90.28.141.145|90.28.141.145]] ([[User talk:90.28.141.145|talk]]) 13:17, 8 January 2008 (UTC)</small><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->

::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. <small>—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/92.226.200.25|92.226.200.25]] ([[User talk:92.226.200.25|talk]]) 20:56, 13 January 2008 (UTC)</small><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->

:::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. <small>—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/92.226.200.25|92.226.200.25]] ([[User talk:92.226.200.25|talk]]) 23:07, 13 January 2008 (UTC)</small><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->

== 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. [[User:Skydot|SkyDot]] ([[User talk: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. ;-) <small>—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/78.54.97.117|78.54.97.117]] ([[User talk:78.54.97.117|talk]]) 13:04, 10 May 2008 (UTC)</small><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->

: 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. --[[User:Rfsmit|Rfsmit]] ([[User talk:Rfsmit|talk]]) 20:30, 21 July 2008 (UTC)

== Default argument ==

How can [[default argument]]s be defined using bash and ksh? <small>—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/92.227.135.56|92.227.135.56]] ([[User talk:92.227.135.56|talk]]) 22:52, 10 January 2008 (UTC)</small><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->

: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}

...

}

:{{unsigned-r|2008-01-30T12:32:29|Stephane Chazelas}}

== "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. [[User:Charles dye|Charles dye]] ([[User talk: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:

<code>

set fred=ping.exe

%fred%

Usage: ping [-t] [-a] [-n count] ... etc

</code>

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.[[Special:Contributions/203.206.162.148|203.206.162.148]] ([[User talk: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. <tt><span style="background-color:#de0000">[[User talk:Helpsloose|<font color="#fcd115">Hel</font>]][[User:Helpsloose|<font color="white">pslo</font>]][[Special:Contributions/Helpsloose|<font color="#fcd115">ose</font>]]</span></tt> 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.) [[User:Charles dye|Charles dye]] ([[User talk: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. --[[User:SJK|SJK]] ([[User talk: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? [[User:Ghettoblaster|Ghettoblaster]] ([[User talk: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.))

--[[User:SJK|SJK]] ([[User talk: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. <small>—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/12.152.252.4|12.152.252.4]] ([[User talk:12.152.252.4|talk]]) 19:15, 3 June 2008 (UTC)</small><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->

== 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). <small>—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/12.155.35.130|12.155.35.130]] ([[User talk:12.155.35.130|talk]]) 14:43, 19 June 2008 (UTC)</small><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->

* 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. {{unsigned-r|2008-08-30T01:25:27 |George OConnor}}

;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... [[Special:Contributions/193.173.39.45|193.173.39.45]] ([[User talk:193.173.39.45|talk]]) 11:25, 18 February 2009 (UTC)

== Lisp? ==

Should the Lisp REPL be included on this page? <small>—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/75.65.196.71|75.65.196.71]] ([[User talk:75.65.196.71|talk]]) 18:42, 18 August 2008 (UTC)</small><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->

== 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). [[User:Vincent Lefèvre|Vincent Lefèvre]] ([[User talk:Vincent Lefèvre|talk]]) 03:33, 25 February 2009 (UTC)

: {{sofixit}} [[User:Ghettoblaster|Ghettoblaster]] ([[User talk:Ghettoblaster|talk]]) 18:33, 27 March 2009 (UTC)

== MPW Shell ==

Should [[http://en.wikipedia.org/wiki/Macintosh_Programmer%27s_Workshop#MPW_Shell 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 [[Special:Contributions/62.12.14.26|62.12.14.26]] ([[User talk: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. [[User:Ghettoblaster|Ghettoblaster]] ([[User talk: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).<small><br>—[[User:Brian Patrie|überRegenbogen]] ([[User talk:Brian Patrie|talk]]) 03:49, 9 April 2009 (UTC)</small>

* 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). [[User:Cbensf|Cbensf]] ([[User talk:Cbensf|talk]]) 19:29, 23 February 2010 (UTC)

== History in Powershell? ==

I think the meaning of history is cross-session - this blog indicates, [http://winvistaforums.com/windows-vista-support/157-how-add-history-windows-powershell.html NO]. [[User talk:-Zeus-|-Zeus-]]^{[[User:-Zeus-|u]]|[[Special:Contributions/-Zeus-|c]]} 15:56, 13 April 2009 (UTC)

:[[Command history]] [[User:Ghettoblaster|Ghettoblaster]] ([[User talk: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. ⇔ <span style="font-size-adjust:0.54; font-family:'P22 Declaration Script','American Scribe','National Archive', Charcoal, Virtue;">[[User:ChristTrekker|ChristTrekker]]</span> 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. <span style="font-size: smaller;" class="autosigned">—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/64.66.99.129|64.66.99.129]] ([[User talk:64.66.99.129|talk]]) 19:58, 6 July 2009 (UTC)</span><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->

== Bash is king of ubiquity ==

Where's the Unix PowerShell. Oh there it is!<BR>

Whatabout Perl, PHP and Python? the run shell mode too.

[[Special:Contributions/81.174.174.31|81.174.174.31]] ([[User talk:81.174.174.31|talk]]) 22:29, 21 July 2009 (UTC)

== No [[Bourne shell|sh]]? ==

So though this has bash, [[C shell|csh]], [[tcsh]], and [[zsh]], it does not have [[Bourne shell|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 {{tl|sofixit}}). Adding the Thompson shell has no use for those who think of that before the Bourne shell. -[[User:PatPeter|'''Pat''']][[User talk:PatPeter|'''Peter''']] 01:17, 5 January 2010 (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?. [[User:Useerup|Useerup]] ([[User talk: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? [[User:Useerup|Useerup]] ([[User talk: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 '''struct'''s. 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 pipes[[User:Useerup|Useerup]] ([[User talk:Useerup|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 <span style="font-size: smaller;" class="autosigned">—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/84.59.79.230|84.59.79.230]] ([[User talk:84.59.79.230|talk]]) 00:35, 10 January 2010 (UTC)</span><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->

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. [[User:Useerup|Useerup]] ([[User talk: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. [[User:Useerup|Useerup]] ([[User talk:Useerup|talk]]) 14:49, 10 January 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".[[User:Useerup|Useerup]] ([[User talk: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" <span style="font-size: smaller;" class="autosigned">—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/203.206.162.148|203.206.162.148]] ([[User talk:203.206.162.148|talk]]) 07:20, 2 February 2010 (UTC)</span><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->

== 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. <span style="font-size: smaller;" class="autosigned">—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/187.105.140.115|187.105.140.115]] ([[User talk:187.105.140.115|talk]]) 04:38, 23 June 2010 (UTC)</span><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->

== Rows like "binary prefix notation" ==

Considering you need ''one'' line* to have this, why is there even an own row?<br />

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

[[Special:Contributions/84.63.170.222|84.63.170.222]] ([[User talk: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.

[[Special:Contributions/84.63.215.19|84.63.215.19]] ([[User talk: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. [[Special:Contributions/84.63.215.19|84.63.215.19]] ([[User talk:84.63.215.19|talk]]) 13:30, 10 July 2010 (UTC)