Talk:Comparison of command shells/Archive 2

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)

1. [1]

   http://technet.microsoft.com/en-us/library/hh847864.aspx. {{cite web}}: Missing or empty |title= (help)

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)

This is an archive of past discussions about Comparison of command shells. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.