Talk:Bash (Unix shell)/Archive 1

Archive 1

Install instructions?

I don't think that the Bash installation instructions should be part of this article — they just duplicate the same information in the bash distribution (and probably do an inadequate job of it). Does this kind of information really belong in an encyclopedia? --Neilc 07:56, 30 Nov 2004 (UTC)

I feel the same way. --Mark Bergsma 15:13, 30 Nov 2004 (UTC)

I've commented out the "How to install Bash" section for now, but the reason I added it in the first place was because Bash is often an add-on shell (i.e., it doesn't come with every UNIX system), so people who want to start using it need to download, build, and install it themselves. This is not hard to do if you are a programmer, but non-programmers often have no idea what to do with a tarball after they download it, even if they know in some abstract way that a "build and install" must be done. Perhaps a reduced summary of this section should remain to help such a user? — franl 16:55, 30 Nov 2004 (UTC)

Very well, but that still belongs in the documentation, not in an encyclopedia. Perhaps add a convenient link to it. --Mark Bergsma 20:05, 9 Dec 2004 (UTC)

I agree. I think this encyclopedia article should link to installation instructions, rather than explain how to install Bash. I suggest moving the "How to install Bash" section to Wikibooks: Bash Shell Scripting, leaving behind a link to that Wikibook. --DavidCary (talk) 15:02, 19 December 2014 (UTC)

OSX

"Bash is the default shell on most Linux systems as well as on Mac OS X "

I thaught CSH was the OSX one? —Preceding unsigned comment added by 86.16.160.17 (talk) 19:18, 26 November 2007 (UTC)

At least on my Leopard (and previous Tiger), it is Bash. — ww —Preceding unsigned comment added by 118.26.230.12 (talk) 17:00, 15 April 2008 (UTC)

BASH is the default shell on OSX. 98.149.80.248 (talk) 05:58, 28 January 2011 (UTC)Nanoatzin (talk) 06:00, 28 January 2011 (UTC)

How to test for file extensions

I suspect this is the wrong place for this (that's why I'm not putting it in the article) but this little tip needs to be better promoted, so if you know of a better place for it, please move it there. In any case...

When writing a bash script which should do different things based on the the extension of a file, the following pattern is helpful.

#filepath should be set to the name(with optional path) of the file in question

 ext=${filepath##*.}
 if [[ "$ext" == txt ]] ; then
   #do something with text files
 fi

(My source for this is the slike.com Bash FAQ. Maybe this should go in the Wikibook on this subject, or in some kind of Bash Cookbook? --JesseW 21:54, 21 July 2005 (UTC)

I'd suggesting starting a new chapter in the wikibook.... how about wikibooks:Bourne Shell Scripting/Cookbook? Lupin 23:48, 21 July 2005 (UTC)

Ok, I've moved it there. That will be my first real edit to Wikibooks... Maybe something will get started... --JesseW 01:05, 22 July 2005 (UTC)

A note on the code above: - first, it's not correct if the file doesn't contain any dot. Like a file called "txt" will be said to have a .txt extension while it doesn't - second, it's a non sh syntax for which there is a better sh equivalent (it's preferable to write a script using a standard syntax rather that the syntax of one specific version of one specific shell implementation):

 case $filepath in
   ?*.txt)
     # do something with text files
     ;;
 esac

—Preceding unsigned comment added by Stephane Chazelas (talk • contribs) 00:17, September 10, 2006

Linux vs. GNU/Linux

I can't help but feel that this change is in factual error. As Bash is a GNU product, on a presumptive non-GNU-based Linux system, it would not be the default shelll. Please don't turn this into a flamewar over the term GNU/Linux vs. the name Linux alone; this is merely an inquiry into whether a non-GNU-based Linux distribution would use Bash as its default shell. Jouster 20:45, 22 August 2005 (UTC)

I think its alright the way it is. You see, in my opinion, the word Linux here imply the kernel, not the who operating system. If it was the later, I think the edit would have been a mistake. Now, some bash tricks [1] —Preceding unsigned comment added by Wk muriithi (talk • contribs) 16:37, November 29, 2005

Bash commands

How about a list of Bash commands? --88.111.52.30 15:48, 29 December 2005 (UTC)

Probably not. Such a list is not particularly encyclopedic or interesting- Wikipedia is not a repository for manuals after all. --Maru (talk) Contribs 18:12, 30 December 2005 (UTC)

I think it'd be worth mentioning that using the help command will bring up Bash-integrated commands (which are noteworthy different than those in /bin ). Particularly, using foreground (fg) and background (bg). Likewise, how the shell interprets keybindings such as Ctrl-Z and Ctrl-C. 69.22.210.109 19:05, 25 July 2006 (UTC)

Pipes

I have to say that I'm a little disappointed by the lack of the discussion of pipes. —Preceding unsigned comment added by 69.25.215.133 (talk • contribs) 17:29, January 12, 2006

Agreed, more elaboration on pipes & filters, and their use vis-a-vis "everything is a file" and /proc would greatly improve this article. 69.22.210.109 19:07, 25 July 2006 (UTC)

Everything is a file is great, but it's an operating system feature, and bash (by design) doesn't know anything about it. Many platforms on which bash works just fine don't have /proc or /dev/tcp or anything else along those lines. --TotoBaggins 05:22, 11 March 2007 (UTC)

Something about coproc would also be acceptable. condor (talk) 13:04, 21 February 2014 (UTC)

Integer Mathematics

I don't really understand this:

"A major limitation of the Bourne shell is that it cannot perform integer calculations without spawning an external process. Bash can perform in-process integer calculations using the ((...)) command and the $[...] variable syntax, as follows:"

So it can't do calculations without spawning an external process, ok... but wait, here's how to do it 'in-process'? Confused. --Ling

Bourne can't do integer calcs in process, but Bash can. Masterdriverz 17:21, 13 May 2006 (UTC)

• • • The last thesis is real wrong. to calculate in correct mathematic forms doesn't count on the interest of thirds. Jur is a medium to stop powerabuse of a programm that deals with wrong stuff and sadist interest.--Raskollnika (talk) 09:02, 6 September 2010 (UTC)

OpenBSD

Some of the bits in here don't work on OpenBSD, although they do on Linux. —Preceding unsigned comment added by 66.192.62.82 (talk • contribs) 15:39, July 26, 2006

Could you be more specific? Which bits don't work on OpenBSD? --maru (talk) contribs 00:05, 27 July 2006 (UTC)

Unsorted comments about the bash page

First, about the credit. I don't think any of the feature described in the page was of the bash authors' invention. Most if not all features are copied from other shells: ksh for the syntax, csh/tcsh for the history and user interface and one or two zsh features. Maybe those features would be better introduced in the ksh/csh/zsh pages instead.

Minor point:

it should be:

echo "$((...))" instead of echo $((...)) as bash performs word splitting upon arithmetic expansion in that case (contrary to pdksh or zsh for instance).

It may be good to say that $[...] shouldn't be used as it's not a standard sh syntax contrary to $((...)).

The exit status of ((...)) is 0 or 1 depending on whether the expression resolves to 0 or not (a non-zero expression means "true" so a 0 exit status). So ((1+1)) is true and ((1-1)) is false.

bash has several I/O redirection syntaxes that the traditional Bourne shell lacks. bash can redirect standard output and standard error at the same time using this syntax:

The Bourne shell doesn't lack that. bash is only providing with a short cut. &> foo (why didn't bash just used the same as csh or zsh: >& ?) is the same as > foo 2>&1.

<<< 'string' is inherited from ksh93 which inherited it from zsh which inherited it from rc.

The regular expression syntax is the same as that documented by the regex(7) man page.

That regex man page when it exists documents several regexp formats. bash implements the POSIX extended regexps.

About startup scripts, it should be noted that some Linux distributions for instance may interfer with that by changing some default configure values at compile time (like enabling a system-wide bashrc or disabling the sourcing of bashrc on rsh or ssh connections). —Preceding unsigned comment added by Stephane Chazelas (talk • contribs) 00:56, September 10, 2006

You seem to know a lot about the various shells, so don't be shy about improving the article itself rather than noting its problems in here. Thanks! --TotoBaggins 05:15, 11 March 2007 (UTC)

Bash special characters

For example, the character % and & does have a special meaning. So, say I dump something to stdout, I need to escape those characters. It would be nice to have a list here because printf won't work as expected. Sure, I know you can do all the aliases you want. I know it's likely to have been listed in the docs, but I'm rather sure it could be a nice addition and does not seem to require much work by people having to deal with this all days. Thanks!
83.190.231.93 21:33, 11 December 2006 (UTC)

Article Cleanup Co-Ordination Point

I'd say a lot of the examples should be removed or moved to Wikibooks if they're not there already. Concepts like I/O redirection need only be linked to the articles which describe them, and a brief introduction given here. [edit - first we need to create the I/O redirection article :-]

Some random questions it might answer:

• Does it have a larger overhead than other shells, as it does have a lot of features?
• Is there a port for Mac or OSX (I would assume so - also is it the default for the X terminal thing)?
• For builtin commands like test and pwd which also have an entry in /bin, are they really builtin or does it just call the other program?
• Bash shares a lot of features in common with perl - but perl is generally used for web applications, but why? Is it less secure, harder to write complex applications in, etc?

One final fact (from the bash docs), when bash is run through a symlink called "sh", it will mimic the historical POSIX sh functionality more closely. --h2g2bob 10:41, 20 March 2007 (UTC)

>Is there a port for Mac or OSX (I would assume so - also is it the default for the X terminal thing)? That's a good question, unknown guy from 2007. Yes, there is a port of bash for Apple's little beasties. There's some vestigial UNIX-ness under the hood that would allow this. About the login shell, as of macOS Catalina the default is zsh instead of bash. I believe it used to be bash, but I'm not certain. Wetsocks3499 (talk) 15:35, 28 July 2021 (UTC)

Versions

Anyone want to mention the differences between versions? I thought there was a version 1.0 and a version 2.0. Am I correct? Anyone want to mention this? --Bill.albing 19:17, 21 December 2006 (UTC) $Insertformulahere$

Elements of Style

Some people write admirably well considering they're not professional writers but in general Wiki would benefit by trained proofreaders. Another recurring annoyance is how people in the US (possibly North America) insist on putting double space after a full stop when they should know by now it's not recognised by HTML. This latter fact is most likely due to TBL fortuitously not being educated in the US or NA. Also, cutting down, on the number of, commas would greatly, improve, the readability, of Wiki, articles. As reference try visiting a major UK news site and see how English is supposed to be written: it's written to be read, not to be spoken. The comma is not a grammatically correct replacement for 'uh' or 'um'. —Preceding unsigned comment added by 62.1.24.107 (talk • contribs) 12:18, February 4, 2007

So web browsers compress white space. So what? Typing classes for decades taught double-space-after-full-stop. I don't think people's habits are going to change any time soon. ⇔ ChristTrekker 16:28, 10 November 2008 (UTC)

Tutorial stuff?

I'm removing this all. It gets bigger every time I look at the article. If we need specific comparisons to other shells then exaples might be okay, but not the manual we have now (which may as well be in yiddish as far as casual users are concerned). Chris Cunningham 12:12, 10 May 2007 (UTC)

I reverted your May 10th removal of most of the content from the bash page. Wikipedia shouldn't be dumbed down for the layman in all cases -- leave that for the intro. As a quick example: [Variations to the Standard Genetic Code]. Information about how bash handles & behaves with variables, whitespace, I/O redirection, etc is valid. Jeff Carr 15:59, 10 June 2007 (UTC)

This isn't a manual. It's not a case of "dumbing it down for the layman", it's a case of making it an interesting article, and technical guides do not make for interesting articles. The whole lot belongs on Wikibooks. Chris Cunningham 09:14, 12 June 2007 (UTC)

I fully agree that the details and examples in the integer math and string comparison sections are valid to be included in the article. I have promoted them from sub-secions under start up scripts to be main sections. Chris Cunningham - rather than the quick and easy edit to remove them all, why not take the time to summarize them, and add links to the appropriate articles with details. See test (Unix). --Unixguy 17:42, 11 June 2007 (UTC)

You're pointing to a transcoded man page as an example of a good article? That's the exact opposite of what we should be aiming for. Chris Cunningham 09:14, 12 June 2007 (UTC)

...Actually, having just gone and tried to "summarise" the stuff from the deleted sections that is actually useful to the article, I find that I already did take all the relevant bits and add them to the features section. So all that was deleted was the egrecious teach-yourself-unix shell scripting guide which specifically says it isn't bash-specific, and a couple of pages of example code. Not worth keeping. Chris Cunningham 09:48, 12 June 2007 (UTC)

Ok, after looking at the examples you removed more closely, it does appear that there is more detail than is needed for this article. I went ahead and placed the removed sections here on the talk page for future reference. --Unixguy 23:08, 13 June 2007 (UTC)

disagree Here is my vote if people feel like voting to find consensus. I do think that for this subject matter, the removed sections are relevant. Jeff Carr 20:31, 25 September 2007 (UTC)

Removed sections

Following are the removed tutorial sections. --Unixguy 23:03, 13 June 2007 (UTC)

I've moved these to Bash syntax and semantics as the content was handled in a similar way for Python syntax and semantics. Jeff Carr 00:02, 24 October 2007 (UTC)

The BASH' lack of simplification

The Bourne Again Shell has, during its long lifetime, gained several improvements and thus new programs. This has had as a result that to perform a same specific task, the user is bothered with a amount of overlapping programs.

Aldough Linux' self-correcting community might have resolved this earlier, as it is no longer actively used (now graphic interfaces are used instead) no corrections have been made for these flaws. Besides a large amount of overlapping programs, the command line interface has also a number of features which can be dismissed and replaced by other existing commands, hereby making a huge simplification possible.

Examples on this are:

• viewing of a text file: this can be done by an excessive amount of programs as vi, pico, less, more, ...
• the unnecessairy grep-command; instead locate with a specific option (thus locate -xx) can perform this function if locate is altered so it allows this

• The unnecessairy possibility of using relative pathnames, this can be replaced by only allowing absolute pathnames
• The unnecessairy pwd-command; instead the current directory can just be shown in the command line itself (similar as in DOS).
• The unnecessairy append I/O redirection and piping option; instead of using append (>>) one can simply use overwrite (>) instead
• The write permissions included with files should no longer include type-information (only gives extremely limited information and would be better checked with the filename-extension. Also, support for a sticky bit (-t permission) should be dropped. Thus instead of presenting eg drwxrw-rw- this would become rwxrw-rw-
• The possible use of general points in folders (not being part of the extension) should be dropped. Thus folders named foo.bar etc can no longer be created. This has caused allot of confusion in the past.
• Finally, commands as ls for listing folders, ... are best changed to list. Changing the commands to these makes it easier to remember them.

More suggestions may be found at My Blog's Linux Improvements-doc Hoping this article-segment will qualify for wikipedia, I have already implemented it into the BASH-article.

--KVDP 14:52, 9 September 2007 (UTC)--

Elimination of relative paths? grep unnecessary, just rewrite locate? pwd unnecessary? Remove append in favor of overwrite? Is this a joke? You're teasing. 74.64.85.88 16:11, 9 September 2007 (UTC)

Silly KVDP! Choice is what makes GNU/Linux so great. Following your train of thought I would guess that you think all cars should be the same color because there is no "need" for choice. I'll just stop there because I do not want to feed the troll any more. Donkdonk (talk) 20:42, 15 April 2008 (UTC)

Citations

The following papers

• http://tiswww.case.edu/php/chet/bash/rose94.pdf
• http://tiswww.case.edu/php/chet/bash/article.pdf

Contain a number of citations that could be added to this article. --BrianFennell (talk) 22:13, 28 May 2008 (UTC)

Pronunciation

Is anyone up for a IPA-pronunciation code? There is some controversy about how the name is pronounced. An IPA clarification would be in place, and would increase the quality of the article. 89.8.51.17 (talk) 16:40, 1 October 2008 (UTC)

Where exactly is this controversy? Chris Cunningham (not at work) - talk 17:03, 1 October 2008 (UTC)

"|hello | you| |this is a good news| do not you think so|"

history of bash development

From a historical point of view, it would be interesting to note what features were new in bash 2, and what is new in bash 3. Surely there are people running with older versions (I had a box still using bash 1 until a few weeks ago, now up to 2.02), so this would be good to know. Bill.albing mentioned this almost 2 years ago, but I don't see anything yet. ⇔ ChristTrekker 16:24, 10 November 2008 (UTC)

Regarding blocked bash address

Hi,

I have recently been trying to add a website to the external links section on the 'Bash' page, but this had been deleted a number of times.

Having read the reason, I feel that it should qualify to be added to the page. The website was not added solely for adversitement purposes. The function of the website is to provide reviews of Bash learning resources, and therefore offer users a guideline to go by when attempting to learn Bash Scripting. It is part of a final year undergraduate year, however it will be maintained as the function is solely to aid the learning of others in the area of Bash Scripting.

Regards,

Mustafa —Preceding unsigned comment added by 78.105.87.154 (talk) 16:29, 5 May 2010 (UTC)

"Unix shell"

I find it mildly offending. Perhaps "Not Unix Shell" rather! 85.77.179.98 (talk) 20:17, 18 May 2010 (UTC)

• I'm pretty sure BASh was designed for Unix not GNU. It just happens to work on GNU/Linux and other Unix based OSs. P4lm0r3 (talk) 18:12, 11 August 2010 (UTC)
• Well, then why article starts with:"written by Brian Fox for the GNU Project"? I would also vote for the "Unix like" or "GNU Shell". Also "Unix based" is not really correct as Linux is similar to Unix, but not based on the Unix code. "Unix like" seems to be more precise and widely accepted term for those systems (Linux distros, etc..) Igor Klimeš (talk) 09:41, 2 August 2012 (UTC)

Here on Wikipedia, we have a consensus definition of a Unix shell as "a command-line interpreter or shell that provides a traditional user interface for the Unix operating system and for Unix-like systems." Msnicki (talk) 13:50, 2 August 2012 (UTC)

Grammar

• Programming on Bash may mean mechanics, which doesn't fit to sensefull txt. ((Oxymerons)) of a unix supervsion are instable.

Doubleblind or -bind is another lack in commands of this disappearence. N _recall sense!--Raskollnika (talk) 09:13, 6 September 2010 (UTC)

What#s up?

• with the mixture of bash and NLP in leading companies?--88.77.149.237 (talk) 14:25, 18 October 2010 (UTC)

External links

It seems to me the list of external links is pretty indiscriminate and far too long. I don't feel that I'm enough of an expert on bash to cull through the list but I'm hoping someone who is might be able to take a cut. When even I could spot that the bash ref manual was missing from a list this long, something's not right. What can be done to improve the quality? Msnicki (talk) 16:11, 27 October 2010 (UTC)

Keyboard shortcuts

I would like to move this section to the Readline article. In the context of an article about bash, this seems like "how to" minutiae. If this material is sufficiently notable to appear anywhere, I think it makes more sense in readline, which actually implements this functionality. Comments, please? Msnicki (talk) 16:46, 17 November 2010 (UTC)

I just removed this section but Graeme Bartlett reverted for a reason that I don't understand. How is listing the commands that a user must type to move the cursor not how-to information? How does this an attempt to explain to the reader what Bash is and why it's significant, which is what an encyclopedia is supposed to do? QVVERTYVS (hm?) 23:32, 19 November 2015 (UTC)

This is what I've been trying to tell you in the Hamilton C shell discussion: You're entitled to your opinion about what constitutes too much how-to and too much detail. But I just don't think your views are as widely shared as you think they are. Msnicki (talk) 00:21, 20 November 2015 (UTC)

I think we can have plenty of detail. However the style of this section needs to be changed. It should not be addressing "you", and it should not explain how to do things. But the detail of what the buttons are is encyclopedic information. Graeme Bartlett (talk) 12:35, 20 November 2015 (UTC)

As long as other WP authors remove detailed information for other articles, I believe this section should be deleted in the bash article. Schily (talk) 14:41, 20 November 2015 (UTC)

I cross-posted this discussion to Wikipedia Talk:WikiProject Computing#Are listings of keyboard shortcuts encyclopedic information?, but I forgot to post the link here and to request discussion take place here. In any case, Codename Lisa appears to share my opinion. QVVERTYVS (hm?) 15:13, 20 November 2015 (UTC)

I've decided to WP:BEBOLD and do what I proposed 5 years and which has never received an objection. I've moved this list of key combinations from this article [2] to the Readline article [3] where I think it becomes less "how to" and more "what does it do" content. I'm hoping everyone can live with that. Msnicki (talk) 17:58, 20 November 2015 (UTC)

Hi. The move is definitely a plus. They make more sense there. But still, I understand that when there is very little to say about the subject of the article, lists like this are convenient as sheer mass instead of useful information, especially for articles that have no hopes of every becoming a Class C article, let alone GA or FA. One telltale sign is that they are sorted alphabetically, instead of classified and meaningfully presented.

Best regards,

Codename Lisa (talk) 03:25, 21 November 2015 (UTC)

Good. Glad you thought it was helpful, Codename Lisa. Now, perhaps you might take a look at what Qwertyus has been doing here [4], playing games like removing good sources (from Cygwin), leaving only the Usenet sources and then tagging what's left with a complaint that he wants better sources, and deceptively summarizing a source to make it appear it's critical of the product when in fact they describe it as "excellent". I think it's just a big "I don't like it because it's not open source" agenda and I've complained at Talk:Hamilton C shell#Discussion requested. Msnicki (talk) 08:29, 21 November 2015 (UTC)

No, no, no, no, my dear friend. Had you asked me to participate in another discussion, I might have. But what you wrote here is personal comment that sail very close to attack. It is not even related to this discussion. Come now, I've known both of you for sometimes and know that both of you mean well. Assume a little more good faith in one another.

Now, bearing in mind the we are here to build an encyclopedia, don't forget that what you did above was simply moving building material closer to the building site. If the material remain unused for a long time, they become street clutter.

Best regards,

Codename Lisa (talk) 15:00, 21 November 2015 (UTC)

Versioning

Others might have found the extensive versioning information elsewhere as I have at the official GNU Bash website and thought that perhaps a synopsis might work well in this article. Linux kernel documentation mentions having some level of a solution prepared before suggesting a fix or feature and that same canon might apply here as well to detirmine the details listed in such a synopsis and that these details should be brought together from the knowlege of multiply contributors each with some experience with the Bash version(s) being commented on.

condor (talk) 20:33, 28 December 2010 (UTC)

As a pun

The explanation citing a relgious basis for the name lacks a credible source. Rather than wait for someone to find one I've removed the sentence because allowing it to stay in the absence of a credible citation is inflammatory.

These reasons aside. I've got an opinion of my own, which is this: There is humor to it because it is a play on words, i.e. there is similarity in spelling between "Born" and "Bourne", the latter being the shell it was named after. In addition, there is no resemblance to being birthed, in any sense of the word.

Finally, humor is subjective. I'm unable to find a reason to remove the clause saying that the name is a pun because I also see humor in it. My opinion about what it is funny explains the basis for my opinion using a reference to a classical type of humor. But I'm not sure the explanation belongs in the article -- because humor is subjective. NPOV implies a lack of subjectivity.

Kernel.package (talk) 03:50, 25 February 2011 (UTC)

This should not need a citation, it's simply a statement of the obvious to English speakers who are aware of that popular Christian phrase, which predates Bash. But I concede that a better statement of that obviousness might be useful, which I've tried to supply, along with a citation for the obvious. There's no evidence that this pun was intended to be funny or humorous (not all puns are), merely clever and expressive. Msnicki (talk) 03:05, 10 March 2011 (UTC)

GNU website as a source

Wikipedia policy seems pretty clear that we should exercise care in the use of information taken directly from any organization's website. From the business and commerce source guidelines, "Websites and publications of trading companies, organizations and charities are a marketing communication channel and should be treated with caution. These media can be used for primary data about the organization's view of itself and may have clear bias related to commercial interests. Effort should be made to corroborate the reference with an independent source in order to maintain a neutral point of view."

To be a really good encyclopedic article, we need to assemble it from secondary sources: It's not about what GNU says about their product, it's about what other reliable sources we can cite say about it. This is a lot harder job (I'm just learning!) but it's kind of fun. I hope this helps. Msnicki (talk) 22:04, 12 March 2011 (UTC)

Grandscribe has again inserted GNU's own description of Bash into the first line of the article. It positions Bash as whatever GNU says it is with obvious advertising copy about its "advanced features for both interactive use and shell programming." It's peacock language. Bash and the other important Unix shells are all about a quarter century old and all are very stable; how "advanced" can any of them be anymore? I've already reverted this stuff twice and I've explained why WP policy asks that we not simply quote from a primary source.

Because I've already used my 2 reverts, I won't do another. This needs discussion and others need to weigh in so we can find an actual consensus, please. Msnicki (talk) 22:14, 13 March 2011 (UTC)

Your interpretation of the guidelines does not apply in this case where we use the information supplied by the developer of a program such as Bash as a reference to write a definition about it. Wikipedia guidelines do not forbid the use of information supplied by the developer of a program about what the program does. Bash is a a program from the GNU project. The use of information about programs from the GNU project taken from the GNU website IS NOT in violation of any Wikipedia rules. So please stop using the guidelines to try to support your POV.--Grandscribe (talk) 22:18, 13 March 2011 (UTC)

Third Opinion

• We should not be copying phrasing verbatim like we have from [5]. This is a borderline copyright violation.
• We should avoid puffery. We don't let the people who make things "define" them for us, without attributing the description to them. In other words, we don't let them speak in "Wikipedia's voice".
• This isn't really a question of sourcing per-se. Primary sources are reliable enough for self-description, but we do not necessarily report what they say as factual, especially when it involves puffery.

Gigs (talk) 18:26, 15 March 2011 (UTC)

Based on this third opinion, I have undone the edit in question. Msnicki (talk) 19:18, 15 March 2011 (UTC)

User Msnicki please respect Wikipedia guidelines. My contribution is a valid one, using valid sources, in accordance with Wikpedia rules. You are not allowed to make edits based simply on the opinion of another editor. That is POV. Read WP:NPOV.--Grandscribe (talk) 20:14, 21 March 2011 (UTC)

When you and I failed to agree, I made a request for a Wikipedia:Third opinion. It's the process we're asked to follow to resolve disagreements like this one between just two editors. Msnicki (talk) 20:20, 21 March 2011 (UTC)

My take on current disagreements

(Grandscribe pointed me to this.)

Here are some thoughts from skimming the history:

• "advanced features" is too subjective and complimentary
• Half the intro can't be given to the name - that sort of trivia can go in a history or background section
• It's a GNU project launched before "open source" existed. It was developed to propagate the four freedoms. Retroactively calling it an open source program is not encyclopaedic.
• "C commands built in" is too jargonish for the intro
• Bourne shell should be linked
• Third-party sources should be used in preference to citing the developer (I'm pretty sure this is in the Wikipedia rules), except when the purpose of the citation is to show that the developer says, or that the GNU project says something.
• Sentences and wordings shouldn't be copied from other webpages (unless they're in quotation marks). gnu.org publishes what GNU wants to say about Bash. Wikipedia is writing an encyclopaedia entry, which is different.
• Bash isn't a clone. It started as a clone but that hasn't been the focus for the past two decades. gnu.org says "most"[6] sh scripts will work in Bash, so it's not even completely compatible.
• The rebirth of "born again" isn't necessarily "spiritual", and this article probably isn't the place to explain what "rebirth" is. The link to born again does that.
• What's the pertinence of the "bashing together" comment? (it's in the intro, with this reference: [7]) Is the author of that comment somehow important? If I find someone making an off-hand comment on a mailing list about Bash being comparable to black ash, should that also be put in the intro?

I'll make some edits in the coming days. Most of the references that have been used don't have a "quote" field, so it's hard to know exactly what information they're backing up. That makes it hard for me and others to re-use those references. That's an exercise for whoever knows the content of the referenced pages - but it would be better for Wikipedia if the "quote" field was used. Gronky (talk) 23:24, 21 March 2011 (UTC)

The citations used in the first paragraph are all fairly short and all are on-line. But as suggested, I've added quotes to a number of them. The Bourne shell is linked in the second sentence. Bash may not be a clone now but that was its initial intent; Stallman called it an "imitation". People really did talk about Bash as bashing-together the features of sh, csh and ksh; the citation is intended as a contemporaneous example. Msnicki (talk) 00:52, 22 March 2011 (UTC)

I see you've just made a number of changes. I don't think they're better at all. There are no citations to support the wording (e.g., "feature-compatible", "Unix-like") you've chosen, unlike what we had before. I don't know why you would move the author's name out of the first sentence. I thought we had a consensus (as shown in the article title) that Bash is a Unix shell, not a "Unix-like" shell. The citations don't match the claim that "Brian Fox to develop Bash from 1988 to 1993." You've dropped the reference to bashing together, which I think had a valid citation. You've changed the wording from "begin coding" to "began developing" but the citation (which is just the code) doesn't support that; he could have done some work before starting the coding.

I would like to revert this edit but first, I would like to hear comments from others. Msnicki (talk) 03:39, 22 March 2011 (UTC)

I agree, the latest changes make the lead para worse and are not properly supported by the refs. The previous version was better. - Ahunt (talk) 12:30, 22 March 2011 (UTC)

Based on Ahunt's agreement with my concerns, I have undone Gronky's edit.

I suggest the article definitely needs improvement but that the problem isn't the first paragraph. The problem is that the rest of the article simply isn't done. The history section would benefit from an additional paragraph or more discussing how Bash evolved through later releases. And the features section is completely random. It lists key bindings even those are part of Readline, not Bash, but doesn't even list Bash's basic control structures or other facilities. (Compare the content here to that of C shell article.)

I think we can make this article much better, but probably not by just quibbling over the first paragraph. Msnicki (talk) 14:14, 22 March 2011 (UTC)

• I wrote "Unix-like" because Bash was not written for Unix, it was written for GNU. How can it be a "Unix shell"?
• Why the sensitivity about having the name of one of the authors in the 2nd or 3rd sentence instead of the first? How (and where) was it decided that Chet Ramey didn't deserve a first-sentence mention? His name is already in the infobox and the history section, having it in the intro at all seems strange.
• The "bashing together" citation only proved that someone once used this set of words. There's nothing to suggest that this was the reason for the name or the philosophy of the program's development.
• "coding" is programmer slang.

Gronky (talk) 14:19, 22 March 2011 (UTC)

Bash is a Unix shell by consensus that "A Unix shell is a command-line interpreter or shell that provides a traditional user interface for the Unix operating system and for Unix-like systems." Brian Fox is not merely "one of the authors," he is the one and only original author. Chet Ramey has been the maintainer but he is not the author. (Please see the discussion at WP:Articles for deletion/Chet Ramey.) The bashing together remark was commonly heard in conversations contemporaneous to the release of Bash, reflecting the obviousness of that word association to English speakers. (I know that from being in some of those conversations at the time but of course personal knowledge isn't useful for a citation.) The citation simply establishes that the phrase was used and when that happened. Msnicki (talk) 14:46, 22 March 2011 (UTC)

Btw, I do agree with your point (and your edit) that the better term is free software, not open source. Msnicki (talk)

It is good to see that Gronky has been helping a lot to improve the definition for Bash. It is little better now.But it still needs to be further improved. Too many lines of the inrodutcion are spent explained the acronym and not what Bash really is and what it does. --Grandscribe (talk) 08:15, 23 March 2011 (UTC)

Could you start a second paragraph in the intro or do something to flesh out the features section? Msnicki (talk) 14:45, 23 March 2011 (UTC)

gnu shell in 1986?

Richard Stallman says in this 1986 speech:[8]

A shell I believe has already been written. It has two modes, one imitating the BOURNE shell, and one imitating the C-shell in the same program. I have not received a copy of it yet, and I don't know how much work I'll have to do on it.

More info sought. Gronky (talk) 20:37, 22 March 2011 (UTC)

That sounds like a reference to the same prior developer Stallman was referring to in his 1988 comment, "For a year and a half, the GNU shell was "just about done". The author made repeated promises to deliver what he had done, and never kept them." I have not been able to find any reference to say who that individual might have been. Msnicki (talk) 20:53, 22 March 2011 (UTC)

Ok. Looks like a dead end. Gronky (talk) 21:11, 22 March 2011 (UTC)

LOL. I hope not. I'd like to know what happened, wouldn't you? I think there's a cool story there if someone can find a citation somewhere. Msnicki (talk) 21:18, 22 March 2011 (UTC)

Authorship

When Microsoft or Apple publish some software, they're the author, and the Wikipedia article says so. For Bash, the equivalent author is FSF.

Bash didn't come into being thanks to Brian Fox. If Fox was busy, FSF would have hired someone else. Further, for Bash's 22 years, FSF has been the publisher.

For the question of "who's fingers tapped the keys?", it seems Chet Ramey did as much as Fox. More by some measurements. This is evidenced here: Wikipedia:Articles_for_deletion/Chet_Ramey. That discussion concludes that Ramey wrote more than Fox, and that Ramey isn't notable enough to get a Wikipedia article. That suggests that the Fox article should maybe be proposed for deletion (but my vote would be "keep" - I'm no deletionist).

From the above-linked Afd on Chet Ramey, there are two important-ish points:

• Bash 4.1, for example, contains an AUTHORS file. It lists Fox 214 times, and Ramey 400 times.
• The program size has grown by a factor of 20 (referring to Fox's Bash compared to today's (i.e. Ramey's) Bash

Those are testable/provable arguments for giving Ramey more credit than Fox (for fingers-at-keyboard). What's the argument for giving Fox as much credit as Ramey?

It seems to me that Ramey may have done more, but I'd give them equal credit, for the sake of simplicity. And FSF should be credited. Gronky (talk) 22:37, 22 March 2011 (UTC)

Oh, my, Gronky. Do we have to go there again? I think this got decided at WP:Articles for deletion/Chet Ramey: A maintainer is not the same as an author. Authors of Microsoft and Apple software are reported when known, e.g., HPFS by Gordon Letwin or QuickDraw by Bill Atkinson and Andy Hertzfeld. The GNU Project gets credit in the first sentence along with the author. How much clearer can this attribution get? Msnicki (talk) 22:43, 22 March 2011 (UTC)

Go where again? I just got here. Where was it decided?

If Fox authored A, and Ramey authored B, and Bash is A+B, why should Ramey not get any credit? If Ramey did nothing substantial, then he shouldn't be mentioned, but no one's suggested that. On the contrary, the only verifiable comments on this have been to say that Ramey did more than Fox. Maybe those comments are wrong, but "let's not discuss this" doesn't prove support either argument. In any case, this issue isn't terribly important to me. If anyone's hell bent on keeping Fox's name high up in this article, I won't discuss it for long. But I would like to note that, from reviewing the previous discussions, it seems the data says that Ramey is more the author of today's Bash than Fox is. Gronky (talk) 22:53, 22 March 2011 (UTC)

Then you missed the part where Chet Ramey became a redlink because it was decided he was a maintainer, not an author, and didn't clear the bar for notability. Msnicki (talk) 23:09, 22 March 2011 (UTC)

No one there said that his role regarding Bash was insufficient. (But this isn't important to me.) Gronky (talk) 23:23, 22 March 2011 (UTC)

(Note to readers: Msnicki has expanded his 22:53, 22 March comment, so I'm now replying to the new version of his above comment)

I don't care about Fox v. Ramey as much as you, but I will point out that the Afd you link to doesn't contain the decision you claim.

As for FSF, ok, I take your point about some MS and Apple software having individual authors. There is still a distinction worth making: lots of software was developed for GNU, but Bash is special in that it was important enough that *FSF* raised funds and paid someone to write it. Gronky (talk) 23:06, 22 March 2011 (UTC)

Of course I think it's important that FSF paid for it. That's why I made this edit. Msnicki (talk) 23:57, 22 March 2011 (UTC)

"clone" isn't quite accurate

I've nothing against the word "clone", it's neither positive nor negative. But FSF didn't set out to just "clone" Unix. Being Unix-compatible was very important (but not crucial - incompatibilities were accepted), but the GNU project's goal was always to produce software that users would like. This was in the initial announcement of GNU:[9]

GNU will be able to run Unix programs, but will not be identical to Unix. We will make all improvements that are convenient,

There are many more if anyone doubts this.

So, GNU programs are not really "clones". Wine aims to "clone" the Windows API, as they say, their aim is "bug-for-bug compatibility". There are many descriptions that are more accurate; one is "an extended replacement for the Bourne Shell", in Sam Williams' Free as in Freedom 2.0. Gronky (talk) 22:47, 22 March 2011 (UTC)

This is back to the question of what Wikipedia should say about Bash. We can't let GNU speak in Wikipedia's voice, as was pointed out earlier. We need consensus about how we describe things and the terms we use. Clone has a consensus definition, "In computing, a clone is a hardware or software system that is designed to mimic another system", that seemed appropriate. I'm open to suggestions but so far, I haven't heard one that sounds better. Msnicki (talk) 23:01, 22 March 2011 (UTC)

Consensus? Where's that?

None of the refs say that Bash is a clone.

I've given a third-party ref calling it "an extended replacement" (Sam Williams has no affiliation to FSF), and a GNU ref saying that writing clones isn't their goal. Gronky (talk) 23:18, 22 March 2011 (UTC)

The consensus about the word clone is whatever it says on that page. If I thought it was wrong, I would argue it there. The word extended is Wikipuffery. Replacement is neutral and could be used but it doesn't seem better. The WP clone article goes on to describe the compatibility issue that clones, including Bash, typically have to address but which true replacements (e.g., cars for horses) may not have to. Clone is a better match for Stallman's description of Bash as an imitation (which might be another alternative, but still not as good.) Msnicki (talk) 23:27, 22 March 2011 (UTC)

The Clone (computing) article has, after 7 years, fewer than 50 edits and not a single reference. It needs fixing, but I don't have time. It doesn't even give an in any way clear definition of what it's talking about.

"extended" is accurate. That's what Bash is to the Bourne shell. Or as you'd say, "extra things have been bashed onto it" :-)

I agree that "replacement" isn't optimal, but, since you've set the tone of this cooperation to belt-and-braces-else-Msnicki-reverts-you (1, 2, 3, 4, 5, 6, 7, 8, 9), I think sticking to a wording which has references is the only solution. Gronky (talk) 00:15, 23 March 2011 (UTC)

What we should do is request opinions from others. This is a consensus project. No one owns anything. I think clone is better than anything else I've heard but if you can convince a simple majority of whoever cares to weigh in on this that there's something better, I'm totally okay with that. That's how it works.

Comments, please? Who prefers clone and who prefers extended replacement (or something else)? Msnicki (talk) 00:24, 23 March 2011 (UTC)

In reviewing this I agree that "extended replacement" is too close to peacock language or marketing jargon and our job here at Wikipedia is to write an encyclopedia, not present anyone's marketing campaign. I also think that "clone" is too loaded a term. I would suggest the sentence be more neutral and just read "referring to its initial conception as a free software replacement for the Bourne shell (sh)". - Ahunt (talk) 01:00, 23 March 2011 (UTC)

Okay, I'm already outvoted. I'll make the change. Thanks for the discussion. Msnicki (talk) 01:10, 23 March 2011 (UTC)

A proposal for some new paragraphs

Conceding my own (at times) unhelpful contributions, we seem to fighting over details of what's there already rather than cooperating to tell more of the story.

I propose (purely in the spirit of brainstorming) that it would be useful to start two new paragraphs.

• A second intro paragraph, something like "Bash is typically used as a command line interpreter running in a text window but is also popular for scripting. It has been widely distributed with versions available for <list of systems>. It is the default shell on <list of systems>. As a replacement for sh, it provides support for all the facilities of sh except <whatever>. In addition, it supports <list of features> borrowed from csh, <list of features> from ksh and its own unique features, including <whatever>. Today, ..."

• A second history paragraph, maybe something like "Since it's initial 0.99 beta release by Fox, the community of developers who've contributed to Bash has grown to over <number> individuals in <number> countries. In release xxx in 19xx, <list of features> were added. In release xxx ... Today, ..."

Thoughts? What new facts would be most interesting to add next? Would anyone like to try his hand at getting us started? Msnicki (talk) 16:52, 25 March 2011 (UTC)

That looks like a good idea. Both those would be useful to the article, provided the "Xs" can be filled in and referenced! - Ahunt (talk) 17:02, 25 March 2011 (UTC)

How about if we move the first Features paragraph to the intro and then work to make it better? It's rambling and lacks any citations but it's a start. Msnicki (talk) 16:07, 26 March 2011 (UTC)

We should be careful to keep jargon out of the intro, as much as possible, and for "default shell", it might be better to say "default login shell", or something else since /bin/bash is almost always the shell that users get by default when opening a command line, but some systems such as Debian have made /bin/sh a symlink to a less feature-rich shell with a faster start-up time (Dash, IIRC). Was compatibility with ksh and csh ever claimed, or was Bash's philosophy a "best of breeds" one? If the latter, it might be best to explain Bash's broad feature set in terms of providing all useful things / all things users want rather than specifically providing ksh or csh features. Gronky (talk) 13:47, 28 March 2011 (UTC)

• I've just moved the first paragraph of the Features section up to the intro. If you know how to improve it, please be bold. Msnicki (talk) 16:36, 14 April 2011 (UTC)

intro still wrong about name

• We are having difficulty reaching consensus on the first paragraph. Msnicki (talk) 15:27, 28 March 2011 (UTC)

1. The intro erroneously says the name refers to Bash being free software.
2. It's also wrong to say the name is a description. The comment about "bashing things together" is just a remark by someone after the name was chosen. I think it's irrelevant, but that's another issue. The issue here is that it's wrong to say that this is what the name is.
3. It also seems wrong to say that Bash is a pun and an acronym - more accurately, it's an acronym for a pun. ("Bash" isn't a pun. "Bourn again shell" is a pun.)

I'll try to fix these problems. There's also still no mention in the intro of the author, FSF. Gronky (talk) 14:01, 28 March 2011 (UTC)

Done. Gronky (talk) 14:39, 28 March 2011 (UTC)

Gronky, you must know this was a contentious edit. I don't think this is better and I don't agree with your reasoning. Once again, can we get some other opinions, please? Msnicki (talk) 15:10, 28 March 2011 (UTC)

I have reverted those additions for now. User:Gronky, making a proposal, asking for opinions to gain a consensus and then making the edits anyway is not a good-faith way to proceed. You need to make your proposal and then wait at least a few days to gain consensus. If your proposals are good ones then there is no need to rush the process. In this case I don't think your changes are an improvement and the previous text was more balanced and neutral. - Ahunt (talk) 15:30, 28 March 2011 (UTC)

@Msnicki: (What's a "consensus edit"? One that requires consensus before making the edit?) I didn't expect anyone to be sensitive about these changes. They seems pretty clear when you look at it. There were factual errors, I fixed them.

@Ahunt: The current intro is factually wrong. It says that "Bash" means that the software is free software. That's nonsense (partly or wholly of my making). It also says that "Bash" is a pun, which is flat wrong. And it says that "Bash" is a description of the development philosophy, which again is completely unfounded.

I await someone proposing an alternative way to fix these three problems. Gronky (talk) 22:25, 28 March 2011 (UTC)

If you don't think Bash is free software, why did you make this edit? Msnicki (talk) 22:44, 28 March 2011 (UTC)

Of course it's free software. I've always said so. The error is in the claim that "Bourn-again shell" refers to it being free software. That's false. The name refers to Bourn shell, and "born again". There's no free software reference within the name. Gronky (talk) 22:50, 28 March 2011 (UTC)

• Re: bashing together, the term bash was much more popular through the 70s and 80s as a term for a Bash#A party or gala event (where people or music or whatever mixed.) Young adults then certainly knew the term because it was in common usage. I don't think it is today. (I haven't heard anyone tell me they went to a bash in at least 20 years.) Would citations that establish that fact possibly resolve this? Msnicki (talk) 18:13, 28 March 2011 (UTC)

You've replied by saying that "bashing" can be used grammatically as a verb, but that was never in question. The error in the current intro is the claim that the name of this software is a description of it's development philosophy. If you have a citation which shows the software's name-giver as confirming this, then the claim could stay. Otherwise, it's flat wrong. You seem intent in keeping some form of "bashing" sentence in the intro. I think that's a bad idea, but I give up. "Bashing" can stay. Factual inaccuracies (i.e. the claim that the software's name refers to the developers bashing features together) can't. Gronky (talk) 22:28, 28 March 2011 (UTC)

On each issue:

1. Agree.

2. Agree. But think the post-remark is relevant.

3. Semi-agree. This is true, but a technicality.

Niluop (talk) 04:24, 17 April 2011 (UTC)

• Comments from non-involved user: First, when requesting comments you should try to keep the requests short and concise and not have a lengthy discussion as in the thread above and the sections below. I have not read these parts, so I will only comment based on the three issues listed above. I believe all points are irrelevant for the introduction and should be moved to a separate section. Then a simple rewrite should be able to solve the issue. Instead of saying that "the name is" you can use a weaker "the name has been described as a" (or something similar). Labongo (talk) 19:03, 18 April 2011 (UTC)

• What would you think about cleaning up the second paragraph and moving it up to immediately after the opening sentence, "Bash is a Unix shell written by Brian Fox for the GNU Project.", making the remainder about the name the second paragraph? You can't just move the second paragraph as-is because it's an unsourced jumble. But if someone would be willing to clean it up (see my comments above), I would be supportive. Msnicki (talk) 19:17, 18 April 2011 (UTC)

• I believe the suggested changes would make the intro better. The origin of the name description is in my opinion not important enough to be mentioned in the introduction, but can be in either the history section or in a separate section. Labongo (talk) 21:24, 26 April 2011 (UTC)

FWIW, here's the text I proposed

Nobody has commented on the substance of the changes I made. Does anyone have any problems with the edit itself? Here's the text:

Bash is a Unix shell written for the GNU Project by Brian Fox while working at FSF. The name is an acronym for Bourne-again shell, which is a pun referring both to its initial goals of being a mostly-compatible replacement for Bourne shell (sh) and being born again, a term for spiritual rebirth. The name can also be said to be descriptive of what it did, bashing together the features of other Unix shells, including csh and ksh. Bash is free software, distributed under the terms of the GNU GPL.

. Gronky (talk) 22:53, 28 March 2011 (UTC)

• What do you mean, "no one has commented"? I told you it wasn't better, and why, and so did Ahunt, who then reverted it. If that wasn't sufficient, what does one have to do to register disagreement? Msnicki (talk) 22:58, 28 March 2011 (UTC)

I said "Nobody has commented on the substance of the changes I made." My change was immediately reverted but nobody has said a word about why. Does anyone disagree that the three factual errors exist? What's wrong with my fix? If my fix isn't used, how do others propose we fix these errors? Gronky (talk) 23:07, 28 March 2011 (UTC)

• Yes, I disagree that these three claimed factual errors exist. That was the whole point of the citations with each statement as it now stands, to establish the facts. What's wrong with your "fix" is a laundry list of problems, starting with the demotion of the author, the double-reporting of GNU and FSF (variants on the same thing, especially then) in the first sentence and wording that doesn't match the citations. Does this count as a comment? Msnicki (talk) 23:13, 28 March 2011 (UTC)

Thanks for commenting on the substance.

The author hasn't been demoted. He's mentioned in the very first sentence. (Which is a lot, give that the jury's still out on whether he's the mostly authorly contributor - but that's another thread.) The citations don't contradict anything I said about the intro having factual errors. GNU and FSF arent' the same thing. GNU has tens of thousands of developers. FSF had a dozen at it's highest. Gronky (talk) 23:19, 28 March 2011 (UTC)

Detailed explanation of how the intro is poorly written

The intro is misleading and weak because it is poorly written. My improvements have been reverted over and over, so I give up. Here are my explanations of the intro's problems. The current atmosphere of this collaboration indicates that these improvements will be ignored here, but I'll detail them anyway so that they might help someone else in the future, or might help the people who are currently reverting me to improve their writing in other articles.

1. The intro says "Bash is a pun", which is wrong. "Bourn-again shell" is a pun. This error is obvious.
2. The "Bash is a description" error is fairly obvious (to anyone who already knows the whole situation), but not so obvious to explain. The issue is that when the intro says "Bash is a pun" and "Bash is an acronym", the meaning of "is" is that this name was chosen because it conveys this pun and acronym. It's an existential "is" - we're talking about the reason for the name being "Bash" instead of something else. Tacking on that "Bash is a description", is misleading because, this time, it's shorthand for "someone once commented that", but the reader isn't told that this is shorthand. The only conclusions the reader can take are that, either, all three uses of "is" refer to "someone once commented that", in which case the first two are factually wrong, or that all three are existential "is", which means the name "Bash" was chosen because it's a description, which is factually wrong. So you see, there are two different forms of "is", and by mixing them together without informing the reader which is which, the intro is inevitably wrong, no matter which interpretation the reader gives to "is".
3. Last, the intro says that the name "Bash" refers to the shell being free software. Bash is free software, but the name contains no reference to this.

Apart from these writing errors, there is the problem that the author, FSF is omitted. The FSF hired very few programmers. Only for the most important tasks, for which no external non-paid contributor could be found. This would be worth mentioning for any organisation, and is even more noteworthy in this case.

And finally, there's the issue that Chet Ramey seems to have contributed at least as much, or more than, Brian Fox to Bash. This is what has been numerically, confirmably demonstrated in a previous Afd. However, keeping Brian Fox's name, and only Brian Fox's name, in the first line of this article seems to be Msnicki's most important goal. Getting the author attribution right isn't important enough to me for me to continue looking into this issue. Gronky (talk) 19:28, 29 March 2011 (UTC)

I'm not sure it's appropriate for the lede to focus so much on the name in the first place. The stuff about the name should be in there somewhere, but ideally the lede should summarize the rest of the article, not present unique information. It's harder on an article like this that isn't fleshed out as much, but that's the goal for a Good Article. Something to keep in mind. Gigs (talk) 03:12, 30 March 2011 (UTC)

What do you think of the proposal (above) for a second paragraph in the intro? Would you be willing to get us started? Msnicki (talk) 03:22, 30 March 2011 (UTC)

A month ago, I moved the features paragraph to the top and rewrote the into based on the discussion here, borrowing some material from the intro to the C shell article. To my surprise, no one has complained, so I'm hoping we've closed on this issue and have a roughly acceptable intro. Msnicki (talk) 14:56, 30 May 2011 (UTC)

Brace Expansion verbosity

I think that the Brace expansion section could be expanded a little more. The purpose being to demonstrate more commandline-fu:

ls *.{jp{,e}g,png}     # expands to *.jpg *.jpeg *.png - after which,
                       # the wildcards are processed

It may also be of note to expand on how quoting works in brace expansion:

ls a{*.txt,'*.png',\*.bmp}    # expands to a*.txt a*.png a*.bmp
                              # but a*.png and a*.bmp aren't processed as wildcards

Just my opinion. «ɧʒχχ (tOk•k«n'trIb)» 20:45, 6 August 2011 (UTC)

How about, oh I dunno, finding an example from a reference rather than trying to create our own? It's only Unix articles which seem to have this obsession with teaching content to readers using editor-invented examples. Chris Cunningham (user:thumperward) - talk 12:35, 15 August 2011 (UTC)

Early shells did not support here documents

The article currently says: "Like all Unix shells, it supports filename wildcarding, piping, here documents, command substitution, variables and control structures for condition-testing and iteration.".

I placed a {{dubious}} tag. The first shell I used did not support here documents. If I am not mistaken Steve Bourne's description of here documents, in the Bell Systems Technical Journal, described it as a new feature. If I am not mistaken some of the other features also weren't supported by the earliest shells. Geo Swan (talk) 16:38, 5 February 2012 (UTC)

How far back do you want to go? Very few people ever saw UNIX prior to 1978, when the famous BSTJ issue devoted to UNIX appeared and in that issue, Bourne makes clear that his shell did support here docs. I have that issue (in my hands) and while he describes the feature, he makes no indication of whether it was new. But it's possible you may be thinking of an unrelated change to the way stdin worked for scripts, which Bourne called procedures. It's in the same paragraph where Bourne first mentions here docs but it really is unrelated. "During the execution of a shell procedure, the standard input and output are left unchanged. (In earlier versions of the UNIX shell the text of the procedure itself was the standard input.)"

Bill Joy's C shell also had here docs; they're described in Joy's 1979 paper, "An Introduction to the C shell". John Mashey has told me privately (sorry, wish I could share) that Joy only had the Thompson shell to work from, so here docs may have been in that one, too (though I concede the feature is not mentioned in the archived man pages.) If you go far enough back, perhaps you could find a time when the very first shell first compiled and probably it did not have here docs. But so what? The point here is that we have a consensus understanding of what a Unix shell is and it's based on what we understand today, not pre-1978, and it includes this feature, which bash also supports. That's really all this is about. Msnicki (talk) 17:27, 5 February 2012 (UTC)

Non-interactive Case

https://en.wikipedia.org/wiki/Bash_%28Unix_shell%29#Startup_scripts describes interactive startup of the shell. The non-interactive case should also be discussed, although I'm not qualified to make even a cursory draft. Regards, PeterEasthope (talk) 01:34, 22 May 2013 (UTC)

Meaning of $

It would be worth expanding on the meaning of the "$" sign in Bash. It isn't like the "this-is-a-variable" prefix in PHP/Perl, rather it acts as a unary operator. $...x... means "Do something with x and return the value", where the common case $x merely returns the value of x, but the $ operator also has all sorts of abilities such as lower-case, substring-removal, arithmetic evaluation, default-value substitution etc. [i.e. it's wrong to think that "variables are written to without a $, but read from with a $"] — Preceding unsigned comment added by RichardNeill (talk • contribs) 14:26, 25 November 2013 (UTC)

Delete keyboard shortcuts

Someone has lavished loving detail on the "keyboard shortcuts" section. But the list is way too detailed for this kind of article. And the list is basically useless. I have used bash for MANY years. Only a few of those "shortcuts" are of any use, for example CTL-C, CTL-R, CTL-V, CTL-Z. Many of the "shortcuts" are downright laughable, for example CTL-T, many others. It would be a huge waste of time for a practical user to learn most of the list items, and few if any of those "shortcuts" would ever be used. At least the list fits with the tone of the rest of the article, which is poorly written. 71.212.48.92 (talk) 07:12, 22 January 2014 (UTC)

First release date

We need to use the date stamp from the usenet article and this date stamp is from June 8, 1989. Schily (talk) 17:51, 17 November 2015 (UTC)

Sorry for my revert. I misread the date. I have no idea how I did that. You are correct. Msnicki (talk) 17:54, 17 November 2015 (UTC)

Invitation to a possibly related discussion

Qwertyus has edited [10] the Hamilton C shellarticle, removing a fair amount of content, arguing that the WP:SPS sourcing, e.g., of what the author was thinking, was inappropriate. One of Qwertyus's objections is to the Usenet sources; especially in light of our recent discussion of the release date for Bash, I think Qwertysus is wrong, we do use Usenet sources when they're best available and not controversial as to their authenticity or what claims they are being used to support. The article survived a WP:DRV at Wikipedia:Deletion review/Log/2011 May 8#Hamilton C shell in substantially the previous form, drawing a consensus that it was not obviously promotional. No one at the time voiced criticism of the content. On that basis, I think the content was fine. But Qwertyus is correct that I have a WP:COI, declared at that deletion review and also on the article talk page, so I do need to ask for others' opinions and I must respect your consensus. I am too close to this. Msnicki (talk) 20:05, 17 November 2015 (UTC)

Shouldn't this article have an infobox programming language too?

I understand that Bash is both a computer program (as are all Unix shells) and a programming language and hence I was surprised to not see a programming language infobox in this article underneath the software infobox (which would make its formatting resemble that of the MATLAB article, for example). Hence I am creating this section to ask why, in case this is more than an oversight (like perhaps some consensus was reached earlier on in this page's history that I am unaware of, that related to this). If this is merely forgetfulness, or the result of no-one having the time or inclination to create one, I am willing to create one filled with some basic info about the language. Brenton (contribs · email · talk · uploads) 13:40, 30 December 2015 (UTC)

Hello, Brenton

{{Infobox programming language}} is a superset of {{Infobox software}}. I believe you can simply upgrade the article to use the former and its unique fields. I am not aware of a field present in {{Infobox software}} but not in {{Infobox programming language}} but do feel free to have a quick check.

That said, replace the infobox only if you do have material for it. There is no obligation to use all its fields. I can see some of the fields in the current infobox is badly populated (like |operating system= and |language=). So, I hope you understand my concern.

Best regards,

Codename Lisa (talk) 15:33, 30 December 2015 (UTC)

Bourne-again

I know this is not the focus of the article, but the term "born again", as alluded to in the intro, is neither a contemporary nor an American concept of Christianity. I would like to suggest the deletion of those two words. - BroVic (talk) 16:16, 30 August 2016 (UTC)

Our article on Born again appears to disagree with you. Msnicki (talk) 16:21, 30 August 2016 (UTC)

Oh, good. I will love to take a look.  :-). BroVic (talk) 18:15, 30 August 2016 (UTC)