This article is rated List-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||
|
Safety is for protecting the user against his own clumsiness (as opposed to security, which is for protecting the system against malevolent users). A few safety features of Fish I've stumbled upon:
[[
compound command, which avoids the ambiguities of the test
command.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?
Wildcard completion is not explained - The word "wildcard" is not mentioned anywhere in the linked section. And if TAB-completion of
glob patterns is meant, that is supported at least as far back as Bash 3.0 (2004). Try for example cd /[e]*<tab>
.
Directory history is another feature which has been supported since at least Bash 3.0 - Try cd -
and pushd
/popd
.
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.
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.
l0b0 ( talk) 12:08, 11 April 2013 (UTC)
pushd
/popd
, and I'm wouldn't be surprised if there are many more on that list.
Yb2 (
talk) 02:54, 24 May 2013 (UTC)I've just found the section [1] 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.
Are there any significant points I've missed?
Any great objections to me removing those shells from this page?
peterl ( talk) 13:10, 27 June 2013 (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). Proxyma ( talk) 02:50, 9 August 2013 (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 -- Sean r lynch ( talk) 04:37, 4 October 2013 (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. -- Sean r lynch ( talk) 04:55, 4 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:
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. 203.28.14.129 ( talk) 02:40, 25 September 2014 (UTC)
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). 80.189.144.187 ( talk) 23:23, 17 July 2015 (UTC)
mkfifo
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
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. —
Vincent Lefèvre (
talk) 18:35, 23 February 2021 (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 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.
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).
KamikazeScotsman (
talk) 16:38, 6 November 2013 (UTC)
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. -- Beland ( talk) 15:15, 1 February 2014 (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? Msnicki ( talk) 23:29, 15 July 2014 (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 wiki page refers to it as a "Java-like scripting language" rather than a shell, and its 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. 80.189.144.187 ( talk) 21:15, 17 July 2015 (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. Vincent Lefèvre ( talk) 16:02, 25 January 2016 (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. Vincent Lefèvre ( talk) 16:41, 25 January 2016 (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.
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 Schily ( talk) 17:11, 25 January 2016 (UTC)
Important is also the Shell page from Sven Maschek: http://www.in-ulm.de/~mascheck/bourne/ Schily ( talk) 19:08, 25 January 2016 (UTC)
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). II | ( t - c) 09:13, 17 October 2016 (UTC)
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.
Does ReactOS have CMD.EXE and/or PowerShell? I am curious. Does anything else have either of these Microsoft shells, or emulate them?
Should this article mention Cygwin as a way to get a Unix/POSIX shell on Windows?
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.
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. Fluoborate ( talk) 15:29, 23 September 2017 (UTC)
The Mashey shell, aka the Programmer's Workbench shell, is missing from the table. Hmmm, why?
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.
I never saw it in use, but I read a couple of papers Mashey wrote on it. Geo Swan ( talk) 01:56, 28 January 2019 (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? Ghettoblaster ( talk) 17:37, 28 July 2021 (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.
Does this need to be addressed by editing, or is explicitly mentioning that the indicator is external sufficient? Wetsocks3499 ( talk) 15:22, 21 October 2022 (UTC)
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. Fyul e'Cuest ( talk) 17:51, 24 March 2024 (UTC)
This article is rated List-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||
|
Safety is for protecting the user against his own clumsiness (as opposed to security, which is for protecting the system against malevolent users). A few safety features of Fish I've stumbled upon:
[[
compound command, which avoids the ambiguities of the test
command.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?
Wildcard completion is not explained - The word "wildcard" is not mentioned anywhere in the linked section. And if TAB-completion of
glob patterns is meant, that is supported at least as far back as Bash 3.0 (2004). Try for example cd /[e]*<tab>
.
Directory history is another feature which has been supported since at least Bash 3.0 - Try cd -
and pushd
/popd
.
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.
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.
l0b0 ( talk) 12:08, 11 April 2013 (UTC)
pushd
/popd
, and I'm wouldn't be surprised if there are many more on that list.
Yb2 (
talk) 02:54, 24 May 2013 (UTC)I've just found the section [1] 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.
Are there any significant points I've missed?
Any great objections to me removing those shells from this page?
peterl ( talk) 13:10, 27 June 2013 (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). Proxyma ( talk) 02:50, 9 August 2013 (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 -- Sean r lynch ( talk) 04:37, 4 October 2013 (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. -- Sean r lynch ( talk) 04:55, 4 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:
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. 203.28.14.129 ( talk) 02:40, 25 September 2014 (UTC)
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). 80.189.144.187 ( talk) 23:23, 17 July 2015 (UTC)
mkfifo
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
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. —
Vincent Lefèvre (
talk) 18:35, 23 February 2021 (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 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.
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).
KamikazeScotsman (
talk) 16:38, 6 November 2013 (UTC)
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. -- Beland ( talk) 15:15, 1 February 2014 (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? Msnicki ( talk) 23:29, 15 July 2014 (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 wiki page refers to it as a "Java-like scripting language" rather than a shell, and its 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. 80.189.144.187 ( talk) 21:15, 17 July 2015 (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. Vincent Lefèvre ( talk) 16:02, 25 January 2016 (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. Vincent Lefèvre ( talk) 16:41, 25 January 2016 (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.
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 Schily ( talk) 17:11, 25 January 2016 (UTC)
Important is also the Shell page from Sven Maschek: http://www.in-ulm.de/~mascheck/bourne/ Schily ( talk) 19:08, 25 January 2016 (UTC)
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). II | ( t - c) 09:13, 17 October 2016 (UTC)
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.
Does ReactOS have CMD.EXE and/or PowerShell? I am curious. Does anything else have either of these Microsoft shells, or emulate them?
Should this article mention Cygwin as a way to get a Unix/POSIX shell on Windows?
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.
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. Fluoborate ( talk) 15:29, 23 September 2017 (UTC)
The Mashey shell, aka the Programmer's Workbench shell, is missing from the table. Hmmm, why?
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.
I never saw it in use, but I read a couple of papers Mashey wrote on it. Geo Swan ( talk) 01:56, 28 January 2019 (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? Ghettoblaster ( talk) 17:37, 28 July 2021 (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.
Does this need to be addressed by editing, or is explicitly mentioning that the indicator is external sufficient? Wetsocks3499 ( talk) 15:22, 21 October 2022 (UTC)
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. Fyul e'Cuest ( talk) 17:51, 24 March 2024 (UTC)