BASH 4.0 Released 459
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 excellent news (Score:5, Funny)
Perhaps this year, Linux will be ready for the desktop.
Re:This is excellent news (Score:5, Funny)
No, but it'll be ready for the year of the commandline (comes right after year of the hippo).
Re: (Score:3, Funny)
Re:This is excellent news (Score:5, Insightful)
Linux has been ready for the desktop for years. It's just that certain users are not yet ready for Linux.
Re:This is excellent news (Score:4, Funny)
So... when can we expect the year of the L(inux)user?
Re:This is excellent news (Score:5, Insightful)
You are too kind. In fact, most users are not ready to operate computers. At all.
Re: (Score:3, Insightful)
Most people don't need to operate computers directly. But a lot of people uses them more or less indirectly, for example, when driving a modern car, or when redacting a letter in MS Word. The idea is that people should never have to be ready for (nor aware of) any OS at all.
Re: (Score:3, Informative)
I will give you the car, but not Word. Want it or not, they ARE operating a computer directly when using MS Word.
Ah, a friend of mine LOVES you (Score:5, Insightful)
He has a garage, fixes cars. He LOVES people that don't think they need to operate their car. Some lovely person puts petrol in the company van, ah christmas come early! Oil light been on since "Oh I just ignore that as the car starts fine with it on", we will eat tonight!
The simple fact is that we got to know a lot of stuff and if we don't we pay other people a LOT of money for knowing their stuff. 175 euro for 15 minutes work unglogging a toilet because some female doesn't know you can't put femine hygiene products down the toilet.
50 euro to run a set of automated tools on your PC to clean it, total labor involved, inserting a USB stick, you got to bring the PC in, during quiet hours and pick it up yourself, no warranty.
My neighbour changed his the nature of his small construction firm, he no longer does projects for clients, he assists DIY'ers with theirs. To translate, he charges a FORTUNE to fix the mess they made and has their free labor to help out with simple but expensive to hire a pro for tasks.
Everytime somebody like you defends people not having to know the tools they use, somebody somewhere sees dollar signs.
Re: (Score:3, Funny)
Fixed it for you...
Re:This is excellent news (Score:5, Informative)
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.
Re: (Score:3, Insightful)
It's gotten a lot better, but there are still gaps that need to be filled in.
Today, I had to enable printer sharing (via Samba for Windows clients) on my parents' computer, which is running Ubuntu.
Although the majority of the desktop is very well-integrated, the process for doing this was *extremely* non-obvious.
Re: (Score:3, Informative)
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.
Re:CORRECTION (Score:5, Insightful)
...MOST users.
To be fair, most users have trouble setting the clock on a VCR.
Yes!!! (Score:5, Funny)
This is definitely the turning point; the Register just last week published an article indicating that the one thing stopping most users from migrating from Windows was the lack of support for the `**' special glob pattern.
looks like it still loses history (Score:5, Insightful)
Don't get me wrong, I really like bash, but the treatment of history is abysmal. The default behavior is to lose history due to a race condition when multiple bash sessions that are concurrently open are closed in arbitrary order.
IMNSHO, the default of any process should be to never lose data.
Re:looks like it still loses history (Score:5, Informative)
Re:looks like it still loses history (Score:5, Insightful)
Bah. History files are a horrible security problem. History belongs in memory. I can count on about ten hands the number of times I have found passwords and various other sensitive information in them.
First line in my .bashrc files: unset HISTFILE
Re: (Score:3, Interesting)
I guess that I must be weird or something. I don't expect bash to retain history from one invocation to the next, and I'm always surprised when it happens.
Re: (Score:3, Interesting)
Re:looks like it still loses history (Score:5, Interesting)
Log in twice (A) and (B) as the same user, do something in session (A), then log out of (A).
Now check 'history' as (B), obviously the first session's command isn't there.
Open another session, (C) and check its history. It is just as you'd expect. Now type a simple command into session (B) and log out of it. What do you think the history is?
Check history on (C) still logged-in. Log out of (C) and check history on a new login and you'll see that the history matches (C) inherited from (A), no record of (B) happening.
Re:looks like it still loses history (Score:5, Informative)
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)
Re:looks like it still loses history (Score:5, Insightful)
I'll grant I haven't thought this all the way through, but a slightly lighter-weight approach than daemons and databases might look like this:
Each open session logs history to a uniquely-named file. Then on session close, that file can be appended to the one true history file. (A bit of file locking can maintain atomicity of the append step.)
When you scroll back into history, you would start with your own session's still-open-and-separate history file -- which is more often than not what I'd expect, but not always what I get today. If you go back beyond the beginning of that, I supposed you'd scroll into the accumulated history of closed sessions.
This means that one session doesn't "see" the history from a concurrent session while they're both open. That, too, can be addressed, even if it has to wait for a subsequetn release. Either way, it's better than just losing the data IMO.
Re:looks like it still loses history (Score:5, Informative)
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.
Re:looks like it still loses history (Score:4, Informative)
or just add to your bashrc/profile scripts:
shopt -s histappend
Re: (Score:3, Informative)
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.
Re: (Score:3, Funny)
BASH doesn't like it when you anthropomorphize it. ;-)
Feeding a troll (Score:4, Insightful)
Yes, I am complaining about the default behavior.
How about if we made the default for mv to delete blocks as they were copied and not wait to delete to original until a full copy was made. This would be 'good' (more efficient) most of the time and break in strange corner cases, losing the users data (not a good thing^TM).
The default behavior should *NOT lose data*. To do so is bad UI design.
Re:true... (Score:4, Interesting)
Or do "set -o inc_append_history" in zsh.
(I'm not sure if the option is case sensitive. It may need to be in CAPS, the lameness filter made me change it)
Re:true... (Score:4, Funny)
Use i.e. as a stand-in for "that is."
I prefer to use Firefox.
patience (Score:5, Funny)
i'll wait for 4.2
Re: (Score:3, Funny)
Re:patience (Score:5, Funny)
Give me a K..DE!
You tried to say 'KDE' but there was a lag before it completed... Just like true KDE4!
*Runs away*
Re: (Score:3, Funny)
Uh ... wait a sec ...
Circular what? (Score:3, Funny)
Re:Circular what? (Score:5, Funny)
stay away from kernel.org then.
Re:Circular what? (Score:5, Insightful)
What do you think was used to compile GCC?
Re:Circular what? (Score:5, Funny)
Re:Circular what? (Score:5, Funny)
Re: (Score:3, Funny)
Re:Circular what? (Score:5, Funny)
EGCS, duh.
Re: (Score:3, Informative)
After bootstrapping... (Score:3, Funny)
After bootstrapping the new compiler with the old compiler, you can then use your new compiler to compile the new compiler code.
If this bothers you, stay away from recursion [wikipedia.org]!
Re:After bootstrapping... (Score:5, Interesting)
Broken link. Try this: Reflections on Trusting Trust [boun.edu.tr]. It's the most frightening security paper of the last 30 years.
Re:Circular what? (Score:5, Funny)
Sup dawg, I heard you liked compiling, so I put a compiler in your compiler so you can compile while you compile.
Bugs (Score:3, Funny)
The new major release fixes several remaining bugs in the 3.x releases
That's great, but they forgot to mention how many new bugs were introduced.
My Dr. Seuss observation... (Score:5, Funny)
So now I can make a BASH hash, sweet!
Re: (Score:3, Funny)
I've been making a hash of BASH for years! Just ask the folks who review my code!
Zsh has had these features for years (Score:5, Informative)
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.
Re: (Score:3, Funny)
Re:Zsh has had these features for years (Score:5, Funny)
Excellent post. I look forward to the ensuing flame war.
Re:Zsh has had these features for years (Score:5, Interesting)
The reasons I use zsh and not bash:
1) ... some pipeline | read variable
In zsh you can use $variable to get the value. In base you have to do variable=$(... pipeline | { read variable; echo $variable; } ), and this is annoying and complicated when doing anything more than reading just one variable.
2) tab completion doesn't have a cycle mode (like DOS's completion)
abc-1.2.3
abc-1.2.4
abc-2.0.1
abcdef
In bash you have to do "a, tab, -, tab, 1, tab, 3" to get the first one. That means you have to know all the filenames so that you know what letter to press to get the next 'section' of the filename you want (you can double-tab to get a menu, but it's annoying). In zsh you can configure it to cycle, so to get the first one you type "a, tab" or the second one "a, tab, tab".
3) rm -f -- $FILE
In zsh, this does what you want, removing the files. In bash you have to say "$FILE" because if it has a space it is treated as two parameters, and also wildcard expanded. It's annoying to have 1/3 of the script be " characters.
4) bash history has problem with multiple shells. It only writes the commands when the shell exists, so if it exits unexpectedly your history is lost. And if you open up another terminal you can't ctrl-r for recent commands in another window.
5) zsh's line editor is better when editing multi-line commands and just generally readline is a pos. After having to use readline in a C program I have a huge bias against anything using it. It sounds like they improved it slightly by being able to remember the prompt text... before to erase the prompt and reshow it (in order to print async text) you had to remember the prompt index, delete the prompt text, save the prompt, clear the message, your code here, then restore the prompt, undo the delete of the text, restore the prompt index (by setting a global variable), then redisplay the prompt, then set the prompt string. Oh, and each one of these functions is just poorly documented enough that you feel like it might possibly tell you what you need to know, then you find out the time you spent figuring out how to navigate an 'info' file (again) was completely wasted.
Re:Zsh has had these features for years (Score:5, Funny)
I also found the vi mode in zsh to be inferior to the equivalent in bash last time I tried it, but maybe it's improved since then.
That's because Emacs's bindings are far more logical than Vi's, especially when running on FreeBSD instead of Linux. Oh, and indent with spaces.
Did I miss anything?
Re: (Score:3, Interesting)
A shell wants to suck in half of qt? :/
Screenshots? (Score:5, Funny)
Does anyone have any screenshots? I always hate that when they post some great new upgrade without any screenshots.
Re:Screenshots? (Score:5, Funny)
$
#
Re:Screenshots? (Score:5, Funny)
Anyone have a high-res screen shot? My fonts are raster based. :-(
Re:Screenshots? (Score:5, Funny)
Here you go..
[root@localhost ~]#
Re:Screenshots? (Score:5, Funny)
I was really hoping someone would post a picture of a half-rotated Compiz cube with a bash shell running transparently on it.
Re:Screenshots? (Score:4, Funny)
http://imagebin.ca/view/M6HnUiBp.html [imagebin.ca]
You betchya.
Re:Screenshots? (Score:4, Informative)
Warning, above post is NSFW!
Note for sysadmins (Score:5, Funny)
With your production boxes, it's generally recommended that you wait for Bash 4.0 SP1 before deploying.
Bourne Shell (Score:3, Insightful)
If you want your scripts to be compatible with just about every Unix, you still need to stick with /bin/sh (yes, I know, it's a compatibility mode). If you don't, might as well use a better scripting language.
Re: (Score:3, Interesting)
Apparently, bash's own compatibility mode leaves a lot to be desired. There's no end to people on FreeBSD lists who bitch about porting some script from Linux, to have someone point out that /bin/sh on Linux 99.9% of the time equals /bin/bash in compatibility mode. Best to code for strict Bourne shell syntax even if you use Linux, since you can be reasonably assured that it will work nicely on other systems. Not sure what the de-facto open source Bourne shell clone is. Perhaps "ash" is close enough, as
Re: (Score:3, Informative)
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.
Re: (Score:3, Interesting)
use a better scripting language
That's what I've been wondering. Bash is fine for the command-line but not such a good choice for scripts due to compatibility issues. It certainly isn't a good choice of scripting language compared to /bin/sh. Given the number of changes bash has had over the years it would seem to be a kitchen sink of every feature anyone wanted to add (though not necessarily use). POSIX is protecting /bin/sh from this sort of feature creep but there are still several bugs in "bash --posix" (sh mode).
I also wonder abo
Re:Bourne Shell (Score:4, Insightful)
Solaris 9 (10 is *far* from universal, hell, even 8 is pretty common). HPUX. Tru64. That's three off the top of my head.
People have ported GNU to them but you just can't rely things like bash being there - you have to be able to work with the out of the box environment.
Re: (Score:3, Funny)
Tru64. That's three off the top of my head.
What, three users or three installed servers?
Tru64 has been abandonware for four long years and will have no commercial support in only three years.
To quote the great wikipedia:
In December 2004, HP announced a change of plan; they would instead use the Veritas file system and abandon the Tru64 advanced features. In the process, many of the remaining Tru64 developers were laid off.[8]
In July 2007, HP stated that they would continue to support Tru64 UNIX until at least 2012.
You'd get more support by complaining that VMS, MVS/370, and TRS-DOS 1.3 don't come with BASH.
Re:Bourne Shell (Score:5, Insightful)
Re: (Score:3, Insightful)
Out of the box? My guess is "almost all of them", at least where BASH 4 is concerned. Outside of the Linux community, BASH 4 will pretty much be stillborn. I expect close to zero adoption.
Why? GPL v3. The *BSD community is working hard to replace everything the FSF produces with BSD-licensed code because GPL v3 is so offensive to them. They're well on their way even in hard-to-fill spaces like compiler technology. With shells, they already have several viable replacements, so there's no point in cont
something resembling homepage (Score:3, Insightful)
it would be quite cool if they could set up at least something something resembling homepage.
you know, the thing with announcements, news, and, ooooh, release notes !
wiki probably would be too much to ask.
Re:something resembling homepage (Score:5, Funny)
Are you smoking something? This is a GNU project. The "web page" is actually a facade to appease the unenlightened. Here is a Web 1.0 concept mapping for you:
news page -> "announce" mailing list
wiki -> "user" mailing list, documentation
developer forum -> "dev" mailing list
release notes -> in the tarball!
Ant-style ** globbing (Score:5, Funny)
Instead of rm -rf /, we can now just say
rm -f /**
Now that's an improvement!
Re:Ant-style ** globbing (Score:4, Interesting)
The scary thing "rm -f /**", when used with the new shopt "globstar", removes all non-directory files while preserving the directory skeleton. It's kinda like vaporizing everyone in the town while leaving all the empty buildings and cars intact...
Re: (Score:3, Informative)
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 [bash-hackers.org]
Re: (Score:3, Interesting)
Without -r, rm will error instead of deleting directories, however these errors will not stop rm from removing the remaining files on the command line.
The buildings and cars remain due to malfunction, not design ;)
Re: (Score:3, Funny)
Ah! A command-line neutron bomb?
I am sure Linux is ready for the desktop now.
Re:Ant-style ** globbing (Score:5, Funny)
Backward Compatibility (Score:4, Interesting)
I'm seeing release candidate versions of bash 4 in the SRPMS dir for Fedora testing. It should be easy to rebuild it on Fedora 10 and install it, but I'd like to know if it would break existing scripts.
Does anyone know if it has any backward compatibility issues?
Freedom at a price (Score:4, Interesting)
Translation: "Most of us would try it out if only it was easy to do so and we had the freedom to easily install and use Linux software, but we don't, because software installation standards have yet to be worked out and right now it's annoying as hell tracking down the dependencies manually and struggling through the compilation process. Instead, we'll rely on distro companies to give us access to software instead of being able to download and run like Mac and Windows users have the luxury of doing."
Yeah, I'm sure I'll hear the "if they want to try out BASH then they probably know how to compile already" argument, but a) that doesn't make it any less annoying, just because you like using the command line doesn't mean you hate convenience, and b) I'm speaking generally about the sever lack of Linux binaries in existence, and the complete lack of nice installation packages unless you get lucky and someone targeted your specific version of your specific distro.
Once Linux application installation becomes a snap, so any Linux users can easily share software, you will see a much greater proliferation of Linux programs out there, torrents etc, because it will actually be useful keeping archives of packages because they won't go obsolete in 6 months. Once users can easily share Linux programs, it will help make Linux adoption sore and Linux users who don't want to or don't know how to compile will finally be free of suckling on distro companies for their software milk.
Re:csh syntax mode? (Score:5, Funny)
Re:csh syntax mode? (Score:4, Interesting)
If bash is invoked with the name sh, it tries to mimic the startup behavior of his- torical versions of sh as closely as possible, while conforming to the POSIX stan- dard as well. When invoked as an interactive login shell, or a non-interactive shell with the --login option, it first attempts to read and execute commands from
Re: (Score:3, Informative)
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.
Re:csh syntax mode? (Score:5, Funny)
WHOOOSH
I was following this discussion of bash, sh, csh and tcsh perfectly well, but now I'm lost. What shell are you talking about?
I hate [T]CSH (Score:5, Insightful)
One of my favorite bookmarks, Csh Programming is Considered Harmful [uni-giessen.de], is very useful for shell scripting in Bourne, Csh, and Bash. Oh, and it's also a good reminder of why you should never write csh scripts.
In my experience, the only [t]csh users out there are those who used it back in the day before there were other options, or those who are so embedded in the C/C++ world that they thought it a good idea to use a C/C++ -styled shell. That's fine, use that shell. DON'T write scripts in it though. It's annoying. (More annoying: ln -s /bin/csh /bin/sh ... this breaks TONS of things as /bin/sh must be posix-compliant. Csh doesn't even want (or try) to do that!)
Re:csh syntax mode? (Score:5, Funny)
This is great, but I find the csh syntax easier to use from the command line (however unsafe it is to use in scripts). Will they add a csh compatability mode to bash?
ln -s /bin/false /bin/csh
99% of the functionality of csh, without the bugs!
Re:Linux (Score:5, Funny)
Still gay.
Don't bash it dude.
Re:So? (Score:4, Insightful)
Re: (Score:3, Informative)
Re:So? (Score:4, Informative)
Gentoo uses bash for their init scripts citing reasons of speed.
Yeah it does show.
Re:So? (Score:4, Interesting)
Weird, because Debian moving away from bash to dash for exactly the same reasons.
http://www.nabble.com/Making-init-scripts-use-dash-td4458217.html [nabble.com]
Re: (Score:3, Funny)
Gentoo uses bash for their init scripts citing reasons of speed.
Weird, because Debian moving away from bash to dash for exactly the same reasons.
Like the way Red Hat uses nash?
Or the way Microsoft uses cash?
I apologize, but I saw the opening and had to take the shot.
Re: (Score:3, Informative)
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.
Re:So? (Score:5, Informative)
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.
Re: (Score:3, Insightful)
Do you use bash on a day to day basis?
I love using bash scripting inline, so to speak. The speed that you can get complex things done on the commmand line (and you might be surprised how much you can do with a little ingenuity) is due in no small part to the flexibility of the bash scripting language.
Sure, you could fire up vi (or perhaps nano?) and write a "serious" script to help you get the job done, but my way's quicker.
Re: (Score:3, Interesting)
Is there a single Linux (or Unix) user without some knowledge of bash?
Yes, lots and lots. At my house, for example, we have eight Linux users, but only two of them have any knowledge of bash. At my aunt's house, there is one user of Linux, but none with any knowledge of bash. Depending on how far you're willing to stretch the definition, every person with a TiVo could be considered a Linux user, and very few of them are likely to have any knowledge of bash. Etc., etc.
Re: (Score:3, Insightful)
Tons of fun for a certain kind of hacker, but not of any interest for people writing serious scripts.
Most serious scripts are (and continue to be) written using /bin/sh. Maybe your definition of serious is something different?
But the scripting community has moved on, and doesn't really care that Bash or Csh now have features that other scripting languages acquired decades ago.
Huh? Some of the new features are welcome for interactive use, and bash is extremely popular in that regard. Feature parity (in a
Re: (Score:3, Insightful)
You're an idiot.
The shell is my file manager, and my entire dev toolchain works from the shell. Shell scripting is better suited to linking together unix commands that pipe text between one another. I don't particularly want any scripting interpreters other than bash and awk to be _required_ on my systems. I like lua and javascript, some folk prefer perl, python or ruby but nobody is getting very far on a unix-like system without /bin/sh and the de-facto standard for that is bash.
De Facto Bullshit (Score:3, Interesting)
When did bash become the "de-facto standard"? I work at Sun, which has been in the Unix business for a couple decades. The most common interactive command line here is csh. (Bill Joy being the original head of software probably had something to do with that.) Most software developers here do prefer bash to csh, especially for scripting. But if somebody tried to tell them they couldn't use any other scripting language, they'd probably quit all at once. If you asked them what the de-facto standard was, I thin
Re: (Score:3, Funny)
What's the point? It's worthless on my multi-touch screen. Only crusted headed, unbathed, girlfriendless uber geeks need to use the CLI.CLI's are so 1940's Get with the times you gezzers.
Hey, I am not an "uber"!