Slashdot Mirror
BASH 4.0 Released
An anonymous reader writes "The widely used Bourne-Again Shell (BASH) version 4.0 is out. The new major release fixes several remaining bugs in the 3.x releases, and introduces a bunch of new features. The most notable new features are associative arrays, improvements to the programmable completion functionality, case-modifying word expansions, co-processes, support for the `**' special glob pattern, and additions to the shell syntax and redirections. The shell has been changed to be more rigorous about parsing commands inside command substitutions, fixing one piece of POSIX non-compliance. Most of us will probably wait for the distros to test the new version and upgrade gradually, but you always have the option of grabbing the source and compiling it yourself. Enjoy."
This is GNU Bash, version 4.0. Bash is the GNU Project's Bourne
Again SHell, a complete implementation of the POSIX.2 shell spec,
but also with interactive command line editing, job control on
architectures that support it, csh-like features such as history
substitution and brace expansion, and a slew of other features.
For more information on the features of Bash that are new to this
type of shell, see the file `doc/bashref.texi'. There is also a
large Unix-style man page. The man page is the definitive description
of the shell's features.
See the file POSIX for a discussion of how the Bash defaults differ
from the POSIX.2 spec and a description of the Bash `posix mode'.
There are some user-visible incompatibilities between this version
of Bash and previous widely-distributed versions, bash-2.05b and
bash-3.2. For details, see the file COMPAT. The NEWS file tersely
lists features that are new in this release.
Bash is free software, distributed under the terms of the [GNU] General
Public License as published by the Free Software Foundation,
version 3 of the License (or any later version). For more information,
see the file COPYING.
A number of frequently-asked questions are answered in the file
`doc/FAQ'.
To compile Bash, try typing `./configure', then `make'. Bash
auto-configures the build process, so no further intervention
should be necessary. Bash builds with `gcc' by default if it is
available. If you want to use `cc' instead, type
CC=cc ./configure
if you are using a Bourne-style shell. If you are not, the following
may work:
env CC=cc ./configure
Read the file INSTALL in this directory for more information about how
to customize and control the build process. The file NOTES contains
platform-specific installation and configuration information.
If you are a csh user and wish to convert your csh aliases to Bash
aliases, you may wish to use the script `examples/misc/alias-conv.sh'
as a starting point. The script `examples/misc/cshtobash' is a
more ambitious script that attempts to do a more complete job.
Reporting Bugs
==============
Bug reports for bash should be sent to:
bug-bash@gnu.org
using the `bashbug' program that is built and installed at the same
time as bash.
The discussion list `bug-bash@gnu.org' often contains information
about new ports of Bash, or discussions of new features or behavior
changes that people would like. This mailing list is also available
as a usenet newsgroup: gnu.bash.bug.
When you send a bug report, please use the `bashbug' program that is
built at the same time as bash. If bash fails to build, try building
bashbug directly with `make bashbug'. If you cannot build `bashbug',
please send mail to bug-bash@gnu.org with the following information:
* the version number and release status of Bash (e.g., 2.05a-release)
* the machine and OS that it is running on (you may run
`bashversion -l' from the bash build directory for this information)
* a list of the compilation flags or the contents of `config.h', if
appropriate
* a description of the bug
* a recipe for recreating the bug reliably
* a fix for the bug if you have one!
The `bashbug' program includes much of this automatically.
If you would like to contact the Bash maintainers directly, send mail
to bash-maintainers@gnu.org.
While the Bash maintainers do not promise to fix all bugs, we would
like this shell to be the best that we can make it.
Enjoy!
I've been using Zsh (the Z shell) for years, because it had better completion, and a richer bourne-shell and ksh-based programming language including also associative arrays and the co-process.
So it would appear that bash finally caught up. But zsh has continued to improve. I'll be sticking with zsh for now, until I see that bash really caught up.
What the fuck are you talking about? In the real world, shell scripts are used all the time. Despite their failings relative to more complex languages like Python and Perl, shell scripts are very easy to generate from repeated manual invocations of command lines.
In other words, to scratch an itch with a Python script requires writing your command over again. With a shell script, you can build on the commands you've already typed. Shell scripting is the original RAD, and remains very useful today.
It's commonly referred to as bootstrapping. For instance, you might bootstrap your compiler by using an older version to compile the newer version of that compiler.
are you looking for shopt -s histappend ?
Gentoo uses bash for their init scripts citing reasons of speed.
Yeah it does show.
Give me a K..DE!
Bored at work? Play Game!
This almost works. I have tried using an approach like this by building bash scripts and modifying history variables.
One issue is that sessions that don't terminate cleanly (ssh loss, system reboot, etc.) leave a bunch of dirty history files that would need to reaped at the next start up of a bash.
-- The morphemes of your disquisition are ascertainable, but they have eschewed an ambit of transpicuous exposition.
WHOOOSH
"You're older than you've ever been, and now you're even older."
I'm sorry, but /etc/rc.d/rc.sysinit is certainly not empty on my Fedora boxes. It also contains a lot of good functionality that matters to system start-up.
- Michael T. Babcock (Yes, I blog)
Judging by the number of Windows machines that are active members of botnets, it's not just the Linux desktop "MOST users" are not ready for.
I don't care why you're posting AC
That's only part of the solution. Yes, that will retain all recent commands but not in the order in which they were entered (instead, commands will be stored in the order in which the shells were closed).
In order for history to be kept in chronological order, you need to
$ set PROMPT_COMMAND='history -a'
which I think is an ugly hack, but it ensures that the history file is appended (or rewritten, without histappend) each time the command prompt returns.
I did exactly as you said, and at the new login I had the commands from A,B,C (in that order) in history.
Here's what it looks like:
996 echo AAA # A
997 history|tail # checking history on B
998 echo BBB # B
999 history|tail # checking history on C
1000 history|tail # checking history on C, again
1001 history |tail # new login
This is:
GNU bash, version 3.2.33(1)-release (x86_64-redhat-linux-gnu)
.
I will give you the car, but not Word. Want it or not, they ARE operating a computer directly when using MS Word.
morcego
There is a new shell option: `globstar'. When enabled, the globbing code treats `**' specially -- it matches all directories (and files within them, when appropriate) recursively.
which would imply the buildings and cars go too. See also: http://www.bash-hackers.org/wiki/doku.php/bash4
by typing csh, you're loading the c shell and leaving bash. Parent asked for compatibility mode.
Hilarity ensues.
As for why you should care which shell is which, you probably don't. You'd only care if you were using more advanced features or scripting. A quick google will show you all your shell can do. It's impressive, really.
:x
Warning, above post is NSFW!
"I was in love with a beautiful blonde once, dear. She drove me to drink. It's the one thing I am indebted to her for."
This is a placeholder for my reply to your comment. The comment itself has been written on paper using a disposable BIC ballpoint pen. The paper has been posted to the slashdot editors with instructions to replace this placeholder with the comment that is contained on the paper.
A note to moderators. The comment I have written on the paper is both insightful and informative as well as funny. It would be impossible to consider the comment I have written to be overrated (even if it were rated +100), a troll, or flamebait. So please rate this placeholder accordingly.
Thank you.
it is only after a long journey that you know the strength of the horse.
The Slackware standard for init scripts and other system utils done is shell is that it should run on ash. If it runs on ash it will run on bash. The installation media used to, and still does? use ash while an installed system uses bash as the interpreter. So I agree with you its reasonable to code to ash for shell scripts if portability to othe *NIX like systems or running in striped down cases like installation environments is any concern.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
or just add to your bashrc/profile scripts:
shopt -s histappend
The revolution will not be televised... but it will have a page on Wikipedia
I've said it in another post, but just to be helpful:
shopt -s histappend
add to your bashrc/profile scripts. Should do the trick for ya.
The revolution will not be televised... but it will have a page on Wikipedia