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."
Perhaps this year, Linux will be ready for the desktop.
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?
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.
-- The morphemes of your disquisition are ascertainable, but they have eschewed an ambit of transpicuous exposition.
i'll wait for 4.2
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!
So, I'm gonna grab the source to BASH and compile it using GCC under BASH? My brain hurts :).
512 MB RAM, 20 GB disk, 200 GB transfer, five datacenters. $19.95/month.
Nobody will really care about the new features so long as "man woman" still does that vagina-less woman joke.
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.
Still gay.
Don't bash it dude.
Oh, good.
I'm sure someone likes case-sensitive filenames, but they annoy me way more often than I find them useful. Maybe this will reduce or eliminate one of my biggest problems with them.
So now I can make a BASH hash, sweet!
"Murphy was an optimist" - O'Toole's commentary on Murphy's Law
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.
Does anyone have any screenshots? I always hate that when they post some great new upgrade without any screenshots.
More
So you like to type in script, No forgiveness when a space is skipped, It doesn't matter, I'm hard up for cash. Thank goodness I have patience, for the love of BASH
The day Ruby or Python takes over from the boot grub loader for the initialization of init levels in Linux on start up is the day your statement makes sense. Until then, I think people with your attitude love one tool too much. If you don't understand BASH, you don't really understand Linux. I think OS start up is a serious script.
With your production boxes, it's generally recommended that you wait for Bash 4.0 SP1 before deploying.
#DeleteChrome
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.
"I think OS start up is a serious script."
Surely it is.
You must think it's such a big pity Bash is not used on OS start 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.
But the scripting community has moved on,
"The scripting community"...that has to be the funniest phrase I've heard in a long time.
Advice: on VPS providers
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!
I only look human.
My mother is a halfling and my dad is an ogre, so that makes me an Ogreling
I'm curious, in your opinion what is a better use of my learning time? I'm learning bash scripting and python scripting at the moment as I am a sysadmin with a lot of time. What do you propose I learn instead?
Bored at work? Play Game!
Get off your high horse. Upstart works equally well with shell scripts for events. Shell scripting is plenty useful and is here to stay. The only reason you'd shun it is if you were a cocky newbie who hasn't yet learned to not re-invent the wheel.
Can someone post a link to a simple "What's New" doc? I'm not gonna go combing through the code to see if they've fixed my bug.
-*The above statement is printed entirely on recycled electrons*-
I know you are kidding, but the award of really bad program name should go to the WebDAV client "cadaver".
And I'm tempted to name my WebDAV server "morgue" ;)
No kidding. I'm not a huge fan of bash scripting, but as a big commandline user, I am looking forward to the ** globbing.
-l
Help cure AIDS, cancer, and more. Donate your unused computer time to worldcommunitygrid.org. Join Team Slashdot!
"acpid: POSIX shell script text executable"
Very few OSes use bash for init.d scripts.
Gentoo uses bash for their init scripts citing reasons of speed.
Yeah it does show.
The new major release fixes several remaining bugs in the 3.x releases, and introduces a bunch of bugs.
Do those actually require bash? Or are they 'sh' scripts that 'file' happens to call bash scripts? This isn't anti-shell hostility, it's anti-linux centric non-standard bash scripts hostility.
Give me Classic Slashdot or give me death!
But is it snappier?
I do find having moderate lightweight programmability in a shell to be useful, for writing one-off things on the command line: things like doing some operation on file_X for X=01 to 99. But for anything more significant, I find myself always writing a Perl script or something.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Shell scripting is obsolete technology.
Hardly. Shell scripting is still useful for all those simple tasks that are not much more than a couple of linked shell commands, where Python or Ruby would be major overkill. On the other hand, I'd never use Bash to write anything complicated, as Python is much easier for that.
Maybe it's a weird way to go about it, but when I write my shell-script-like Perl scripts, I start them out similarly by just building on commands I've already typed, wrapped in system(). Slightly heavier-weight syntax, but not by much, and allows me to use all the rest of Perl, which makes some things easier.
It does provide a portability route if I want one: I can convert all the system("mv whatever") calls to use the proper Perl OS-abstraction libraries. But you don't have to start out with those.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Can I order DVD from bashmall.com ?
Bourne bourne bourne bourne again!
Of course I wouldn't wait for 4.2, as someone pointed out above, but rather I would stick to using 3.5, even though really they are only at 3.2.
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)
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.
You feel sleepy. Close your eyes. The opinions stated above are yours. You cannot imagine why you ever felt otherwise.
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.
Rich
... certain users are not yet ready...
...MOST users.
And the only (partial) way out of this problem I know of is screen. It offers a way of not having to close a session but to disconnect from it and later connect. You still cannot use multiple session with one user and keep all history, but you i.e. can run your primary commands on you screen session and keep that one running all the time (and keep your important work). Working that way is also a nice way to keep focused. Need to keep your machine running, obviously.
I love BASH, and it's my primary shell, but other shells have some really cool features. ZSH can have status bars and some cool syntax for lazy people and FISH has built in syntax highlighting...
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 general hand-wavy sense) doesn't exist between bash, csh, zsh, etc., so decades later, the choice of shells remains important, as does continued development.
Personally I use bash (with plenty of Perl one-liners thrown in for good measure), but I'd be misguided to think that bash (or Perl) is available everywhere, or didn't concede that other shells do certain things far better.
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
Instead of rm -rf /, we can now just say
rm -f /**
Now that's an improvement!
æeee!
One of my favorite bookmarks, Csh Programming is Considered Harmful, 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!)
Use my userscript to add story images to Slashdot. There's no going back.
On my Fedora Core 6 box, 44 of the 75 scripts in my /etc/rc.d/init.d start with:
#!/bin/bash
For Fedora 10, 31 of 47 scripts start with that line.
There are some non-Fedora packages on the boxes, YMMV, etc.
and I thought slurpd was bad :)
I did say that shell scripts still had their uses. But does that make new shell features worth caring about? Will any of them find their way in the boot scripts?
shell scripts are very easy to generate from repeated manual invocations of command lines.
Very simple shell scripts, which don't use any of these fancy new features. I'm still not hearing a reason I should care about a major update to Bash.
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.
I believe you're the kind of person I was referring to when I said "tons of fun for a certain kind of hacker." But tell me, is this latest update to Bash going to have any sort of impact on your productivity? Or is it just more kewl stuff that you'll enjoy playing with?
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?
Most serious scripts are (and continue to be) written using /bin/sh. Maybe your definition of serious is something different?
Scripts written in a serious language. Maybe you've been using sh so long, it's more efficient for you to work in it than in any more modern language. (Rather like an old Bell Labs hand I used to know who could edit faster in ed than any of us could in vi or emacs.) But the traditional shell language is still very klunky and limited compared to later scripting languages.
I still write the odd shell script myself. But if I need to do anything at all complicated, I switch to Perl. And even Perl is showing its age. (If writing scripts were a bigger part of my job, I'd learn Ruby.) But it's still more sophisticated than sh, bash, or csh.
Wow, that was fast!
I hope to god nobodies got a ** typo in an old script because that could be troublesome.
Even worse it could be simple enough to ** in error on the prompt.
Get off my lawn. Shell scripting? What's wrong with machine code? Damned cocky newbies.
"Wise men talk because they have something to say; fools, because they have to say something" - Plato
That's doubly interesting, given that a couple weeks ago in the portable shell scripting book review, some people were insisting that everyone should tell other shells (and portability) to fuck off and just use bash (and it's extensions).
Do you even lift?
These aren't the 'roids you're looking for.
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.
-- The morphemes of your disquisition are ascertainable, but they have eschewed an ambit of transpicuous exposition.
Gentoo uses bash for their init scripts citing reasons of speed.
Of course, more time left for compiling.
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.
"...who hasn't yet learned to not re-invent the wheel."
Are you serious? re-inventing the wheel is pretty much the basis of our existence.
You can claim otherwise, but you'd better pull up, naked, riding on some wooden rollers, shaving your beard by chewing it off.
BASH et al, certainly has it's place, but considering the article is about BASH 4.0, even the people who originally developed this wheel, thought it wasn't good enough as is.
** is very interesting. mplayer **/*.mp3 for example =) This might not be useful in scripts though
PS. I'm assuming that ** works like it does in zsh because I haven't RTFA
Because the CLI ought to be a DRM-friendly environment!
Then again even Apple is busy removing DRM from iTMS, so perhaps the BSD folk are just wasting their time.
If by "the kind of person I was referring to", you mean, one of many millions of competent Unix users out there, then I suppose I am.
Will this major release affect my productivity directly? Probably not, (although I daresay "improvements to the programmable completion functionality" will be a welcome feature) however, to suggest that bash scripting is merely some bygone vestige of a time where people didn't have "serious" languages work with just shows how far outside your comfort zone you stray when actually considering these things.
Bash is core to almost all the major Linux distributions out there (in the sense that it is the default shell). It is a serious technology indeed, just as relevant today as it ever was. A major release is not only worthy of the Slashdot front page, but I'd be disappointed if I hadn't heard it here first.
You feel sleepy. Close your eyes. The opinions stated above are yours. You cannot imagine why you ever felt otherwise.
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"!
#DeleteChrome
I was really hoping someone would post a picture of a half-rotated Compiz cube with a bash shell running transparently on it.
Just find any random old youtube video of people showing off Compiz. Superimpose an xterm with alpha=0%, and there's your transparent bash shell ;-)
You honestly think there are millions of people out there whose primary user interface is a shell command line? You need to get out more!
Like the way Red Hat uses nash?
"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."
a Windows or OSX dig would have been nice. ;-)
Quack, quack.
Primary no, but like it or not, it an absolutely necessary part of any Linux user's skill set.
Is there a single Linux (or Unix) user without some knowledge of bash? For many, it is almost synonymous with Linux, it has to be one of the most pervasive pieces of software out there.
You feel sleepy. Close your eyes. The opinions stated above are yours. You cannot imagine why you ever felt otherwise.
Should I upgrade or grab another fire extinguisher?
it's getting kind of smoggy here! /nervously waiting for reply/
wikipedia says: Debian Almquist shell
sigh, I was really hoping they had called it the Deade Again SHell
The creator of this post (Jacob Smith) hereby releases it, and all of his other posts, into the public domain.
"... Err, what? Shell scripts are used all the time. Even upstart services are still often written as shell scripts. Really, why all the anti-shell hostility around here?"
Err... did I say nothing against shell scripts, uh?
I talked about *Bash* scripts. Init scripts should be standard shell, not Bash, as per the single unix specification. Any init script using Bash should be considered a bug but for very few exceptions.
Oh! and by the way... *All* "upstart services" must be written as shell scripts, not just "oftenly".
and has been for a long time now. It's an OS that caters to the high end of the technical skill bell curve.
As the island of our knowledge grows, so does the shore of our ignorance.
Yeah, but Gentoo bash has funroll loops built-in!
Yeah right. I've worked at a few places where /bin/sh was the strict standard. And guess what, every one of the "serious" scripts I saw were liberally peppered with invocations of sed & awk to get anything "serious" done, because /bin/sh is so devoid of useful builtins. In all cases the use of awk for example was an unholy mess, and anyway, writing scripts like that breaks the golden rule for writing fast scripts: i.e. stick to using buildins as much as possible to keep the number of context switches down to a minimum.
If anyone wants to do "serious" scripting, then they should pick the right tool for the job, and /bin/sh just doesn't cut it.
I know you didn't mean to but could you please not use nabble links. Please try and find the original mailing list rather then those content stealing assholes.
For whatever reason, I've been a diehard tcsh user for the last 15 years. It's clear that bash is the standard, and where all the development effort is going (at least relative to csh/tcsh).
Sometimes it feels like I'm the only tcsh user left.
A government is a body of people notably ungoverned - AC
No way, GIMP is by far the worse program name.
Is there a single Linux (or Unix) user without some knowledge of bash?
So what? Users with "some knowledge" won't ever use these fancy new Bash 4.0 features. They don't even know how to use more basic stuff, like pipes and filters.
If you use vi key bindings (set -o vi), then ESC v will launch vi (or whatever your EDITOR variable is set to) to edit you current command line. This is useful if the command line gets really long. Navigating single long line in VIM (with gj and gk) is much faster.
As the island of our knowledge grows, so does the shore of our ignorance.
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.
linux should find some way to do "looping GUI" actions easily.....
linux is good for "farms" coz it's easy to do "looping" job
windoz is good for "dumbs" coz it's easy to point-n-click
so for "dumb farms" u need "looping GUI"....
Haha, I've done things like the mplayer example as
ls */ | sed 's/^\1$/mplayer \1*.mp3/' | sh
This is because I'm a noob that knows very few GNU commands, but enough to be hazardous.
On the other hand, on Ubuntu, I only see three "Bourne-Again shell script text executable" files in /etc/init.d. The rest are all (or claim to be) "POSIX shell script text executable". Of course, that really only means that they start with "#!/bin/sh" instead of "#!/bin/bash", but Ubuntu is derived from Debian which has fairly strong policies about not allowing bashisms in /bin/sh scripts.
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.
Baselayout2 uses openrc which is written in C. (damn, it even rhymes!)
OpenRC is C, Baselayout 2 is bash.
They work together.
Check under /lib64/rc/sh/
This thread is giving me a rash.
I believe both recursive globbing "**" and coroutines are zsh features.
I'm glad they included this. I think it's fair to say that lack of recursive globbing support was pretty annoying in the past. Using a command composed with find composed with xargs was the previous alternative... and pretty over complicated compared to **.
In the past I'd switched to zsh, but moved back because most shell scripting information online is built around bash. This makes sticking with bash that much easier.
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
No, it would be "weird" if they moved from bash to python for the same reason.
Is that the new Zune?
Have you even seen Monowall? To quote from its website:
m0n0wall is probably the first UNIX system that has its boot-time configuration done with PHP, rather than the usual shell scripts, and that has the entire system configuration stored in XML format.
Monowal is actually rather nice.
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
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.
Power does not corrupt - power attracts the corrupt.
I am still waiting for a standard command line syntax for every command, standard command naming convention for commands, standard config file format in /etc, standard output, object piping... oh well, this just looks like powershell... damn! Is there a project trying to bring sanity to this mess?
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.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
"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.
I'm aware of a not-obscure high-volume website (yes, porn; no, not telling which) running on nothing but shell scripts. No other language needed.
Not sure why, but the site is very fast and scales exceptionally well. It even does database access (don't know which db, I'm not a developer at that site).
So is bash still the only shell getting pipes wrong.
In all other shells, the last part of the pipe is in the current process.
In bash, the first part of a pipe is, which is completely useless. If it's the last one, you can effectively modify variables and use them later.
e.g.:
ls | while read a
do
myls="$myls $a"
done
echo $myls
ok, it's a silly example but what would you expect happens by just quickly looking at the code. The echo shows the ls? Well not in bash, it just is empty!
But the bash people still ignore this bug, because in POSIX it is not clear which part of the pipe is in the current process. Well why don't they do it like all the others?
Atari rules... ermm... ruled.
Just build the binary and install it as /bin/bash-4.0 or bash4, and you can use the new version, while your scripts don't break. If you want to start testing, try running some of your scripts under the new version. When you are more confident, you can symlink /bin/sh to your new bash4.
Many binaries use this type of protocol: gimp, gcc, and several others. It allows you to use multiple versions at once, if you wish. The default one is just a symbolic link from say gimp to gimp-2.4 -- Simple. Effective. Easy.
Really, why all the anti-shell hostility around here?
Ignorance, basically.
man gay
Great update.
For me, standards across all the *nix flavours is key so I probably won't use associated arrays in a shell script. Can't help but like them though.
Love that we finally have co-processes, hate that the syntax is completely non-standard.
Great to see bash updated though.
I did a wubi install of ubuntu on my laptop, and it installed and ran ok
and...
incredible - all these volunteers have produced a great OS/desktop that installed nearly flawlessly
or
so what - it is the same as windows, so why should I care ?
which is the problem: if windows is your target, who cares if you are equal or even slighlty better.
And stay away from any living cells! (think about it...)
You can lead a horse to water, but you can't make it dissolve.
Are you specifically referring to the stagnant vi, or the class of vi editors (most notably vim)? If the former, yeah, sure whatever. If the latter, stop flaimbaiting. Just as csh users almost universally use tcsh (which is fine unless you're scripting), vi users almost universally use improved versions of vi like vim or elvis. The scripting argument is moot. You can find vim gurus that completely pwn emacs experts at efficient coding with their editor in the same way that you can find emacs gurus that wreck vim experts. It's pretty even, and there is no clear winner.
vim and emacs are in a league all their own, and others such as joe, kate, and bbedit aren't too far behind (some landing far closer than others). See Wikipedia's comparison of text editors for detail on what you're missing.
Gentoo stable requires bash for baselayout-1 /bin/sh for OpenRC
Gentoo unstable uses
I know - I wrote OpenRC and maintained baselayout-1 for a long time :)
For pure startup, busybox sh is the fastest, followed by dash followed by bash.
busybox is fastest purely because it doesn't fork as much due to the apps builtin. Plus the apps in question generally have much shorter code-paths due to many GNU extensions being stripped.
I didn't test zsh or pdksh for speed.
Its the bloody default shell. I can't stand it - why can't they use bash or just plain bourne shell FFS?
It's no fun if you get all rational about it. Nobody actually gives a flipping fuck what text editor you use. This argument is ritual by now and here for everyone's continued enjoyment.
When invoked as sh (i.e. in sh-compatibility mode), how does the following display?
$ echo "hello\n"
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
WHAT?!! If they aren't aware of their OS and its inner workings, then how are they going to edit their config files? It's not a true computer, or a true operating system, if you don't have to edit config files from the command line! This whole idea makes no sense to me!
Beware of bugs in the above code; I have only proved it correct, not tried it.
Bash is GPL, which is not compatible with the BSD license. The standard response is to use zsh, which is more powerful than bash, insanely featureful, and BSD-licensed. I'm not a BSD user, but zsh is now my shell of choice. These days, the differences are so minor that it doesn't matter. The only big-deal feature in zsh but not bash that I can think of is RPROMPT and maybe the better completion. (See the screenshot of my power-tweaked zsh shell.)
I was under the impression the BSDs used zsh as the default shell. Maybe that's NetBSD?
Use my userscript to add story images to Slashdot. There's no going back.
Not bad for a first attempt, but you need to start a bit more gently to draw them in before you lay in with the hard stuff.
$ sudo apt-get install ipython
$ ipython -p pysh
You can make an alias or a (cue drum roll) shell script with that last command. The nice thing about pysh is that it has prevented me from learning to do anything complex in bash. I'm a slacker.
But... the future refused to change.
I get worried when a lowish UID person on slashdot is so blase about the commandline. I own a mac and I do most of the file stuff in the command line. On my work machine, I don't even have a GUI file browser installed. When you are handling lots of files, nothing else really makes sense, unless you are doing something common enough to have been GUIfied, like MP3 or photo management.
I have tried many times to use file managers, but I always feel like my hands are chopped off when I try to do even basic stuff like 'move all the PDFs in directory A to directory B', or 'find all the files in my Documents folder that are newer than File A'. Probably the only place where a graphical interface contributes is if the files have a reasonable graphical interpretation and are not named consistently, like a random dump of images from someone's flash disk.
Languages aren't inherently fast -- implementations are efficient
It's even worse than you think! Not only do I have a low UID, but I've actually been using computers for a really really long time. I started in 1971 (PDP-11 running RSTS), didn't even see a GUI machine until 1983 (when the company I was working for bought a Mac to do competitive analysis on it), and didn't start using one day-to-day until 1990 (when Windows 3.0 came out). Even then, it was some years before Windows file managers progressed enough to that I could use them for most complicated operations.
That's over a decade when I used various command lines (mostly csh until I became a MS-DOS person, when I relied on something called 4DOS) because there was no alternative. Than some years before the alternatives got good enough so that I could rely on them most of the time. I got pretty good at hacking shell scripts and aliases.
I still am, though certainly not in your league. Nowadays I go back and forth between Solaris and Windows, and on the Solaris side there's still a lot of things that are easier to do in the command line.
So, with all this command line experience, why am I a GUI apostate? Because it suits the way I think better. Visual metaphors means that I don't have to devote brain cells to remembering and elaborating the idiom I need. Visual feedback tells me immediately whether the idiom I used did what I thought it did.
You see these mechanisms as crutches and that interfere with your ability to work efficiently, and prefer more powerful tools. If that works for you fine. Despite the way most people read my original post, I am not saying that only idiots use the command line. Though I strongly suspect that a powerful command line appeals to you more for the intellectual stimulation and pleasure you get from using it, rather than any increase in your efficiency.
Comment removed based on user account deletion
Comment removed based on user account deletion
Comment removed based on user account deletion
Comment removed based on user account deletion
Comment removed based on user account deletion