Talk:Comparison of command shells

Fish should be added

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)

+1 Sedrikov (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)

Archived discussion

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 versus Unicode

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)

Xiki

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)

Dash? Brace expansion?

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)

"General Characteristics", second and third rightmost columns

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

New Security Section

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)

Credentials prompt

At least we have ssh public key auth. Not a shell feature.

Not the same thing. ssh public key auth is no a way to obtain credentials through, say, keycards or time-synch tokens. If a shell is designed to execute scripts, it must also be able to provide authentication on behalf of the user to external authorities. It is true that the unerlying OS should be involved in the auth, but the shell must facilitate it. Useerup (talk) 18:11, 11 August 2014 (UTC)

I get what you say about ssh != keycard, but I fail to understand the rest of your argumentation. Why should the underlying OS be involved in authentication, and why must the shell facilitate it (as opposed to a standalone commandline program)? --84.209.119.158 (talk) 19:59, 14 November 2014 (UTC)

A user may have multiple ways to prove his identity - i.e. authenticate. It is (typically) the responsibility of the operating system to abstract away the inner mechanisms, e.g. drivers for and interaction with keycards readers, rfid tag readers, biometric devices or external identity brokers. A script that needs a user to prove his identity (perhaps just to pass it on) will often not care about how the user authenticates, as long as some authority it trusts vouches for the users identity. This is already what happens when the script asks the operating system about the identity of the current user. The PowerShell Get-Credential will allow a user to authenticate through any authentication mechanism available on the local machine - which can include a broker to an external authority. If keycard reader or biometric devices is installed, the user can authenticate using PIN, keycard, username/password, one-time-password (OTP) tokens, Facebook, Google, and/or 2-factor mechanisms. The script calls Get-Credential and gets back a credential it can present to external entities. It does not care whether username/password or some other method was used, as long as the external entity is content with the credential presented. Useerup (talk) 22:22, 14 November 2014 (UTC)

By definition, the main goal of a shell is to execute commands, in particular external commands. It sufficies that a Get-Credential executable be installed on the system, so that a shell script can execute it. And such an executable would be available not only from the shell, but also from any program. IMHO, any feature that can easily be implemented as an external command should not be regarded as a shell feature. For instance, zsh has a builtin Tetris game, but I wouldn't call that a shell feature. Vincent Lefèvre (talk) 23:17, 14 November 2014 (UTC)

I disagree. The purpose of a shell is to sit around the core OS and expose the OS functionality to the user. Hence the name shell. While most OSes have some concept of pipes/queues/fifos, the idea to create a compound command as a pipeline of commands is squarely a shell concept. The fact that a kernel has a feature that the shell exposes does not make it "not a shell feature". Indeed, exposing kernel/core functionality is the raison d'etre of any shell. But a shell also has some features of its own, typically to make it easier to compose OS and/or external process functionality. As such, the shell delivers the infrastructure that commands can rely on other commands also subscribe to. Example: Clipboard in graphical shells, pipelines in command shells. If it is not offered as a property (integral or emerging) of the shell, commands cannot rely upon other commands understanding it. Authentication is a protocol in the same way that pipelines is a protocol. So if an OS has an integrated concept of authentication, exposing this through the shell is quite similar to how files and streams are exposed through the shell. In PowerShell, you can use the logged-on users credentials, or obtain credentials from an installable credential provider. The credential provider infrastructure is an OS concept, but exposing it to the user (in PowerShell also as a type) is a feature of the shell. It sets the protocol rules and indicates that future/external commands can just use the "credential" type and pass it along (it is a token). Useerup (talk) 12:11, 15 November 2014 (UTC)

Some features can only be implemented by the shell (e.g. pipeline is typically a shell feature). But this is not the case of authentication, at least under Unix. So, not a shell feature for all Unix shells, according to Unix philosophy. — Vincent Lefèvre (talk) 19:23, 15 November 2014 (UTC)

Let's say, syntactic features, must be implemented by each shell, whereas commands do not. Anyway, I absolutely agree that any shell feature that could just as well be an external program, should not count in this article. Because such a thing never occurs on Unix -- it's not considered an acceptible place to put a major feature. For example, implementing ssh as a bash builtin would be a failure to please users of zsh. And bash can't have Linux-specific features, because it's supposed to work on Mac OS X too. (For a real example, look how much criticism systemd has attracted for cannibalizing udev, and for being Linux-only.)84.209.119.158 (talk) 00:47, 25 November 2014 (UTC)

Apparently, a command shell for Windows is and does more than a command shell for Unix. I also heard in school that a shell "sits around the core OS and exposes OS infrastructure, thereby shell". This definition is difficult, as the set of programs in this category seems rather unbounded. Worse, this is hardly a description of what "shell" refers to on either Unix or Windows: an interpreter for an interactive programming language for running commands. The clue is, Unix shells are just that. As an implementation detail, features are implemented in external commands (and libraries) as much as possible. These, not the shell, implement the majority of OS infrastructure. Even basic commands like ls, echo, true, [, cat are standalone executables (some standardized by POSIX). The overwhelming consensus among Unix shells is that any builtin command has to be justified, as either impossible to implement externally (e.g. cd), or beneficial for performance. This modularity craze has its reasons in reusability & portability (see above). It's said that Unix is founded on "programs that do one thing, and do it well". Unix comes in many parts; we must try not to compare a whole car against just the tires of another.84.209.119.158 (talk) 00:47, 25 November 2014 (UTC)

I believe that all of the shells in this article are like that: A very simple set of built-in commands and the ability compose with external commands. That goes for *nix shells, the * cmds for Windows/OS2, the 4DOS/4NT shells as well as for PowerShell. However, the latter deviates from the usual "contract" between the shell and the external tools. In virtually all of the shells, stdin/stdout are the principal interfaces. In PowerShell the external command follows a new contract: External are distributed in modules, execute in-process and support object pipelines. But apart from the different contract, the cmdlets of PowerShell are just as "external" as traditional stdin/stdout tools. Now, for some infrastructure that are naturally part of an OS, the shell can choose to support/expose that infrastructure or leave it to individual commands. Useerup (talk) 23:58, 25 November 2014 (UTC)

For the Unix shells, something like credentials prompt should typically be regarded as an external command, thus not a shell feature for these shells. Vincent Lefèvre (talk) 00:51, 26 November 2014 (UTC)

Where will the credentials be stored between prompt and use? In PowerShell it is also an "external" command - but distributed bundled with PowerShell. However, it does use an intrinsic PowerShell feature: Encrypted strings. So an external command (Get-Credential) prompts for and reads the credentials, returning them as result from the command (on the pipeline). The result is typically stored in a shell variable like this: $mycreds=Get-Credential. The variable then contains the credentials and can be passed to scripts which again can pass it onto external entities like e.g. with the Invoke-RestMethod. As I said elsewhere, given the nature of shells as "enablers" of external functionality, functionality that is usually available along with the shell is in-scope. If available as bundled with the shell or usually available on the system, it should be considered a feature. In the latter case we should note the conditions (like what is done with with the file descriptors and process substitution). How does a script under bash/ash/zsh/ksh prompt for credentials in a generalized, secure way? (i.e. passwords encrypted) Useerup (talk) 01:22, 26 November 2014 (UTC)

Good question. To check if I understand: I suppose one does not simply hand over the decrypted string to the command that needs it, as that would spoil the whole security. So to have end-to-end encryption, the endpoints (the program that implements the prompt, and the program that needs the sensitive info) both need to implement the cryptography (e.g. as a shared library). So: the nearest thing I'm aware of is libsecret (used for storing & retrieving passwords on disk, e.g. wireless password, in at least GNOME/KDE software). Not exactly what you're asking for, but I suppose a hypothetical commandline client to libsecret, that could do the prompting, would be a proof of concept. I'm not saying this is a solved problem, just that it is solvable without doing any of it in the shell. Well, given that shells already implement prompting, this particular thing isn't very far fetched. Still, there is always the usual argument, that a standalone command would enable it for all shells; of course, that entails not bundling it with a shell. This becomes important for substantial features like security often is. Obviously, Microsoft is in a whole nother business, bundling is what they do, with the result that it is extremely easy to tell what's "available on the system". The same makes no sense on Unix -- an awful lot of functionality happens to be available from the commandline, with nowhere to draw the line of what's shell-features and not (and what's "usually available"), if not adhering to the strict principle that only the shell interpreter program is the shell. Thus my general "not a shell feature" stance, though reluctantly ok with secure prompt.84.209.119.158 (talk) 01:24, 1 December 2014 (UTC)

Encrypted variables

Sure, you can put encrypted data in environment variables. Not a shell feature.

Sure, you can find some tool which can encrypt/decrypt. A shell may make that considerably easier (and more secure) by offering it as a feature that works on the shell's own variables. Again, the fact that some shells lack the feature does not mean it is not a noteworthy shell feature.

From bash Cookbook: "Be aware that if you read a password into an environment variable it is in memory in plain text, and thus may be accessed via a core dump or /proc/core. It is also in the process environment, which may be accessible by other processes. You may be better off using certificates with SSH, if possible. In any case, it is wise to assume that root and possibly other users on the machine may gain access to the password, so you should handle the situation accordingly.". If bash allowed you to say read --encrypt -s -p "Password:" you would consider it a feature to avoid precisely these issues (read is a built-in bash command). Useerup (talk) 18:11, 11 August 2014 (UTC)

This is not a shell issue, but an OS issue (feature). Processes can observe what other processes do. If the goal is just to avoid sensitive data to be in a core dump, then one can still encrypt the password on the fly with read -N 1, using whatever encryption method one likes. — Vincent Lefèvre (talk) 20:50, 11 August 2014 (UTC)

How does Powershell pass encrypted environment variables to child processes? Decrypt them first? --84.209.119.158 (talk) 20:33, 14 November 2014 (UTC)

It is not environment variables that are encrypted, it is shell variables. PowerShell is strongly typed, and encrypted strings can be passed as such to cmdlets, i.e. they do not need to be represented as strings as in most other shells. Example is the Invoke-WebRequest cmdlet that takes a -Credentials parameter. Credentials *may* be in the form of username/password - where the password sits in an encrypted string. Useerup (talk) 21:54, 14 November 2014 (UTC)

Execute permission

This is a filesystem + kernel feature.

Which works for the shell command interpreter. On some OSes (Windows, DOS, OS/2) the shells do offer this feature. Cygwin/bash does not use the "execute permission" - even though it is an available Windows permission. Useerup (talk) 18:11, 11 August 2014 (UTC)

Okay, some shells has it, but only to make up for a missing kernel feature. As it is now, this column is more a comparison of (the assumed) operating system than a comparison of shells. How about using the light-green "Optional" template where it's up to the kernel?--84.209.119.158 (talk) 22:21, 16 October 2014 (UTC)

Script origin restriction

We have the opposite of a restriction: Package repositories provide a relatively safe script origin. Not a shell feature.

Package repositories is not a shell feature, I can agree with that. However, the shell actively refusing to run a script that originates from the Internet or an untrusted local network drive is definitively a shell feature in that it is the shell that refuses to execute the script file. Useerup (talk) 18:11, 11 August 2014 (UTC)

Downloaded files do not have the execution bit by default. An untrusted network drive can be mounted without the execution bit. And even if the execution bit is set, this isn't necessarily a problem, because the files will not be in the user's PATH (unless the user chooses to do otherwise explicitly). Then that's up to the user to choose what methods he likes to enforce restrictions. Not a problem.

Note also that with zsh, the user can do any check he likes before executing the command thanks to the preexec hook function.

Vincent Lefèvre (talk) 21:00, 11 August 2014 (UTC)

Isn't this just a substitute for the missing execute permission? That's to say, nobody needs both. Merge into execute permission?--84.209.119.158 (talk) 22:21, 16 October 2014 (UTC)

Signed script restriction

Package distributors provide a second layer of security on top of upstream distributors. Not a restriction. Not a shell feature.

Package repositories is not a shell feature. However, the shell actively refusing to run a script that is not signed according to a shell specification is definitively a shell feature in that it is the shell that actively refuses to execute the script file. Useerup (talk) 18:11, 11 August 2014 (UTC)

This could be done at the same time the execution bit is set. Really not a problem in practice. With zsh, any check can also be done just before the command is executed thanks to the preexec hook function. — Vincent Lefèvre (talk) 21:07, 11 August 2014 (UTC)

Multilevel policies

Chroot jail or equivalent. Not a shell feature.

Jails are not a way to restrict which script files can be executed by a local admin or a local user. It is a shell feature in PowerShell: An administrator can set up a policy where scripts must be signed to execute but still allow local users to change this setting; or he can lock the policy down so that local users (or users of a specific group) cannot change the setting. This is a feature of the shell. In e.g. bash the best equivalent would be if the shell had a feature which disallowed execution of scripts unless their hash could be found in a white-list file, such that the white-list file could be different for each user/group. I will admit that it is not terribly common and may be undue weight. Perhaps we could merge this column with the "signed script execution" ? Useerup (talk) 18:11, 11 August 2014 (UTC)

Well, it is (using hardlinks, mount -o bind or union filesystems to achieve whitelisting). I did not say it was practical.--84.209.119.158 (talk) 22:21, 16 October 2014 (UTC)

Restricted shell

Chroot jail or equivalent. Not a shell feature.

What? The fact that you can start bash with --restricted and enter a restricted shell mode is not a shell feature? Useerup (talk) 18:11, 11 August 2014 (UTC)

Restricted shell features are not related to chroot but permit to prevent to mofify environment variables and to change the working directory. At the time they have been defined, chroot was not intended to create a safe environment but away to setup alternate environments. Chroot now is safer but you need something like zones for safety. Schily (talk) — Preceding undated comment added 08:34, 12 August 2014 (UTC)

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.

But can you invoke a script which allows execution of a restricted set of commands (such as string manipulation, arithmetic functions) that are known free from side-effects (including malicious sideeffects)? PowerShell's DATA section does that. Clearly that is a shell feature designed to allow configuration through shell script but in a secure, restricted way akin to the way login shells restricts the available command set. Useerup (talk) 18:11, 11 August 2014 (UTC)

I admit, that sounds very useful. Hands down. Being able to source a script without side-effects would be an immediately useful security feature, even for a unix shell.--84.209.119.158 (talk) 22:21, 16 October 2014 (UTC)

What about safety?

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:

• Variable in the zero'th argument: Fish refuses to execute the result of a variable expansion, unless adding the eval keyword. This can prevent the user from accidentally executing an incomplete command line.
• Unmatched glob (e.g. touch *.c): This is an error in Fish; the example would not have executed touch at all. Contrast this to Bash, which thinks it's okay to pass the unmatched glob literally, which would cause touch to create a literal *.c file in this example. Alternatively, bash can be told to expand unmatched globs to zero arguments (shopt -s nullglob), which would cause touch to barf in this example.
• Sanity checked environment variables: Fish warns when adding a nonexisting path to $PATH. — Preceding unsigned comment added by 84.209.119.158 (talk) 19:48, 5 August 2014 (UTC)

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

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

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

Vincent Lefèvre (talk) 22:39, 5 August 2014 (UTC)

Many feature issues

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)

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

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

I agree about the "Directory history" point. Zsh is another that has 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)

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

Reopen of "Python and Ruby Shells?" discussion

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)

Agreed --Useerup (talk) 23:51, 28 June 2013 (UTC)

Actually, IPython, being a generic shell, probably should be here. 50.53.15.59 (talk) 11:51, 18 April 2014 (UTC)

Should POSIX shell be removed from comparison?

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)

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)

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)

PowerShell advertising copy

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)

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

Agreed. Hopugop (talk) 15:18, 13 October 2013 (UTC)

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

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)

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)

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

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

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)

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)

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)

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:

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

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

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

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

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)

The main problem

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)

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)

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)

Market share

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)

Qshell

As someone who once had the dubious pleasure of working with AS/400, I have to ask: where is Qshell? Not sure it would check many boxes :) Grover cleveland (talk) 23:42, 28 February 2014 (UTC)

Be bold and add it. Fill out as much as you can. Leave blank/question marks for the cells that you cannot determine. 91.199.208.219 (talk) 16:11, 3 March 2014 (UTC)

preccessor of Bash are not included

clicking through Bash and the preccessors of Bash i got those shells: - sh (Bourne shell), Bash is a Unix shell written by Brian Fox for the GNU Project as a free software replacement for the Bourne shell (sh). - Thompson shell, Developed by Stephen Bourne at Bell Labs, it was a replacement for the Thompson shell,...

why are those not included? (for history comparison) -- 09:55, 9 April 2014 (UTC) — Preceding unsigned comment added by 80.245.147.81 (talk)

performance

In consideration of running shell scripts (rather than interactive use), it seems essential to include some performance metrics. For example, the Korn shell (ksh) is very fast and bash borrows most of its syntax; hence, it's easy to use it for scripting and realise very useful gains in performance (even if bash remains one's interactive shell). Richard Taytor (talk) 04:49, 15 July 2014 (UTC)

The Bourne Shell is also much faster than bash and as fast as ksh93. Check: https://sourceforge.net/projects/schilytools/files/ for an enhanced and portable version of the Bourne Shell. Since it was converted to use vfork(), it was able to close the performance gap to ksh93. Schily (talk) 11:03, 15 July 2014 (UTC)

What is "console redirection"?

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)

Basically yes. I added it as an extra property, because not all shells support it. It is "interesting", because some of the spartanity (like: no popup menus, no colors, no filename completion) of COMMAND.COM can be explained by it supporting this in the DOS environment with its very limited terminal control capabilities. In some of the discussions above it was proposed to illustrate the various shell capabilities also in the context of their different runtime environments and architectural differences. --Matthiaspaul (talk) 03:26, 16 July 2014 (UTC)

Then it seems to be apropriate to chose a different headline. I am still not sure whether I understand what you intend to say, but if you like to say that the typical interactice I/O can be any open file and not only a systemwide dedicated console, then I would propose to use something like "Pty aware" and to make it an explaning link into a section of this article. Schily (talk) 09:27, 16 July 2014 (UTC)

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

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

Yes, an explanation can be added in the future.

--Matthiaspaul (talk) 11:27, 16 July 2014 (UTC)

What about Shell Completion?

What about shell completion? I know that Bash supports variables, files & dirs and arguments, but that CMD supports only files & dirs completion, while Bash is showing a list of all the available options (after pressing twice the Tab button) and CMD is forcing you to cycle through all the available options alphabetically.

Colored Output

What about support for colored output?

That's already on Comparison_of_terminal_emulators. Which is where it should be. --84.209.119.158 (talk) 20:36, 5 November 2014 (UTC)

Bourne Shell in table

Given the fact that the Bourne Shell was originally created in 1977 and then heavily enhanced over the years, it may be a good idea to list the Bourne Shell in two rows:

• one with the features of the initial Bourne Shell fro 1977
• one with the current features

Note that the code size enhanced by a factor of more than 8 since 1977.

Any thoughts? Schily (talk) 12:40, 5 November 2014 (UTC)

It seems that there are no objections. I propose to have the following Bourne Shell variants in the table:

• The original Bourne Shell from 1977
• The Bourne Shell as delivered with SVr2
• The Bourne Shell as delivered with Svr4
• Recent versions with enhancements added after the source was published under the CDDL in 2005.

Note that the Korn Shell is a fork based on the Bourne Shell source that diverted between SVr2 and SVr4. Schily (talk) 10:37, 16 December 2014 (UTC)

Default login shell

I think that in General characteristics, for the Unix shells, "Default login shell" should be changed to "Default login shell for root". Otherwise this is too vague. First, this is a choice of the utility to create the user, e.g. adduser, and its configuration file, e.g. /etc/adduser.conf for adduser. Then this may depend on whether the user is a system user or not. — Vincent Lefèvre (talk) 23:05, 7 December 2014 (UTC)

Are you talking about the program useradd(1m)? It does not look at /etc/adduser.conf and it by default creates an empty field for the shell in the passwd database. Having an empty field at that place causes /bin/sh to be used as a login shell, this is independent from the userid. Which shell /bin/sh relates to, depends on the distribution type. Schily (talk) 11:29, 9 December 2014 (UTC)

I was talking about adduser (which is different). But with what you say, this clearly means that there isn't a unique default shell for users: it completely depends on how a user is created and possibly on what /bin/sh is. — Vincent Lefèvre (talk) 17:40, 9 December 2014 (UTC)

Actually I'm not sure about the non-Linux systems (current information needs to be confirmed). So, I've added the mention "default for root" only concerning Linux. — Vincent Lefèvre (talk) 17:53, 9 December 2014 (UTC)

The table in general seems to need an overhaul. Csh is e.g. not the standard shell on SunOS. It has been the default shell for root on SunOS-3, but after that things changed. Schily (talk) 18:35, 9 December 2014 (UTC)

Snippets column

I propose to delete the Snippets column from the Comparison of command shells#Interactive features section. So far as I can tell from our article on Snippet (programming), this is just another name for a script and it's hard to know why that's an interactive feature anyway. I'd call that a programming feature and one that appears to be offered by every command shell on the list. The whole column is an unhelpful introduction of PowerShell-specific terminology that appears to claim an advantage for PowerShell where none exists. Msnicki (talk) 22:05, 15 December 2014 (UTC)

Actually it seems to be shell functions. — Vincent Lefèvre (talk) 22:12, 15 December 2014 (UTC)

LOL. Okay, whatever they are, it seems to be a new name for old stuff (aliases, procedures/functions and scripts) inserted here in way that implies an advantage for PS that doesn't appear to exist. Perhaps a PS expert might clarify why this special. Msnicki (talk) 22:18, 15 December 2014 (UTC)

Or perhaps the one who introduced Snippets meant some form of keyboard macro. That would be an interactive feature, and there isn't anything yet in the article about this feature. — Vincent Lefèvre (talk) 22:26, 15 December 2014 (UTC)

No, they are not functions, aliases or scripts. Snippets are more like command history, except that they are defined a priori as opposed to picked up from history a posteriori. Functions, aliases or scripts are intended to be used as they have been defined, snippets are templates for commands that are intended to be edited before use. Like history, it is decidedly an interactive feature as it aims directly at command editing. Like history, it is rarely a good idea to use from scripts. A good way to think of snippets is to view them as "prepared history" where the snippets are referred to by name instead of by number and where each session starts with the same set of standard snippets. This is exactly like snippets in programming language editors, hence the reference to the snippets article. Useerup (talk) 22:50, 15 December 2014 (UTC)

OK, so shells that are able to save the history (thus re-read it) support this feature since it suffices to write in a history file (which is a text file in practice). BTW, I do this with zsh for commands (or sequences of commands) I frequently type, and that's true that the ability to edit them is useful. In Unix shells, history items don't have a name, but in most shells, they are incrementally searchable (and if one really wants to give them a name, one can still start them with ": snippet_name;"). — Vincent Lefèvre (talk) 00:22, 16 December 2014 (UTC)

No. It is not the same as the history feature, and history cannot be (ab)used to create snippets as described in the linked article. It is similar and draws on some of the same functions (command line editing). But having the ability to define and/or distribute snippets as part of modules/libraries is distinctly different from automatic history. Both are useful features but the history is changing and non-deterministic under use, while snippets remain static and deterministic. When I invoke history I do so because I know that I typed something similar recently. When I invoke snippets I do so because I have a regularly used pattern or because I want assistance when typing a command or even an entire script block that I have not used recently (or ever). Abusing command history to mimic snippets quickly becomes unwieldy because 1) history is not named, 2) searching for common phrases is polluted with recent incantations of the same command and 3) history is - by nature - constantly changing Useerup (talk) 01:11, 16 December 2014 (UTC)

Could you explain a bit about where are these snippets stored, what they look like, how this "non-static, non-deterministic" part works, and how are they invoked? Sorry to be slow, but I'm still having trouble understanding how this does anything you can't do in a lot of shells with aliases, procedures, scripts, etc. Msnicki (talk) 01:22, 16 December 2014 (UTC)

Maybe this animated gif will explain: . History is "non-deterministic" because it changes with each command. You cannot rely on "muscle memory" as you must view the feedback to make sure that you select the correct command from the entire history. Snippets are predefined, named portions of text that form a complete command line (or part of one). When calling upon a snippet I know that I can type Ctrl-J u n t and I will have the "do-until" snippet selected. Useerup (talk) 06:41, 16 December 2014 (UTC)

Thank you. That was helpful. But that looks more like what I imagine whoever created the "Automatic suggestions" column had in mind, which I note is claimed in the table as supported by PowerShell as snippets. So I'm still not persuaded Snippets is a useful column providing a useful comparison. Msnicki (talk) 07:00, 16 December 2014 (UTC)

Yes, the example (inadvertently) also demonstrated automatic suggestions (typing the "dash" pops up the auto suggestions). However, snippets are a known and useful concept in the realm of programming editors. Snippets adapted for the command line is an equally useful concept, as demonstrated above. Like in programming, snippets can also be used to encourage a specific style, to prompt the user to do it the "right" way and/or to assist the user with constructs that are easily forgotten and/or rarely used. Useerup (talk) 08:57, 16 December 2014 (UTC)

It looks like keyboard bindings as this can be done with zsh: it is possible to bind a function to a key sequence, where the function has access to shell editing commands and features, in order to insert text, look at the current buffer, etc., what is called zle (for zsh command line editor) in zsh. Such functions can either be distributed with the shell or 3rd party, or written by the end user. — Vincent Lefèvre (talk) 07:40, 16 December 2014 (UTC)

It sounds like snippet functionality could be created using extensibility features of zsh? Maybe we should have a section on extensibility? Useerup (talk) 08:57, 16 December 2014 (UTC)

It looks like this is something that can be used in a similar way with the map function of my history editor that maps input sequences into other input sequences. So it is part of my shell and part of my maintained variant of the Bourne Shell. BTW: this map implementation was finished in 1986 (Tschernobyl time). Schily (talk) 10:30, 16 December 2014 (UTC)

It is not part of bourne shell or bash then. Yes, you can code around this and create a directory with snippets (and metadata such as caret position?), create a function that reacts to a certain keystroke, somehow list the names of the snippets so the user can pick one and then insert the snippet code on the command line and calculate the new caret position. I'm sure that can be done (in most of the shells) but it is hardly a feature of the shell, and will require some coding. Feel free to make a note in the table as to how this can be done. Useerup (talk) 12:09, 16 December 2014 (UTC)

As I'm beginning to understand it, what sets Snippets apart from Automatic suggestions is that Snippets might expand into a whole control structure. So why is that different than Command builder, yet another feature claimed only by PowerShell?

Here's my suggestion: Let's roll both Snippets and Command builder into the Automatic suggestions column, noting in the Powershell entry something like "Yes (includes snippets and command builder)", wikilinking the terms appropriately. Msnicki (talk) 20:09, 16 December 2014 (UTC)

Not hearing any objections, I've made the change I proposed. If anyone feels I've misjudged consensus, please revert me and we can continue the discussion. Msnicki (talk) 17:13, 17 December 2014 (UTC)

As I tried to explain to you above, snippets are not automatic. If anything they are like tab completions (must be called upon explicitly), but they are not based on the context (partial name, parameter name). Command builder is a entirely separate concept. It is a GUI interface for filling in parameters to a command. You are collapsing rather different topics which ends up misleading and confusing. Therefore I am reverting. If you want to reduce the table then lets have a discussion about that. A suggestion for that could be to look at joining some of the completion/auto suggestion columns Useerup (talk) 19:33, 17 December 2014 (UTC)

In your animated PowerShell GIF, are the popups happening only when you press a special "give me suggestions" key? Is that your objections to the the word "automatic"? Is that even a distinction anyone cares about? Maybe the column should be simply, "Context-sensitive suggestions". Would it be fair to say that the distinguishing feature of this suggestion feature in PowerShell is that the suggestions can be arbitrarily complex, that, e.g., you click a suggestion and you might get a whole screenful of code you could fill in, continuing to use this suggestion feature? I guess it's combined with context sensitive help but we already have a column for that. What is Command builder besides Microsoft's trademark name for something that's hard to explain and isn't covered by the above? Msnicki (talk) 20:10, 17 December 2014 (UTC)

In the animated GIF I pressed Ctrl-J twice: To pick the "comment" snippet and to pick the "do-until" snippet. The other popups are auto-suggestions (aka "intellisense" in MS parlance) triggered automatically by the dash. Auto suggestions are distinguished from completions in that they pop up automatically and are unobtrusive (they need to be the latter to allow for the former). Completions are by-request (typically TAB key) and are often not unobtrusive: If the suggestion does not suit you, least you have to remove the suggestion (or delete to the end of the line) as opposed to simply ignoring it. Snippets are by-request and covers (as you observed) entire blocks of commands/script code. Completion and auto suggestions are context-sensitive and (in PowerShell) automatically generated from the command, function or script files. PowerShell will look at parameter definitions (types, names, positions) and drive completions/suggestions from that. Snippets are defined using New-IseSnippet or by placing a snippet file in one of the snippet directories. Snippets include caret position indicating where the caret should be placed. Snippets are definitively not completions or auto-suggestions. Useerup (talk) 21:04, 17 December 2014 (UTC)

For a description of the Show-Command command builder see this: [2] or this: [3] Useerup (talk) 21:38, 17 December 2014 (UTC)

Keystroke stacking

What is this? Whoever added it omitted any definition. Googling, it appears to be JP Software's name for aliases, c.f., here, as implemented in their 4DOS, 4NT and TCC products. I believe this column should either be removed or renamed "Aliases". Msnicki (talk) 06:31, 16 December 2014 (UTC)

To me it looks like it is a (very crude) way to automate processes by stuffing the keyboard buffer as if the user had entered the keys. I.e. not aliases Useerup (talk) 08:11, 16 December 2014 (UTC)

The way csh implements TAB completion looks like a variant of this idea as csh uses ioctl (f, TIOCSTI, ac) to simulate terminal input in order to get the characters into the input queue.

On the other side, the Bourne Shell and it's descendents implement a stack of input structures in order to implement macro expansion during command processing.

So I vote for deleting this column except when it possible to describe this as a special feature that can be used intentionally by the user. Schily (talk) 10:21, 16 December 2014 (UTC)

It is undeniably a feature of some of the shells. Presenting it as "interprocess communication" is (IMO) a bit of a stretch, though. I'd call it an "interactive feature" and would assign it low prominence (placed as the last column in the table). It will require an explanation, however, so that readers clearly understand what the feature is and what it can be used for. Useerup (talk) 10:32, 16 December 2014 (UTC)

I concur, without an explanation that helps to understand whether it is a usable feature, it just looks like a me too column that does not help readers. Schily (talk) 10:59, 16 December 2014 (UTC)

Aliases are basically just a crude way of stuffing the input, Useerup. Msnicki (talk) 16:31, 16 December 2014 (UTC)

Aliases are a way to replace the input that is seen by the parser, but this new input is not directly visible to the user. If you like to have user visible replacements, you need the map function as e.g. seen in recent Bourne Shell versions. Schily (talk) 11:36, 17 December 2014 (UTC)

May I ask for a consensus on either (a) removing the column or (b) renaming it as "Aliases"? Personally, I would slightly favor (b) and then properly fill in the boxes for the other shells but it looks like (a) might be favored by others. (I'm okay with either as long as there's a consensus.) I'd like to hear some more opinions before I do anything. Msnicki (talk) 15:39, 16 December 2014 (UTC)

I will suggest that 1) we move the column to the rightmost edge of "interactive features" instead and 2) write an explanation of what it is. I'd be willing to give it a try. Useerup (talk) 16:21, 16 December 2014 (UTC)

Can we try for a consensus here before doing anything? Msnicki (talk) 16:31, 16 December 2014 (UTC)

I think you miss an important part of this: This is not the same as piping characters on stdin. The process on the receiving end of those artificial keystrokes could very well be a GUI application or an "interactive command line" application which does not read stdin. With keyboard buffer stuffing you can achieve a simplistic (and certainly brittle) form of "automation" for interactive programs. I stand by my suggestion for consensus and suggest the following for "explanation": Keystroke stacking is a technique whereby the user tries to anticipate which process/application receives the keyboard focus next (the next application to read the from keyboard) and which state it will be in and thus what keystrokes would cause the application to perform a desired action. The shell utility can then be used to queue a number of keystroke that will be replayed against the application once it receives keyboard focus. This can be viewed as a simplistic form of automation where the shell utility "types ahead" instead of the interactive user. Useerup (talk) 17:09, 16 December 2014 (UTC)

Under Unix, this is done by default: the characters remain in the queue until they are read, and the shell won't read them until this is really needed. For instance, type "sleep 3; emacs -nw", then Enter, and "foo" (during the sleep). One can see that Emacs gets the characters "foo" even though these characters were in the queue before the shell started Emacs. Some command-line applications like Mutt do not take them into account, for an obvious reason (in case they have been entered by mistake, as a single character can trigger a destructive function), but that's their choice. — Vincent Lefèvre (talk) 18:15, 16 December 2014 (UTC)

Does the "keystroke stacking" feature in JP Software's products actually support stuffing of keystrokes into a GUI app started from their product? That's actually an annoyingly hard problem from a console window under Win32 because Microsoft so botched the functionality, so I'm skeptical. If that's the claim, it needs a source. :) It sure looks to me, at least from the example I found (above), that they're only stuffing keystrokes back into their own 4NT command processor's command line with some simple substitutions, pretty much the way an alias would work in any of the C shells listed in our tables. Msnicki (talk) 18:56, 16 December 2014 (UTC)

Source: [4]. Seems pretty clear that they are talking about "activating" the (gui) window that should receive the keystrokes. It's a horrible and error-prone feature; but it's there. Useerup (talk) 21:42, 16 December 2014 (UTC)

Okay. Thank you. Msnicki (talk) 22:48, 16 December 2014 (UTC)

My impression is that this is a feature that cannot be seen as primary shell related but like built-in code that could be implemented separately without loss of functionality. In other words, this looks similar to the functionality that ksh93 gains from having a grep as a builtin. This is different from e.g. the getopts builtin that modifies environment variables inside the shell and thus must be a shell builtin in order to work. Schily (talk) 11:44, 17 December 2014 (UTC)

Which raises an interesting problem, as that strikes me as a very unix'y (as in *sh shells) way to think about it. Other shells have other mechanisms for interacting with "external" commands. PowerShell has a wide bandwidth between the shell and commands, allowing for a more terse core and for something like cd to be implemented as an external command (a cmdlet) that is just bundled with the shell when distributed. PowerShell core has no built-in commands at all - the "standard" commands are defined in modules that just happen to be distributed along with the shell core. Thus, all cmdlets are formally "external" commands and the way are implemented is indistinguishable from the way separately distributed cmdlets are implemented. Drawing the line between "internal" and "external" commands would unfairly exclude functionality of shells like Beanshell, PowerShell etc that have been designed to use a unified model for what otherwise would be regarded as internal and external commands. I don't know a good solution to this problem, but it is clear to me that for readers it makes little difference whether a command/feature is formally external or internal (built-in) as long as it is generally available with the shell. "Available with the shell" threshold would also include the common Unix utilities that are available on any but the most specialized systems as long as the shell (like *sh shells) are designed to be able to take advantage of those utilities. In the case of the keystroke stacking command of JPSoft shells, the command is definitively distributed with the shell and it's description is included within the documentation for the shell. Useerup (talk) 16:45, 17 December 2014 (UTC)

IMHO, the notion of keystroke stacking is meaningless in Unix shells, since the user and the shell don't have to do anything to make keystrokes available to the application (even if it isn't running yet): once the application is running, it gets the keystrokes that haven't been consumed yet. So, what is missing??? — Vincent Lefèvre (talk) 18:00, 17 December 2014 (UTC)

Do you have a common Unix utility that will to queue up keystrokes for an application from script code? I believe that is what 4NT etc does. It is not about actual keystrokes from the keyboard, but rather a command which will simulate the keystrokes and enter those into the keyboard buffer (or message queue) for a given application. It is a crude, error-prone way of achieving simplistic automation for applications that were not designed for stdin or automation (typical for DOS/Windows apps) - like GUI applications. Is there an X utility or something similar? Useerup (talk) 19:55, 17 December 2014 (UTC)

In any case, this is not related to the shell at all. For text terminal applications, one can use pseudo-terminals (pty's), as done by Expect. For X11 applications, there's xdotool. Both can do much more things than sending key events. — Vincent Lefèvre (talk) 00:35, 18 December 2014 (UTC)

Seeing the latest edit, I think that there's a confusion between the shell and the terminal, which are completely different things under Unix. In particular, a shell is a process that runs in a terminal, like any other process it can run. Only the process providing the terminal (the master side) generates keypresses (the alternative is to redirect stdin, which can be done with the shell). Moreover, what is important is not the mean (how this is implemented internally), but the goal. Useerup describes a mean that doesn't make much sense under Unix, while one could achieve the same goal(s) in various ways. — Vincent Lefèvre (talk) 12:11, 27 December 2014 (UTC)

I believe the "terminal" and "shell" distinction is valid under all operating systems. I don't see the confusion. In Windows it would be the console or some other "host" process that is the "terminal". The shell is typically a process running as a child of that process or associated (stdin/stdout) with that process. That's not the issue. At some point I was about to move this column to "interactive features" because it was about "keystrokes". However, it occurred to me that whoever added this column had a reason for putting it in "interprocess communication". I can see why (but it's still not ideal). So you need to see this as a way for the shell to "remote control" other applications. Think of a terminal running under X in Unix where the shell running in the terminal window (or a child process of that running a bundled utility) can activate (bring to foreground) any other desktop window and simulate keystrokes to that window. This is not the same as redirecting stdin at process start; this is about remote controlling an already running process - possibly a GUI process - by injecting fake keystrokes into the keyboard buffer. Given that shells are used for a variety of tasks - among which is to orchestrate and control processes - this is clearly within scope of what is relevant for a shell to do. Do other shells have other mechanisms that are more robust? yes, certainly. This is a crude solution that works under the constraints given by the os the shell was designed for (DOS, OS/2, Windows). Is there a way using e.g. a POSIX standard utility (thus can be assumed to be generally available) where you can inject keystrokes into foreign processes? If so tick yes and include a reference to the tool. Is there a not-so-common utility (there probably is) which does this? If so, tick no but add a note "but 3rd party utility xxxx exists". Useerup (talk) 16:31, 27 December 2014 (UTC)

I don't believe that "Aliases" is the right term for that, I would like to see an explanation that help to understand it's real purpose. Schily (talk) 16:27, 16 December 2014 (UTC)

If piping to stdin does not qualify, the definition needs to say so. Otherwise, this looks like a glaring omission of the yes command.84.209.119.158 (talk) 11:47, 23 December 2014 (UTC)

I think that piping to stdin qualifies only for commands that do not expect to be connected to a terminal. But for commands that need a terminal, I've given external solutions. In any case, a command is not necessarily started by a shell; therefore any universal solution is an external one (i.e. not from a shell). Vincent Lefèvre (talk) 20:51, 23 December 2014 (UTC)

Examples section

I added an examples section intended for examples of usages of shell commands. I believe this is a great way to illustrate the shells as a compliment to the rather abstract tables (and text).

The edit was promptly (within minutes) reverted by User:Msnicki with no prior discussion on this talk page and only the following reason for the revert: Please, let's not start comparing sample scripts written in different shells on this page..

The example I included even has an interesting historic background, which could further help make the article more interesting.

Please state your reason here for why we should not use illustrations to make the article more readable. Useerup (talk) 16:42, 27 December 2014 (UTC)

I don't think it does make it more readable. Even within the individual articles on each these shells, we tend to be careful about examples because this is not a WP:HOWTO manual. But here, it's even less helpful. The rest of the article offers a (mostly) quick check-box style comparison of features. Your boxes will contain algorithms and code samples. That's not at all consistent. And how shall we choose these code samples without inevitable claims of unfairness? We should not go there. Msnicki (talk) 16:59, 27 December 2014 (UTC)

Examples are illustrations that serve to illustrate the differences that are described in abstract by the text/tables. There is no risk that this will turn into a "how-to". Reverting an edit (without prior discussion) because of a perceived, abstract risk is not the way you do this. Disagreement is not a valid reason for reverts. Examples are especially useful here because through illustrations we can highlight the interesting differences using a reference that most readers will understand. Samples in articles about individual shells would serve to illustrate common ways to solve a problem with that particular shell. Here the examples would serve to illustrate the different ways the shells are designed to be used. In addition, the examples would nicely circumvent the inevitable discussion about whether something is a feature of the shell or rather an external feature, bundled/not bundled, common/uncommon. The examples would illustrate how a typical user works with the shell - including external utilities - to perform a task. As to how we choose: Be bold, add an example or edit an existing one. We discuss here what whether it is relevant, whether it could be included as part of another example. The example I started with is very relevant as it has been shown by well-known scolars (Knuth, McIlroy) to illustrate the very point of Unix utilities and pipelines. We can not exclude illustrations just because you perceive a debate. Risk of debate is not a valid reason to leave out content. We will always have debates, and I believe that the more concrete the topic the higher chance that it can be settled by editors. Useerup (talk) 17:56, 27 December 2014 (UTC)

Of course a disagreement over content is a valid reason for a revert in article space. In fact, it's the usual reason. When making changes to an article, of course you're encouraged to be bold. But you're also encouraged to presume that whatever's there represents an existing de facto consensus. When making changes, be bold, but expect that the more bold you are, the more likely others might object. It could be that you'll persuade most people (maybe even me) that we should add sample scripts, exactly as you propose. But you should not be surprised if you make a change without previously discussing it on the talk page and then get asked to demonstrate you have a consensus behind it. Apologies if I seemed disagreeable or difficult. That's not my intent. Msnicki (talk) 18:19, 27 December 2014 (UTC)

I don't think examples would be useful. In particular, on the example that was given, only one feature of shells was shown (a pipeline), with a useless use of cat, and the illustration was more on the existing utilities. — Vincent Lefèvre (talk) 21:13, 27 December 2014 (UTC)

What would be your criteria for when an example could be useful? Agreeing on the criteria, maybe we could work from there? Useerup (talk) 01:34, 28 December 2014 (UTC)

• Oppose. As I explained above. Msnicki (talk) 18:31, 27 December 2014 (UTC)

Msnicki, I called for a debate, not for a vote. Why would you go straight to a vote? The idea is the we try to form consensus, we are not anywhere near a conclusion yet. Useerup (talk) 21:06, 27 December 2014 (UTC)

Editorial comments in footnotes

Footnotes are where the reader expects to find reliable sources of information to substantiate a statement, rather than unsourced commentary TEDickey (talk) 12:51, 26 April 2015 (UTC)

Since you seem to have problems with a text that is there since 3 years, it would help if you did explain what you have in mind. It does not help to send text that other people cannot understand. Note that the original repository from Sun disappeared. It could verify that in fact the CDDL is the license chosen by the license holder. If you like to see more than a copy from the Sun repository, I recommend you to do some homework and find a quote that is good enough for you. Schily (talk) 13:25, 27 April 2015 (UTC)

Other editors can comment on improperly written text, no matter how long, or who the author of the text is. Since you have long been in the habit of making unsubstantiated statements, there is of course a large amount of material to work with. For instance, your edit here ignores one tag (which you added recently) and demands agreement for an older opinion. TEDickey (talk) 00:50, 28 April 2015 (UTC)

Well I am known for adding text to WP that has been verified. It is you who repeatedly comes up with unverified and false claims - usually as a result of missing background information. If you can disprove things using trustworthy sources, yo are of course welcome. I am of course shure that you cannot give a trustworthy source that disproves that Sun did legally put the Bourne Shell source under CDDL. Schily (talk) 09:28, 28 April 2015 (UTC)

The tagged statements did not provide a reliable source for the reader. Your opinion of their truthfulness is irrelevant (and ironic in the context of your repeated accusations of "false information" for sources given by other editors). TEDickey (talk) 00:51, 29 April 2015 (UTC)

Help:Footnotes clearly says that footnotes can be used for explanatory information, not just for reliable sources. But both kind of footnotes should be separated by using groups, possibly a predefined group in order to separate notes and references in a standard way. See also Notes and references. Vincent Lefèvre (talk) 07:22, 29 April 2015 (UTC)

Sure - but in the tagged items, there is no reliable source on Wikipedia which supports the comments. In the usual case, explanatory comments are used to tie together existing sourced information to help the reader understand the topics. These do not fall into that category. TEDickey (talk) 08:07, 29 April 2015 (UTC)

Back to the discussion regarding "Since mid 1990s". Given the release dates for Solaris, that refers to 2.5 or 2.6, nothing later. However, there appear to be no reliable sources which would be relevant. The earliest which I find dealing with Solaris and UTF-8 is for Solaris 8 in 2000. Both Markus Kuhn and Sven Mascheck mention this in their pages. Kuhn's comment about partial support for UTF-8 is borne out by the Oracle/Sun documentation noted here (the terminal emulator and the print utility are the only features which the authors found worth discussing). Their links to Oracle's site are defunct of course. But a web search found these:

• Unicode Support in the Solaris Operating Environment
• International Language Environments Guide

The reader will also notice that the latter document is dated 2005 and 2010, but has little real difference from the first document, aside from mentioning xterm. The wording of the comment hints that it refers to the now-defunct Sun-specific xterm. Without some specific quote from these (perhaps overlooked), or a comparable source, it seems likely that any UTF-8 support as such in a shell from Sun in the mid-1990s would have been of the trivial sort: characters in comments or quoted strings. If that is all, then there is no point to be made, because at that level it would have been indistinguishable from other implementations. TEDickey (talk) 00:19, 1 May 2015 (UTC)

The Bourne Shell from 1988 (first SVr4 variants) already includes multi-byte support. In May 1995, the code was changed to use the now standardized libc interface functions tor i18n. UTF-8 support in the Solaris libc and the locale definitions seem to have appeared around late summer 1996. A quick check in the usenet (comp.unix.solaris) verifies that Solaris-2.6 definitely included UTF-8 support. Feel free, to present reliable sources to prove something more specific. Presenting a lot of non-relevant stuff in hope to be able to take people by surprise definitely does not help and does not account for a reliable source. Schily (talk) 11:42, 4 May 2015 (UTC)

If you had a reliable source, others would assume you will provide a concrete example rather than simply stating that it must exist. Without the example, the edit can be removed, since you are unwilling to substantiate your remarks. TEDickey (talk) 00:33, 5 May 2015 (UTC)

Given the fact that your claim and your pointers have been verified as unreliable sources, I am a not sure what you intend with your claims... If you don't like my verified text, you should be able to give reliable sources to verify your claims. It however seems that you are not able to give us reliable sources to verify your claim. Schily (talk) 12:46, 5 May 2015 (UTC)

You're attempting to make a joke, of course, because no other interpretation of your comments during the past week can lead to any other conclusion. TEDickey (talk) 00:44, 6 May 2015 (UTC)

If you like to introduce claims that are in conflict with source comments or meta data, you would need to give a reliable source for your opinion. Similar to many other cases in the past, you seem to be unable or unwilling to give reliable source for your claims. This looks like another attempt to waste other people's time. Fell free to give reliable sources for your claims if you like to continue this discussion. Schily (talk) 12:17, 6 May 2015 (UTC)

I gave four sources; you have provided no information whatsoever. TEDickey (talk) 01:04, 7 May 2015 (UTC)

I have reliable source, you did not give reliable sources. Come back when you have very reliable sources as you need to disprove the source state to verify your claims. Schily (talk) 08:52, 7 May 2015 (UTC)

Well, here's the problem: there is no evidence that you have any reliable source of information (aside from quoting yourself). And you insinuate that anyone disagreeing with you is a liar. So there's nothing of worth in your comments. Have a nice day. TEDickey (talk) 02:38, 8 May 2015 (UTC)