Talk:Comparison of command shells/Archive 2

I believe fish is an important shell that should be added to this comparison.It has few features that are not present in most other shells (syntax highlighting, for example) and is very comfortable to use.

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

+1Sedrikov (talk) —Preceding undated comment added 14:04, 5 March 2012 (UTC).

+1 --Ben (talk) 18:12, 30 November 2012 (UTC)

Comment: There is no point in "voting" on Wikipedia. A thousand people could append their "+1"'s and yet there would be no more mention of fish in the article than before. If you think something should be added, do add it; all editors are euqual and nobody else will "take the order" here. --Arny (talk) 19:34, 16 December 2012 (UTC)

I just did! --84.209.119.158 (talk) 15:26, 26 April 2014 (UTC)

I was looking into including fish, but fish seems to have been abandoned. A fishfish shell promises to become the new fish shell, but that has yet to be released. Can anyone shed some light on this? I assume that we do not include abandoned/defunct shells in this article? (history of noteworthy shells - defunct or not - should go into articles about each shell). Useerup (talk) 16:09, 21 December 2012 (UTC)

It wasn't abandoned, just got a new maintainer. I've been a fish user since approximately then, and seen it popularize. I think you should look again. --84.209.119.158 (talk) 15:26, 26 April 2014 (UTC)

• Note that fish is currently reflected in the article. II | (t - c) 08:40, 17 October 2016 (UTC)

I have archived all but the most recent section here: Talk:Comparison_of_command_shells/Archive_1. Feel free to copy discussions back in if you feel that it should not have been archived. --Useerup (talk) 12:11, 2 February 2012 (UTC)

SVr4 supported a specific type of multibyte character (EUC) as described in this (later documentation). Its support for multibyte characters was a special case, in contrast to its focus on ISO-2022. In particular, UTF-8 is a different type of encoding, unlike EUC and was not addressed by SVr4. Noting that SVr4 was from 1988, and Solaris (presumably the point of the edit) offered a subset of UTF-8 encoding in 1996 or 1997 (dates unclear, since none of the older Solaris machines from the late 1990s that I have access to have a complete set of locales installed, and for instance LC_CTYPE for the UTF-8 encoding is badly broken). A reliable source should be used rather than speculative comments. The supporting comment in its current form is WP:OR. TEDickey (talk) 22:21, 9 April 2012 (UTC)

Agreed that it is WP:OR in it current form. Absent a RS, could we rewrite it in a way which would not be disputed? --Useerup (talk) 00:19, 10 April 2012 (UTC)

The awkward part is the anachronism of citing SVr4, which is 8 years before the feature was actually available (referring to Solaris 2.6 or 7). By itself, "SVr4" also has the problem that there are three well-known implementations (Solaris, IRIX64 and HPUX). It appears that those all provided independent implementations of UTF-8 in the mid/late 1990s (and all based on the same recommendations via X/Open). Perhaps a suitable RS could be found for that. TEDickey (talk) 01:09, 10 April 2012 (UTC)

Speculative comments do not help us, so let me first correct some speculative claims with real facts:

• The SVr4 deal between AT&T and Sun has been announced in December 1987 (on the Sun User Group Meeting) the product was definitely not ready in 1988.

• The first SVr4.0 code was ready in autumn 1989 - I still know of no public distro that was based on that code.

• I received my first Sun with a preliminary internal copy of SunOS-5.0 in February 1992

• I have been on a UNICODE conference in late 1992, so SunOS-5 and UNICODE appeared to me in the same year.

• The Bourne Shell source (usr/src/cmd/sh/*.c) delivered in the first SVr4.0 code did already support multi byte locales, which is sufficient to support UNICODE (if libc also supports UNICODE)

• The EUC Code delivered with SVr4 is a multi byte locale (see link above)

• The first SunOS-5.x version shipped to anybody was 5.3 (maybe 5.2) - both in 1993.

• The first libc support for UTF-8 appeared in late 1995 in SunOS. So there was only two years between a public SVr4 and a usable UNICODE locale.

• The code to support i18n in libc is common to Sun, HP, IBM, NOVELL and OSF (IRIX may really have an independent implementation).

My concern is that there are unfortunately a lot of OSS hostile people in WP and these people are expected to attack simple unexplained but true statements like: Bourne Shell supports UNICODE. Note that UNICODE can be used with the Bourne Shell since 17 years.

None of the shells listed on this article (except for the windows power shell and the bean shell) have been written before UNICODE was introduced. So their initial versions did not support UNICODE. We need to have equal treatment for all shells in this article and withstand the attacks from people who like to preserve a description of the initial version of the Bourne Shell compared to descriptions of current versions of other shells. I have no problem to go back to "UNICODE -> NO" for the Bourne Shell in case that all other shells (except the windows power shell and the bean shell) also get a "NO" in this column or in case that the Bourne Shell just gets a simple "YES" like currently seen for other shells. --Schily (talk) 13:28, 10 April 2012 (UTC)

Suggestion: For the time being (this is a comparison article where the primary focus is not history) we simple tick it to yes and leave out the "since" part. IMHO the history is a minor detail in this context and is better handled in the articles about each shell. Surely, the yes can withstand a challenge, right? --Useerup (talk) 22:26, 10 April 2012 (UTC)

Would be OK for me --Schily (talk) 22:34, 10 April 2012 (UTC)

That addresses the point in dispute (noting that several of your statements above are easily disputed, and exploring those would take time) TEDickey (talk) 23:57, 10 April 2012 (UTC)

The apparent motivation of Schily's edits is in support of this activity TEDickey (talk) 20:31, 20 April 2012 (UTC)

I am disappointed to see this kind of pointless and obvioulsy wrong claims from User:Tedickey. Note that in the morning of April 20th, he removed well sourced information about the fact, that Sun made the Bourne Shell OpenSource 7 years ago and incorrectly claimed "the new text did not mention the AT&T proprietrary version anymore". I have no idea about his motivation, but there have been many similar cases in the past. The term "promotional ..." is an incoherent stereotype frequently used by him. It would be nice, if we could have fact based articles instead of articles driven by the opinion of Mr. Dickey. The fact that he did not remove the information a second time is a good beginning. --Schily (talk) 12:28, 26 April 2012 (UTC)

I'm not an experienced *nix user so I don't know how to go about making comparisons or evaluations, but Xiki does seem a very interesting new shell, I guess it could be added: http://xiki.org/

Synopsis from the site:
Xiki: A shell console with GUI features.
Xiki does what shell consoles do, but lets you edit everything at any time. It's trivial to make your own commands and menus to access other tools.
Everything is editable text. Type commands anywhere. Edit the output.

Chrishelenius (talk) 00:15, 23 September 2012 (UTC)

Xiki is not a shell but rather a console or terminal. There could be different various shells or interpreters behind Xiki. --pabouk (talk) 15:43, 13 November 2012 (UTC)

As the default shell on Ubuntu, the most popular Linux variant, it seems like dash should be mentioned in this article. Also it would be good to add brace expansion as a column to the programming features table. Jason Quinn (talk) 06:37, 30 September 2012 (UTC)

Isn't dash just a debian-ash? If so we could expand the ash to include ash/dash. --Useerup (talk) 17:29, 19 October 2012 (UTC)

Brace expansion is definitively a noteworthy feature. Useerup (talk) 00:34, 1 December 2012 (UTC)

Also link to what is Brace Expansion Shirishag75 (talk) 22:48, 12 October 2014 (UTC)

Namely, "Native CIM/WBEM support" and "Blocking of unsigned scripts". It seems to me these characteristics are not at all "general" for a command shell, and it also seems like they're only "Yes" for Windows PowerShell, so I believe they would be better represented within the Windows PowerShell article, and unnecessarily take up space here in what looks like an attempt to make PowreShell look "greener". — Preceding unsigned comment added by 109.67.213.188 (talk) 12:47, 19 October 2012 (UTC)

They are notable features of a command shell. The number of shells which implement or support a feature has no bearing on its notability. CIM/WBEM are industry standards aimed at instrumenting and managing hardware and computing devices in a network. That is squarely within the use-cases for command shells and thus an interesting feature. As for script signing that is also an interesting (security) feature, even if other shells haven't gotten around to doing something similar. *Especially* in a comparison article it is interesting what distinguishes one shell from the others. --Useerup (talk) 17:27, 19 October 2012 (UTC)

There may be truth in what Useerup is saying (I am unfamiliar with CIM/WBEM and think that the script signing requirement is more of a policy than a feature). My argument is that while these properties may be noteworthy, they are not "general", in the same sense than "Unix support" is not general. It's also important to note that Useerup has been editing many Microsoft dispute related articles in favor of Microsoft, and thus appears to be biased. However, as a Linux user who tried and didn't like PowerShell, I admit to being biased myself, so I call for a third, more neutral person to settle the issue and decide whether the edit is appropriate. — Preceding unsigned comment added by 109.67.213.188 (talk) 14:05, 20 October 2012 (UTC)

Regarding CIM/WBEM: I don't really get what "general" is supposed to mean in this context. You could compare it to the POSIX shell standard. Both are standards, both are clearly relevant within the topic of command shells. Shells adhere to the POSIX shell standard in varying degrees. I agree that "Unix support" could be problematic - but that is due to it being a loosely defined term rather than a general concept. It *is* interesting what platforms a shell is available for, however. And the latter is more neutral and less prone to conflicts. Useerup (talk) 19:02, 20 October 2012 (UTC)

I posted this to the neutral point of view noticeboard. Hopefully, more neutral and informed people will resolve the issue. — Preceding unsigned comment added by 109.67.213.188 (talk) 23:24, 21 October 2012 (UTC)

You may want to move that post the the main project page. You posted it on the talk page of that board. The talk page is for discussing the project (and policies). The main project page is for handling questions and soliciting opinions such as your request. Useerup (talk) 06:49, 22 October 2012 (UTC)

"Native CIM/WBEM support" is garbage and must be removed. Not a single shell implements CIM/WBEM. At most, one can argue that PowerShell has some CmdLets that implement CIM. The same can be said about _any other shell_ in this page because of stuff like OpenWBEM. Thus, there is no point at all in making a comparison. The "blocking of unsigned scripts" though is an actual feature. <opinion>Totally useless and proves that whoever designed such a shell still has no idea what a shell is. But a feature nevertheless. </opinion> Javispedro (talk) 21:03, 9 November 2012 (UTC)

PowerShell has built-in type accelerators for WMI(CIM) queries and WMI(CIM) classes. Consider this: $system = [wmiclass]'CIM_System'. This assignment looks up the CIM class with the name "CIM_System". No external code, it is integrated into the shell. Likewise the types [wmi] and [wmisearcher] are integrated. Also, the WsMan: special drive is the WMI/CIM hierarchy of the system. An integrated location hierarchy mapping to CIM classes. PowerShell remoting is built on top of WBEM. So PowerShell definitely has more than "some Cmdlets". It is a native feature^[1] Useerup (talk) 01:47, 11 November 2012 (UTC)

As per your reference, "Windows PowerShell implements WMI functionality through a set of cmdlets that are available in Windows PowerShell by default." So, it is actually "some Cmdlets". Neither WsMan nor PowerShell remoting are actually built on top of WBEM (I'd wish), but rather WS-Man, and even if they were I'd argue that any "remoting" stuff is out of the scope for a comparison about the shells. Since a) the feature is usually not of much interest as general discriminator feature between shells (only one person so far has expressed any interest in that column); b) there are programs that universally provide that feature to every computer shell listed on this page; and c) such a column is always going to be all red but for PS, reinforcing the uselessness of the comparison; I am going to remove that column in a few days. We'll see if there are more complains after that. Javispedro (talk) 01:18, 12 November 2012 (UTC)

Now read the entire reference, especially the part about WMI type accelerators. WMI/CIM *is* an integral part of PowerShell. That the topic is *primarily* about the cmdlets (topic title) does not allow you to ignore all of the sections. Remotely administering devices and computers is well within the scope of shells - it is a typical use case. You do not remove this column. Useerup (talk) 07:33, 12 November 2012 (UTC)

I have not been able to parse that article in any other way than "WMI is implemented by a set of built-in Cmdlets". I do not understand your fixation with type accelerators which are actually even simpler and less relevant. You might be talking about actual types, but types are not defined by PS (they are defined by the CLI). In any case, I'm thinking about your good point regarding that remoting is actually a general feature. In this case, I think that what we could do is replace the column with a much more generic "Remoting support" with PS having "Builtin (Windows Remote Management / WS-Management) + External (OpenSSH)" while all others would have "External (rsh, OpenSSH, ...)". Thoughts? — Preceding unsigned comment added by Javispedro (talk • contribs) 22:40, 12 November 2012 (UTC)

I believe that remote control features deserves a table by itself. As for CIM/WBEM: It is a standard which is clearly relevant for the domain of command shells (it is a commonn use case). As long as one shell make special syntax or has bundled/integrated commands for a topic which is relevant in the target domain then it deserves to go into a comparison article. It becomes a distinguishing (and thus interesting) feature. That is the case with CIM/WBEM, for which PowerShell has actual types (wmi, wmiclass, wmisearcher), comes with bundled commands (get-wmi, ...). It is also the case with TCP server and zsh, BTW. The real question is what to do about the shells which do *not* bundle commands/modules but where external commands can be acquired which offer the same or equivalent features. In my opinion they do not offer the features, but the fact that the commands may exist for the system on which the shell is executed should be noted (a reference). I.e., does csh supports features because awk does? No, it does not. But if other shells directly offer features which could be available through awk, it should be a "no" with a comment that "no; but supported through external command awk, if available". Useerup (talk) 07:13, 14 November 2012 (UTC)

Whether "Native CIM/WBEM support" is notable, general, garbage, or a standard, the fact of the matter is that it's only "Yes" for precisely one shell, which makes tabular form an extremely inefficient way to convey the information. Only features that are supported by more than one shell rate a full column in a table with so many rows. It should be removed from the table. --Sean r lynch (talk) 04:19, 4 October 2013 (UTC)

• Note that this currently seems to be gone from the article. II | (t - c) 08:43, 17 October 2016 (UTC)

I find this solution to the problem presented in the above discussion rather amusing, because now, while there's only one MS-Powershell oriented column in the General Characteristics table, there's a whole Powershell-worship section at the bottom. I trust readers of this article to be sharp enough to spot this "subtle" Microsoft advocacy. (I would personally appreciate an explanation though, as to why on earth those guys at Microsoft thought a built-in "secure credentials prompt", "encrypted variables", "safe data subsets" or "signed script restriction" would make features worthy of including in a command shell...)

However, I find two problems:1. The explanations below the table shouldn't be in an article of this kind; they should be written in appropriate separate articles (most, if not all, under "Powershell"), and linked from the table, just as this article doesn't contain text about pipes or regex.

2. If the explanations are to be included, here or elsewhere, they should be heavily reviewed and reworded; for example, under "Encrypted Variables", the text reads: "As the only shell, PowerShell can work with encrypted string variables/parameters ...". Now, while this part of the article is clearly striving to get Powershell to the status of "the only shell", it isn't the case just yet.(There are more mistakes, such as "Several shells can be started or configured to start in a mode where only a limited set of commands and actions are available to the user.", several missing commas, etc.)

Useerup, I hate to ruin your work (in the stronger sense if you are indeed employed by Microsoft, but even if you're just a zealous fan), but this is below the standards of Wikipedia, so I'm removing all the explanations and links for now, so that you can rebuild your Powershell shrine, this time properly. — Preceding unsigned comment added by Alfonsofer (talk • contribs) 16:29, 18 December 2012 (UTC)

Sorry, but you should not delete entire sections just because you do not like the content. Mark the issues you have and I will try to work in a solution. I am trying to improve this article by including explanations with source references such that the tables become summaries of otherwise verifiable explanations. Instead of yes/no/partial of the tables - often with no explanation - this format allows us to address more subtle differences. An article with just a list of tables with yes/no is not very encyclopedic. I have re-introduced the section and will try to address some of your concerns. Useerup (talk) 19:48, 18 December 2012 (UTC)

As I said before, I did not delete your content because I didn't like it, but because I thought, and still think, that its quality and presentation are not near good enough to be included in an article. If they are simply intended to provide a short explanation of the column titles in your table, I would suggest making them as short as possible and placing them as notes, so that they're embedded into the table as much as possible. If they're indeed intended to expand on each feature and compare shells, then some expansion and comparison (rather than the mere description of Powershell features that is currently present) is needed: perhaps some use cases, ways to implement the feature in shells that lack it, etc. In that case, I also urge you to expand and compare on all the other features in the tables.

While I have no doubt that your content is biased, that doesn't mean it's wrong; it become completely unacceptable, however, when it damages the quality and clarity of the article. I'll keep watching this page for the next couple of days and I trust that you will alter your edits to bring improve this page rather than damage it. Alfonsofer (talk) 21:10, 18 December 2012 (UTC)

My intention is indeed to expand on the other tables as well. As it stands now, the tables are largely unsourced or poorly sourced. If you feel like helping with expanding please go ahead. However, when expanding we have to stay away from original research. This often means that we are restricted to sourcing features/characteristics for each shell and not directly comparing them. When one shell offers a feature and others do not, it is often hard to find a source for the latter statement. I will be careful to stay away from such statements, unless sourced. ok? And please watch/review/whatever - just stay away from blanket removal. I know quite a lot about both Linux and PowerShell scripting (more thin on the language shells and 4DOS/TCC), and yes, I have formed an opinion as to what I personally prefer. However, I'm trying to write this from a neutral point of view, and I respectfully ask that you judge the content of the article and not its authors. If you have specific issues then mark them as such, and we'll take it from there, ok? Useerup (talk) 22:31, 18 December 2012 (UTC)

Just to make it clear, I have absolutely nothing against you (in fact, I don't know you at all) - I was just referred to this page and found the wild Microsoft bias infuriating. I apologize for any personal offense implied from my comments. I have some experience with some of the Linux and language shells, as well as Powershell (and to be honest, I don't think Powershell is all bad, just not as clearly superior as an untrained skim of this article could imply). I'll see what I can do to collaborate and improve the quality

As for Powershell's security features, the first question I had when learning about them is when they could be useful (and I've heard several coworkers ask the same question). So I think it would be appropriate if you could cite use cases for these features, to justify their inclusion.

I hope we can create a better and more neutral article. Alfonsofer (talk) 01:21, 19 December 2012 (UTC)

Why security features are relevant:

• Non-echoing (password) prompt: Scripts in a production setting regularly need to access resources on behalf of a user/administrator, and sane users/administrators try to stay away from storing passwords in config files. Hence they need to be supplied at run time. When typing in a password it is security best practice to not echo back the password.
• Credentials prompt: A password prompt is a simplistic way which encourages text passwords and which do not allow for more sophisticated authentication schemes. A generalization of username/password is credentials. If a script can prompt for and receive credentials in the abstract sense (some kind of token proving the operators identity) - oblivious to exactly how they are represented - the script can be used with two-factor authentication schemes such as smart cards, biometrics (fingerprint reader) and more. This can both make supplying credentials easier and more secure.
• Encrypted variables. Common criteria specifies that sensitive information must be encrypted, also in working memory. Otherwise sensitive information can leak through numerous channels, e.g. swap files (memory being swapped to disk, core dumps, transcripts, variable dump or even malicious injections or scannings. If you design a solution which relies on scripts during production and those scripts query for passwords or other sensitive information (e.g. private keys, account numbers), your solution will not be able to pass Common Criteria.
• General execution restriction: Obviously a security feature since it offers *some* kind of protection against directly executing scripts received from an external source.
• Script origin restriction: Rather than a crude exec/noexec policy actually takes the origin into account. This is clearly a security feature which offers yet another barrier to injected scripts. With such a policy in place it will be harder for attackers to social engineer an attack.
• Signed script restriction: Beyond the obvious raised security, this also allows use cases such review/approve policies where a reviewer must sign any scripts used by a solution. This allows split responsibilities where it will be harder for a single attacker to compromise a solution by e.g. changing a script he knows is being run under higher privileges.
• Multilevel policies: All of the above policies can be enforced at different levels. With multilevel policies a security architect can put in place a policy where individual users cannot allow e.g. unsigned scripts or where individual users cannot run scripts originating from the internet zone.
• restricted shell. Used for login shells
• Safe data subset. Used to protect against script injections through include files. This way a script can execute an otherwise untrusted script which is only intended to define e.g. localized text. Supports localization and other customization by someone other than the script author while still ensuring that the included script cannot compromise the main scripts variables.

Useerup (talk) 13:12, 19 December 2012 (UTC)

Let me try to transfer the powershell worship to Unix:

• Non-echoing (password) prompt: Yes, this is actually a shell feature.
• Credentials prompt: At least we have ssh public key auth. Not a shell feature.
• Encrypted variables. Sure, you can put encrypted data in environment variables. Not a shell feature.
• General execution restriction: This is a filesystem + kernel feature.
• Script origin restriction: We have the opposite of a restriction: Package repositories provide a relatively safe script origin. Not a shell feature.
• Signed script restriction: Package distributors provide a second layer of security on top of upstream distributors. Not a restriction. Not a shell feature.
• Multilevel policies: Chroot jail or equivalent. Not a shell feature.
• restricted shell: Chroot jail or equivalent. Not a shell feature.
• Safe data subset: The env program can export untrusted key=value data as environment variables, without danger of accidentally executing any of it. Not a shell feature.

84.209.119.158 (talk) 22:54, 10 August 2014 (UTC)

The shell normally won't ask for a password. Some utilities, such as sudo, do, but that's not the shell. So, "Non-echoing (password) prompt" is not even a shell feature, that's a feature of each specific application, combined with a terminal feature. I suggest that non-shell features should be changed to N/A (or similar). — Vincent Lefèvre (talk) 09:45, 11 August 2014 (UTC)

Some shells (e.g. bash) has a specific feature ("Silent" mode) to not echo characters back to the terminal when using the read command. Read "silent" is described as a way to prompt for password in e.g. bash Cookbook by Carl Albing; JP Vossen; Cameron Newham, recipe "You need to prompt the user for a password, but you don’t want it echoed on the screen.". While it is correct that sudo will prompt for password, sudo cannot cover all use cases. Specifically, sudo cannot prompt for password for external authorities such as websites, ftp servers etc. Clearly, bash has a specific feature to prompt for sensitive information, and it is used for exactly those cases. Useerup (talk) 11:38, 11 August 2014 (UTC)

OK, this wasn't clear. But note that this is just a convenience feature since one can do the same thing with all shells by using "stty -echo" / "stty echo". Basically, this is a terminal feature. — Vincent Lefèvre (talk) 15:46, 11 August 2014 (UTC)

Thanks for correcting me. Do we then conclude that *none* of the security features are shell features (belong in this article)?84.209.119.158 (talk) 16:38, 11 August 2014 (UTC)

No, we cannot conclude that. Several of the features are indeed security/safety features. The fact that not all shells have a specific feature does not make it a non-shell feature. Useerup (talk) 16:50, 11 August 2014 (UTC)

A feature that is needed only because a shell is runing on a miss-designed OS, is not necessarily a shell feature and it seems that the features in question are just needed because of the underlying OS. Schily (talk) 17:01, 11 August 2014 (UTC)

@Vincent Lefèvre: In that vein the entire shell could be described as a convenience for launching processes. To use (misuse?) the terminal echo feature robustly you would have to 1) read and store the current setting, 2) switch echo off, 3) read the input from the terminal and 4) restore the stty to its previous state. If the shell provides that as a convenience, it is a feature of the shell. Further, some shells have this feature *without* playing tricks with the tty device (4DOS, 4NT, PowerShell) Useerup (talk) 16:57, 11 August 2014 (UTC)

This is just a few lines to write for something that is not directly used by the shell. Thus this is not a shell feature. Compare for instance with completion or job control, which can only be provided by the shell. Otherwise one could add lots of things, such as socket manipulation, builtin FTP client, date/time commands and so on (all these are provided by zsh, but this is just for convenience). — Vincent Lefèvre (talk) 20:35, 11 August 2014 (UTC)