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."
Keep the history added in the current session in memory and, when exiting, lock the history file and append? Actually, as far as I know that's what it does; I don't think I've ever seen it actually lose history with multiple concurrent sessions, just add it to the history file in different orders depending on timing. I don't think I've paid that much attention, though.
i think you mean sh, /bin/sh is a symlink to bash in most all Linux systems, calling bash from the sh symlink: Man page ahead::
/etc/profile and ~/.profile, in that order. The --noprofile option may be used to
inhibit this behavior. When invoked as an interactive shell with the name sh, bash
looks for the variable ENV, expands its value if it is defined, and uses the
expanded value as the name of a file to read and execute. Since a shell invoked as
sh does not attempt to read and execute commands from any other startup files, the
--rcfile option has no effect. A non-interactive shell invoked with the name sh
does not attempt to read any other startup files. When invoked as sh, bash enters
posix mode after the startup files are read.
/bin/csh is usually a symlink to /bin/tcsh in most all Linux systems.
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
Politics is Treachery, Religion is Brainwashing
Broken link. Try this: Reflections on Trusting Trust. It's the most frightening security paper of the last 30 years.
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.
- Michael T. Babcock (Yes, I blog)
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
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...
Colorless green Cthulhu waits dreaming furiously.
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?
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.
Good, inexpensive web hosting
A shell wants to suck in half of qt? :/
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.
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 the various BSD's use it (or a modification of it) as the system /bin/sh.
Method of processing duck feet
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 ;)
If I have been able to see further than others, it is because I bought a pair of binoculars.
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 think they'd all say Perl. Even the ones that hate Perl.
Your religiousity about bash may work for you, but it wouldn't for most people. I'm a writer, not a developer, but I do need to write the odd small program now and then. The other day I wrote a 20-line Perl script that pulls a list of names off a web site, looks them up in an LDAP database, and saves retrieved user data in a text file. (The point is to synchronize a web site user access list that I maintain with one that I don't.) I'm sure I could do it as a shell script, but it would be a lot more complicated, and probably a bit less efficient.
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 about feaures like associative arrays in shells. Obviously someone wanted to code it, but a shell seems like the wrong tool for any job needing an array. Is Bash's feature creep just bloat, motivated by some shell programmer's fears of learning a more appropriate scripting language like Python or Perl? I have to say it seems that way given that +99% of Bash scripts are simply the result of the script writer's lack of familiarity with the differences between bash and sh.
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.
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)
We hope your rules and wisdom choke you / Now we are one in everlasting peace
"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."
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.
Promote true freedom - support standards and interoperability.