Talk:Comparison of command shells

message: I've just found the section
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)
replies: text: Agreed --Useerup (talk) 23:51, 28 June 2013 (UTC)
replies: text: Actually, IPython, being a generic shell, probably should be here. 50.53.15.59 (talk) 11:51, 18 April 2014 (UTC)
thread_title:  Reopen of "Python and Ruby Shells?" discussion 

message: 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)
replies: text: I would like to remove it too. It is not a real shell (real as in realized in e.g. sh). Useerup (talk) 05:56, 9 August 2013 (UTC)
replies: text: 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). Vincent Lefèvre (talk) 00:51, 30 October 2013 (UTC)
replies: text: 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.  ArabOrange (talk) 15:15, 14 October 2021 (UTC)
thread_title:  Should POSIX shell be removed from comparison? 

message: 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)
replies: text: Agreed - it's apparent that single-purpose authors have more time than anyone else. TEDickey (talk) 08:57, 4 October 2013 (UTC)
replies: text: Agreed. Hopugop (talk) 15:18, 13 October 2013 (UTC)

text: 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? Jsnover (talk) 03:17, 26 October 2013 (UTC)

text: For example, "Workflow" as a bare assertion without relating it to the state of the art in command-shells, is merely advertising jargon TEDickey (talk) 10:03, 26 October 2013 (UTC)
replies: text: 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?  Jsnover (talk) 17:38, 26 October 2013 (UTC)

text: perhaps, taking into account relevant guidelines such as WP:RS, WP:FRINGE, WP:OR TEDickey (talk) 22:22, 26 October 2013 (UTC)
replies: text: Thanks for the pointers - I was unaware of these.  I'll educate myself.  Jsnover (talk) 15:54, 27 October 2013 (UTC)
replies: text: Also, if you are the 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?) Useerup (talk) 16:11, 28 October 2013 (UTC)
replies: text: 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.  Jsnover (talk) 01:53, 29 October 2013 (UTC)
replies: text: 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.Useerup (talk) 16:54, 29 October 2013 (UTC)

text: 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). Vincent Lefèvre (talk) 00:19, 18 July 2015 (UTC)
replies: text: 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. 80.189.144.187 (talk) 11:38, 18 July 2015 (UTC)

text:  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.  81.110.99.109 (talk) 21:57, 19 September 2015 (UTC)
replies: text:  For Bash, it is said Yes concerning Arithmetic. Vincent Lefèvre (talk) 00:06, 20 September 2015 (UTC)

text: 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 Write-Progress "Creating users" 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. 91.199.208.219 (talk) 05:37, 5 August 2015 (UTC)
replies: text: 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. — Vincent Lefèvre (talk) 17:41, 23 February 2021 (UTC)
replies: text: 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 pipes (e.g. with the POSIX 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)

text: 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. Vincent Lefèvre (talk) 00:45, 18 July 2015 (UTC)
thread_title:  PowerShell advertising copy 

message: 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)
replies: text: 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. Useerup (talk) 21:21, 6 November 2013 (UTC)
replies: text: Actually, there is a clear UNIX bias to this article, right from the wording in the article title. --80.216.243.49 (talk) 12:34, 10 February 2014 (UTC)
thread_title:  The main problem 

message: 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)
thread_title:  Market share 

message: 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)
thread_title:  Beanshell 

message: 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)
replies: text: 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. Schily (talk) 16:10, 25 January 2016 (UTC)
thread_title:  Remove the "ISO 8601 support" column? 

message: 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)
replies: text: 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? Schily (talk) 17:02, 25 January 2016 (UTC)
thread_title:  Mandatory argument prompt 

message: 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)
thread_title:  Missing important differences between shells 

message: 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)
thread_title:  Archiving 

message: 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)
thread_title:  We should mention Windows 8 and Windows 10 

message: 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)
thread_title: The Mashey shell, aka the Programmer's Workbench shell, is missing from the table

message: 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)
thread_title:  Consensus on external programs? 

message: 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)
thread_title:  The tables need some way of filtering