Yesh!
Bish, Bash... gosh! Good ol' Bourne Again Shell takes a bow as it reaches version five-point-zero
In news that will set the hearts of shell fans all a quiver, Bash 5.0 was released this week, replete with a truckload of fixes along with a few new features. The fifth major version in the nearly 30-year history of the GNU Project’s Bourne Again Shell (Bash – geddit?) includes some new variables BASH_ARGV0, which returns $0 …
COMMENTS
-
-
-
Wednesday 9th January 2019 10:31 GMT Anonymous Coward
Re: "Trusty command interpreter"?
I don't know if bash is secure or not: I assume, given how big it is, not. What I'm much more sure about is that shell scripts (bash or otherwise) of any complexity almost never are. And I recently discovered bash's programmable-completion stuff, which can involve a hundred or so shell scripts (actually functions, which are worse because they are less isolated from each other) being run every time you type tab. Some of these functions can do things like run python and ask it for the list of module names. I'd guess the chance of this system not being just infested with security holes is essentially zero. It's just horrifying.
-
-
Wednesday 9th January 2019 14:54 GMT Teiwaz
Re: "Trusty command interpreter"?
Debian-like distros usually ship with dash, not bash as the default shell, and its executable is literally a tenth of the size.
Good point, having switched from Ubuntu a while back, I'd forgotten that - Ubuntu has followed suit (being a Debian based distro) since 6.10.
I assume in testing on Ubuntu that was taken into account?
-
Wednesday 9th January 2019 15:52 GMT thames
Re: "Trusty command interpreter"?
Ubuntu works the same as Debian, as Ubuntu is a close derivative of Debian. There are two shells, the interactive shell and the non-interactive shell. If you simply open a terminal to type commands in you get the interactive shell, which is Bash. If you run a script with #!/bin/sh, then you get Dash. If you want your script to run with Bash, then you need to specify #!/bin/bash.
Bash has features which make it easier to use interactively as well as more advanced syntax with which to write complex scripts. On the other hand, since Dash lacks those features the executable is smaller and so it starts up faster, which is useful if you are running lots of small simple scripts (like in the pre-Systemd init system when this combo originated).
The main thing you have to look out for is when you specify #!/bin/sh in a script but then try to use advanced Bash features and get very unhelpful Dash error messages. This is not that uncommon if you google for scripting examples since so many people just assume that everyone uses Bash. If you are using a Debian derivative and get baffling syntax error messages in a third party script, it's worth a try to change the #! to specify Bash to see if that helps.
Generally, I prefer working in Bash because the more user friendly syntax for advanced features means that I am less likely to make errors which have to be debugged. For really basic scripts however it doesn't make much difference.
-
-
-
-
-
-
-
Wednesday 9th January 2019 20:53 GMT CRConrad
Re: “...discussing how much better than Windows it is”
Actually, I don't think that had anything at all to do with Microsoft. It was just a simple pun on “second” being a unit of time — or, if not, then when the first service fails you switch over to the second one. So, if anyone here is seeing Windows behind every bush, that would seem to be you.
-
-
Wednesday 9th January 2019 10:41 GMT Anonymous Coward
Re: "with the latter having microsecond granularity."
A world in which knowing the time accurately is a security problem is a world which is fucked in more ways than I can count. A world in which the fix for that problem is not to allow high-resolution timers is a world which is fucked in more ways than it is possible for anyone to count.
How the fuck did we get here? What terrible sin did we commit as children that this awful crapness must be visited on us by some angry god? Can't we just burn it all down and start again? Please?
-
-
-
Wednesday 9th January 2019 12:04 GMT Peter Gathercole
Re: Bourne Again Shell (Bash – geddit?)
Probably the case that Bash was not the successor to the Bourne Shell, but to ksh, the Korn Shell, but the naming sort of still fits.
I think it would be an interesting exercise for many of the commenters here to actually try to use the original Bourne Shell as their main shell for a period of time, so that they could appreciate how much a step up ksh, the Posix Shell and bash actually are.
And for those who have hair-shirt tendencies, the Bell Labs. UNIX version/edition 6 shell (if you can format it - it appears it's not compatible with the groff version of the man macros installed on this Redhat system) is a real eye-opener!
-
Wednesday 9th January 2019 12:21 GMT Anonymous Coward
Re: Bourne Again Shell (Bash – geddit?)
I don't think bash was really the successor to ksh in any useful sense. Some people probably had ksh, although I'm not sure who they were: it didn't ship with BSD distributions, or not any of the ones I used.
Instead we had sh, csh and various derivatives of csh like tcsh. sh was too minimal to use interactively, csh was OK interactively and tcsh was quite nice. But both csh and tcsh were just horrors to write scripts in compared to sh. So bash came along having all the interactive niceness of tcsh and some more, while clearly being a Bourne-family shell.
-
Wednesday 9th January 2019 14:24 GMT juice
Re: Bourne Again Shell (Bash – geddit?)
Back in a past life, i used to extensively use ksh on SGI and Sun kit, mostly because you could enable vi commands (i.e. ksh -o vi). Which in turn meant that you could search and repeat/edit past commands with ease.
(It's also worth bearing in mind that these were the days when keyboard translations between systems could often be flaky - telnetting to a server and pressing left or right on a standard PC would often produce some on-screen garbage such as ~#^04c-. Using ksh meant that I didn't have to go digging around to figure out how to fix this for each of the servers I used to bounce around...)
These days everything I work on runs linux, and the built-in bash facitilies (crtl-r to search, ctrl-left and ctrl-right to jump back and forward by a "word") are good enough that I don't really need anything more advanced.
-
Friday 11th January 2019 13:59 GMT Peter Gathercole
Re: Bourne Again Shell (Bash – geddit?) @tfb
I was using SVR2 when I first came across ksh (ksh85, I think it was) in 1987. It was available as an exptool for AT&T related companies.
ksh88 became accepted as part of R&D Unix for AT&T companies (and I think it was purchasable commercially for 3B2 systems), and shipped as a standard shell in SVR4 in 1989 (and thus available in SunOS 4). I think it made it's way into a lot of AT&T licensed and derived UNIX systems including AIX 3.1 onwards. I remember that I also came across it on a DGUX box and Digital UNIX systems.
It became the basis for the POSIX shell (which was effectively ksh88 with a few tweaks), and I think that Bash was written to be a POSIXly compliant shell, which makes ksh a direct ancestor of Bash.
Oh, and in answer to csh, what planet are you from! I know that some wierd people using BSD used csh (but many people on BSD didn't), but really it bore almost no relation to the Bourne shell. In my experience, most people only really used it because of the history features. And most of them only used it as an interactive shell, and wrote most of their scripts in the Bourne shell, even though csh was intended as a programming shell.
I'm not saying that it could not be used, but when I compiled it up on a Bell Labs. V7 UNIX box from a BSD 2.3 tape in something like 1982, it felt so foreign and wrong that I quickly went back to the normal shell.
-
-
Friday 11th January 2019 14:29 GMT W.S.Gosset
Re: Bourne Again Shell (Bash – geddit?)
> Probably the case that Bash was not the successor to the Bourne Shell, but to ksh, the Korn Shell
As I understood it at the time, it was intended to be both.
He wanted to revisit his original shell (which had clean scripting syntax), plus he wanted to add in all the post-sh User Interface ideas of which ksh was the pioneer and about the most advanced. Basically, sh functionality improved, ksh UX improved
eg, instead of only having ksh's vi-style navigation possible, bash also included emacs-style navigation (ctrl-R to search-reverse, etc), which turned out to suit most people best in shell's text-entry-focus environment. Such that many people now think it came from bash not emacs.
-
-