Talk:Comparison of command shells

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)

Given that it would be of far too great a scope to list and compare the details of every POSIX implementation of sh, I agree, the entry serves both a practical and relevant purpose. ArabOrange (talk) 15:15, 14 October 2021 (UTC)

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)

I've removed some of the obvious powershell advertisements but there is still a lot left. I encourage any better writer than me to clean it up farther. I've removed some sections (e.g. "native" CIM/WBEM; obviously trying to move the goalposts from CIM/WBEM by specifying it must be completely native, and nonetheless it's a very strange feature to expect from a shell. I doubt anyone came to this article looking for comparisons of CIM/WBEM support between different shells). I've merged some sections (PS had 3 sections on how it blocked untrusted scripts, and "snippets" is clearly part of the IDE that it advertises as one of its features). 80.189.144.187 (talk) 23:23, 17 July 2015 (UTC)

IMHO, "Progress indicator" is another PowerShell advertisement. Under Unix, I don't see any reason why it would be related to the shell. A command that can provide progress information can always output it to the terminal directly (when connected to the terminal) or output such information in another way (e.g. in a graphical dialog box). Vincent Lefèvre (talk) 00:19, 18 July 2015 (UTC)

Agreed with the progress indicator. `pv` and `zenity` are examples of how you'd get a progress indicator done traditionally, and that's using an external process. I think advertising it as a function of the shell is a little disingenuous when it's just "not done that way" in other shells. If someone sticks a web browser in a shell then adds "HTML5 Support" "Flash Support" "Javascript Support" "DOM manipulation" (...) to the table because their shell supports it, it doesn't make it a "shell feature" if you see what I mean there, and I think this is what's been done (but in a subtler way) with PowerShell. 80.189.144.187 (talk) 11:38, 18 July 2015 (UTC)

Agreed. Many of the features on this page are either biased towards PowerShell, or so oddly defined as to be nonsensical. For example, in the `Programming Features' section, Bash is listed as being unable to do Arithmetic -- and yet echo $[2+2] (a shell builtin) returns 4. Admittedly it's only integer arithmetic, but still. I have no idea why this is missing. Likewise, in the comparison of features section, Syntax highlighting is listed as being "no" for everything except PowerShell "(In ISE)". This is like writing "Yes (In Vim)" by Bash, or anything else you care to mention. It's also the case that one can define syntax highlight quite easily in most of the UNIX shells, if desired. It's just not enabled by default at the prompt. This article needs attention. 81.110.99.109 (talk) 21:57, 19 September 2015 (UTC)

For Bash, it is said Yes concerning Arithmetic. Vincent Lefèvre (talk) 00:06, 20 September 2015 (UTC)

No, PowerShell has a separate channel for conveying progress information. Think distinction between stdout and stderr in Unix. Rather than the 2 from the OS, PowerShell has Success output, Errors, Warning messages, Verbose output, Debug messages and information messages. The shell has special support for displaying the progress messages semi-graphically and to avoid polluting the regular output with the progress messages. If you write Write-Progress "Creating users" the shell will display a box with the text "Creating user. Processing" along with a progress bar. It will be displayed until another progress message is displayed, or until the script ends, at which point the message will disappear. This will work across remote connections as well a for background jobs, i.e. the progress messages are not just output to an output stream, rather they are marshalled to the ultimate controlling interactive shell and used to display progress information there. Given that command shells are often used to create long running scripts - even spanning multiple hosts or managing multiple background jobs - the ability to marshal back reliable progress information as it happens is clearly a valuable feature. 91.199.208.219 (talk) 05:37, 5 August 2015 (UTC)

Under Unix, one can use file descriptors other than 0 (stdin), 1 (stdout) or 2 (stderr), so that progress information can be sent wherever one wishes (this can be done without any interaction at all). Shells with arbitrary stream redirections (e.g. POSIX shells and compatible/enhanced) will have no issues; the other ones may be more limited. When the shell script runs in a terminal, it is also possible to use terminal escape sequences (but one needs to make sure that no processes output data to the terminal in the background at the same time). So I don't see what is missing (at least for the modern Unix shells), given the fact that depending on the context, one can choose the most convenient solution. — Vincent Lefèvre (talk) 17:41, 23 February 2021 (UTC)

And there are other convenient ways to pass information without having to use the standard output (stdout) or error (stderr) stream of the shell script, for instance named pipes (e.g. with the POSIX mkfifo command). So a shell script can use one to pass progress information, and the progress indicator program can read such information from this named pipe. See also various solutions proposed on Stack Overflow in How to add a progress bar to a shell script? (not all of them work under any conditions). Remember that Unix shells can be run from anywhere: with or without a text terminal, with or without a graphical interface..., so that there cannot be a single interface for progress information. — Vincent Lefèvre (talk) 18:35, 23 February 2021 (UTC)

For Unix shells, "Untrusted script blocking" should probably change from "No" to "N/A" (ditto concerning "Execute permission" with a change from "Yes" to "N/A") because these are not shell features and blocking the execution isn't even permitted at this level. In any case, permission control is better done upstream, e.g. at the kernel level, in particular because this could be implemented only once and this is not specific to scripts. Vincent Lefèvre (talk) 00:45, 18 July 2015 (UTC)

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)

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)

Beanshell

Should beanshell be included at all? This is after all a "Comparison of command shells", and beanshell seems to be more of an attempt at a Java REPL than a shell. One could easily include python as a shell under such a loose definition of "command shell". Its wiki page refers to it as a "Java-like scripting language" rather than a shell, and its official website calls it "Lightweight Scripting for Java" and states that "BeanShell is dynamically interpreted Java, plus a scripting language and flexible environment all rolled into one clean package". Nothing but the name suggests that it might be a command shell. 80.189.144.187 (talk) 21:15, 17 July 2015 (UTC)

Remove the "ISO 8601 support" column?

IMHO, it is too vague. The date and time can be used for very different purpose, often via external utilities. So, the answer is not much meaningful. Vincent Lefèvre (talk) 16:02, 25 January 2016 (UTC)

I would be happy with a removal. We should also check whether other columns that apparently have been added to let some Win-DOS shells look better should be removed. Schily (talk) 16:10, 25 January 2016 (UTC)

Mandatory argument prompt

I would say that this should be N/A for all Unix shells: the shell cannot know in advance what an arbitrary utility will require, and the utility can have code that checks its arguments. Prompting is then a standard feature of the terminal, not the shell. Vincent Lefèvre (talk) 16:41, 25 January 2016 (UTC)

Correct: The description does not apply to any UNIX shell as this seems to be a requirement that a standard environment cannot implement: how should a shell know about whether an invoked utility may ask for more input later? Schily (talk) 17:02, 25 January 2016 (UTC)

Missing important differences between shells

The whole set of tables contains many features that do not apply to a standard (UNIX) environment at all, but there is not a single feature in the tables that would allow to distinct a POSIX shell from a SVr4 (1989) Bourne Shell.

To get an impression about the differences in question, it might help to look at the enhancements that have been implemented in the Bourne Shell since 2006: http://schilytools.sourceforge.net/bosh.html Schily (talk) 17:11, 25 January 2016 (UTC)

Important is also the Shell page from Sven Maschek: http://www.in-ulm.de/~mascheck/bourne/ Schily (talk) 19:08, 25 January 2016 (UTC)

Archiving

I archived some discussions, but I left a few which seemed like they might have loose ends that could be tied up... basically a lot of debating around the appropriate way to compare Powershell and Unix shells, which have a different approach (with Powershell more monolithic). II | (t - c) 09:13, 17 October 2016 (UTC)

We should mention Windows 8 and Windows 10

I did a Ctrl-F of "Windows 8", "Win8", "Windows 10", and "Win10", and found no occurrences of any of those strings. Windows 7 is the latest version of Windows mentioned in this article. People who come to this article are likely curious about the roles of these two shells in the two latest versions of a very popular operating system, and the article currently lacks this information.

Does ReactOS have CMD.EXE and/or PowerShell? I am curious. Does anything else have either of these Microsoft shells, or emulate them?

Should this article mention Cygwin as a way to get a Unix/POSIX shell on Windows?

I don't have any high-quality sources to cite, but I would say that CMD.EXE is clearly the default shell in Windows 8. It appears when you right-click on empty space in the File Explorer (in the menu), and PowerShell does not appear. CMD.EXE is also the default application to open .BAT and .CMD script files, much as Bash is the default application to open .SH files on MacOS or most flavors of GNU/Linux that have not been customized to do otherwise.

I'm honestly not sure what the default is in Windows 10, both CMD.EXE and PowerShell seem to be first class citizens. It appears that right-click on empty space now gives PowerShell in the menu (CMD.EXE has been removed), but it seems that .BAT and .CMD files are still by default executed by CMD.EXE on Windows 10, so they are each default in different contexts. In many respects, I feel that CMD.EXE is still more powerful and more widely used. Fluoborate (talk) 15:29, 23 September 2017 (UTC)

The Mashey shell, aka the Programmer's Workbench shell, is missing from the table

The Mashey shell, aka the Programmer's Workbench shell, is missing from the table. Hmmm, why?

There was an early split of UNIX versions, at Bell Labs, around 1976. The Programmer's Workbench was forked from Research Unix, around version six, prior to the development of version seven's Bourne Shell, with the intent that its users would be using it to manage the code they were developing for other systems.

I never saw it in use, but I read a couple of papers Mashey wrote on it. Geo Swan (talk) 01:56, 28 January 2019 (UTC)

Recent removal of command shell features from comparision

It seems that certain notable command shell features are being removed from this comparision with the only argument being "because the only thing mentioned was PowerShell" and "Power. Shell. Goodbye!". I think this is wong. If your favourite command shell does not have the maximum number of supported features then you alter the criteria? Ghettoblaster (talk) 17:37, 28 July 2021 (UTC)

Yes. In this situation, PowerShell is the outlier in comparison to all other shells on this page in terms of its features.

I believe adjusting or removing the irrelevant information on PowerShell is justified, not only because the overwhelming majority of this talk page agrees with me that this article is unnecessarily weighted towards PowerShell, or that there is a template message at the top of the page that further supports this.

I would like to present Ghettoblaster's edit statistics, which were retrieved from WikiChecker.

Scrolling to the bottom of the page and opening the "Frequently edited pages" dropdown reveals that the majority of their many edits have been on Microsoft or Microsoft-related articles.

PowerShell is a Microsoft product.

I don't think it's unreasonable to say that it is very likely that this user has a bias towards Microsoft and its products, and has found it necessary to advertise their favourite command shell.

I would like to note that I am not suggesting that the differences between PowerShell and the majority of other traditional shells be ignored, I believe that the way the mentioned included in this article are irrelevant to the article. I believe that they would be relevant on the article dedicated to PowerShell, perhaps in the section comparing cmdlets to their similar equivalents on other systems.

I am going to edit the article to rewrite and prune the information concerning PowerShell in an attempt to amend the article to reflect Wikipedia's standards. If anyone disagrees with this, please explain to me why that is. Wetsocks3499 (talk) 17:36, 13 October 2022 (UTC)

I agree. IMHO, various Windows shell features are not directly related to the shell and could be implemented elsewhere (in various ways) or could be meaningless as far as the shell is concerned. For instance, it is not clear what "Command builder" is and it probably doesn't make any sense with traditional shells. Ditto for "File/directory passwords". — Vincent Lefèvre (talk) 23:34, 13 October 2022 (UTC)

I think that it's also important to note that the PowerShell ISE is distinct from PowerShell itself, and is therefore not relevant when comparing its features to command shells. Please see this link to its documentation. Again, this information is useful, but ideally it should be placed in a different article. If anyone disagrees, please explain to me why. Wetsocks3499 (talk) 13:37, 26 April 2023 (UTC)

Consensus on external programs?

I'm wondering what people's opinion is on including external programs other than the shell itself in this article, notably in the sections mentioning progress indicators. the "Progress indicator" section itself seems to only exist to mention PowerShell's progress indicator builtin / API. None of the other shells listed in the article provide integrated progress indicators, the closest you can get is piping through a standalone program, which by definition is completely unrelated to the shell program itself.

Does this need to be addressed by editing, or is explicitly mentioning that the indicator is external sufficient? Wetsocks3499 (talk) 15:22, 21 October 2022 (UTC)

The tables need some way of filtering

It is incredibly hard to read and compare the shell features when they are presented as one overflowing table. Something similar to https://www.mediawiki.org/wiki/Extension:FilterableTables could be used for that, I don't know how to do that though. Right now those tables are virtually unusable for comparisons. Fyul e'Cuest (talk) 17:51, 24 March 2024 (UTC)

Default script shell

The first table currently says that bash is the default script shell in Linux. However, this is not true for all Linux distributions. In Debian and Ubuntu, this has been Debian Almquist shell (dash) since Ubuntu 6.10 (2006) and Debian 6 (2011). — Vincent Lefèvre (talk) 11:49, 16 August 2024 (UTC)