Revision as of 22:14, 13 March 2011 editMsnicki (talk | contribs)Extended confirmed users, Pending changes reviewers, Rollbackers10,358 edits →GNU website as a source: Needs discussion!← Previous edit | Revision as of 22:18, 13 March 2011 edit undoGrandscribe (talk | contribs)Extended confirmed users1,272 edits →GNU website as a sourceNext edit → | ||
Line 295: | Line 295: | ||
: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. ] (]) 22:14, 13 March 2011 (UTC) | :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. ] (]) 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. Misplaced Pages 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 Misplaced Pages rules. So please stop using the guidelines to try to support your POV.--] (]) 22:18, 13 March 2011 (UTC) |
Revision as of 22:18, 13 March 2011
This is the talk page for discussing improvements to the Bash (Unix shell) article. This is not a forum for general discussion of the article's subject. |
|
Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
Archives: Index, 1, 2 |
Computing: Software B‑class Mid‑importance | |||||||||||||
|
Computing B‑class High‑importance | ||||||||||
|
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)
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 ] ; 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 —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- Misplaced Pages 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)
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
Cleanup Co-ordination | |
---|---|
This article has recently been tagged as requiring cleanup to meet Misplaced Pages's quality standards. The article may have been flagged as needing cleanup because it has been suggested that:
For a full list of possible problems see Misplaced Pages:Manual of Style. As part of the cleanup process, the automated bot PocKleanBot has generated this notice as a focus of cleanup efforts, and also contacted several contributing editors of the article to bring their attention to the problem. You should use this section to discuss possible resolution of the problem and achieve consensus for action. Only when there is a consensus that the article is now cleaned up should you then de-list it by deleting the cleanup tag from the article, this causes the article to drop off the monthly cleanup-needed list page. | |
Discussion |
- 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. - 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)
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)
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. Misplaced Pages shouldn't be dumbed down for the layman in all cases -- leave that for the intro. As a quick example: . 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
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)
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)
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
Misplaced Pages 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 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." This is inappropriate but 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. Misplaced Pages 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 Misplaced Pages rules. So please stop using the guidelines to try to support your POV.--Grandscribe (talk) 22:18, 13 March 2011 (UTC)