| |||||||||||||
Bash 4.0 released
The bash 4.0
release is available. "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."
(Log in to post comments)
Bash 4.0 released Posted Feb 23, 2009 20:35 UTC (Mon) by muwlgr (guest, #35359) [Link]
What about its performance and resource consumption ?
Has it gone the bloat way of glibc and coreutils ?
Bash 4.0 released Posted Feb 23, 2009 22:40 UTC (Mon) by nix (subscriber, #2304) [Link]
I challenge you to provide evidence that coreutils is bloated.
Bash 4.0 released Posted Feb 23, 2009 23:15 UTC (Mon) by jengelh (subscriber, #33263) [Link] -rwxr-xr-x 1 root root 100556 2009-02-17 17:35 /bin/ls -rwxr-xr-x 1 root root 88104 2009-02-17 17:35 /bin/cp
Bash 4.0 released Posted Feb 23, 2009 23:52 UTC (Mon) by nix (subscriber, #2304) [Link]
Er, you do realise that a lot of, say, the ls(1) binary isn't paged in
unless you use the particular features in question, right? Further, not all extra code is necessarily bloat anyway (e.g. recent changes to find make it quite a bit bigger... and speed it up by perhaps an order of magnitude in some fairly common cases.)
Further than that, simple changes in CPUs account for a lot of
You need a lot more analysis than a simple ls of the binary (not even a
The binary size you get also depends on the capabilities of the system
ls itself (the actual binary includes pieces of gnulib, too):
4569 16762 126726 coreutils-7.0/src/ls.c
Bloat? Maybe, maybe not. Certainly it's larger than V7 ls.c. Certainly it
Bash 4.0 released Posted Feb 24, 2009 20:48 UTC (Tue) by oak (subscriber, #2786) [Link]
Utilities in Busybox[1] typically increase its size by <2KB (they are all
linked to same binary). Yes, they dispend with "redundant" error handling, lack (mostly non-POSIX) features, don't tell when/which features aren't configured in (the corresponding options just don't work) and have now and then strange bugs, but they are definitely smaller. People doing embedded Linux work typically have a bit of a love/hate relation with Busybox...
Bash 4.0 released Posted Feb 25, 2009 11:46 UTC (Wed) by jpetso (guest, #36230) [Link]
"Bloat" is increased size or less performance for features that are not useful or even
wanted. "Bloat" is not increased size or less performance per se. There also haven't been any statements that coreutils does a bad job in performance.
So what, useful features in trade for more disk space? Hell yeah, hand me a copy of
Next time someone shouts "bloat", please give an explanation for the "what is actually
Nifty Posted Feb 23, 2009 20:43 UTC (Mon) by quotemstr (subscriber, #45331) [Link]
It looks like quite a bit of new functionality has been included in this release. And here I was thinking the shell world was dead.
Nifty Posted Feb 23, 2009 22:41 UTC (Mon) by nix (subscriber, #2304) [Link]
A lot of it is, uh, inspired by zsh: ** for instance.
Bash 4.0 released Posted Feb 23, 2009 21:40 UTC (Mon) by madscientist (subscriber, #16861) [Link]
I don't begrudge anyone increasing functionality for their shell, and I've been using bash for longer than Linux has even been around and I love it to death, but I shudder to imagine all the new scripts that will be written and distributed that require bash in ever more complex ways... and will invariably say "#!/bin/sh" at the top and fail to work on many Linux systems and any other UNIX system... for no particularly good reason except "all the shell's a bash, right?"
Hopefully not for very long Posted Feb 23, 2009 22:39 UTC (Mon) by khim (subscriber, #9252) [Link] /bin/sh is not longer bash in Ubuntu (and Debian in some uncertain future) so such scripts will not work there - and Ubuntu is quite popular. I hope other distributions will follow and stop using bash as /bin/sh - it'll close this "problem" once and for all...
Hopefully not for very long Posted Feb 25, 2009 10:28 UTC (Wed) by nlucas (subscriber, #33793) [Link]
True, but that doesn't solve the problem of many scripts assuming bash is "/bin/sh".
I end to "dpkg-divert" to "/usr/bin/bash" because it's easier than fixing all the scripts that cease to work. Even if that makes booting even longer (one of the arguments, iirc, was that dash cuts booting times by several seconds).
Hopefully not for very long Posted Feb 25, 2009 19:42 UTC (Wed) by man_ls (subscriber, #15091) [Link] I always start my custom scripts by "#!/bin/bash". Not that I use any machine where it will actually matter (except at work on braindead AIX installations), but if it will change on Debian as you say it is nice to know that it will fail instead of work in weird ways.Someone should start a campaign for "#!/bin/bash".
Bash 4.0 released Posted Feb 23, 2009 23:23 UTC (Mon) by salimma (subscriber, #34460) [Link]
#!/bin/sh really ought to be Bash in reduced functionality mode -- i.e. it should emulate the behavior of the original sh.
It'd be really nice if #!/bin/bash-4 runs Bash in version 4 mode, wheras #!/bin/bash-3 would turn off the version 4 features. A poor man's versioned interface. If bash itself does not do it, then distributors can emulate it by shipping two versions of Bash as bash-3 and bash-4 respectively.
Bash 4.0 released Posted Feb 24, 2009 20:09 UTC (Tue) by felixfix (subscriber, #242) [Link]
Bash behaves differently when run as sh instead of bash, I think restricting itself to POSIX compatibility, but it's been a long time since this mattered to me in my job. so I could be wrong and/or out of date.
Bash 4.0 released Posted Mar 6, 2009 16:57 UTC (Fri) by Duncan (guest, #6647) [Link]
Yes, bash behaves differently when run as sh, but sh purists, particularly
those in the BSD and Linux embedded camps that don't necessarily have bash installed let alone as sh, tend to have a rather long list of how buggy bash is at actually enforcing POSIX sh mode, based on the number of scripts they've had to deal with that were designed and tested only with bash in sh mode, not on a real POSIX sh that actually enforces the standard.
Thus the original comment...
(Said as one that always uses the #!/bin/bash myself, as I make no
Duncan
Bash 4.0 released Posted Feb 24, 2009 0:28 UTC (Tue) by sayler (guest, #3164) [Link]
Coprocesses and ** both look like nice features for q-and-d scripting and command-line use. Looking forward to it.
Bash 4.0 released Posted Feb 24, 2009 0:49 UTC (Tue) by nix (subscriber, #2304) [Link]
Is there anything in ksh that bash doesn't implement now it has
coprocesses, I wonder?
Bash 4.0 released Posted Feb 25, 2009 2:33 UTC (Wed) by clint (subscriber, #7076) [Link]
Does it have compound variables, floating point arithmetic, and discipline funcitons?
Bash 4.0 released Posted Feb 24, 2009 7:50 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
Well, I'm waiting till someone ports PowerShell from Windows to Linux :) It's really the next generation of shells.
Bash 4.0 released Posted Feb 24, 2009 9:45 UTC (Tue) by tzafrir (subscriber, #11501) [Link]
Power shell deals with objects whereas the unix shell pipes texts. Quite not the same thing. To change that you'll also have to make all of your programs emit objects rather than text. The idea might have merits, but certainly it's such a big change that will break too many things.
If you want something similar, look for perl-shell, python-shell or ruby-shell.
Re: PowerShell Posted Feb 24, 2009 17:01 UTC (Tue) by larryr (guest, #4030) [Link] PowerShell may be the next generation of shells, but I hope not. For me the most valuable thing about using the unix command line tools is that they are constrained to produce and consume a very limited set of very simple, very consistent, and very structured text output/input. Larry
Object-based shell for Linux and friends Posted Feb 24, 2009 22:39 UTC (Tue) by MarkWilliamson (guest, #30166) [Link]
You ask, the internet (and the Free Software community) delivers ;-)
OK, so it's not the same as the Windows PowerShell. Still, seems to have some similar
Cheers,
|
|||||||||||||