Bash 5.0 released
The most notable new features are several new shell variables: BASH_ARGV0, EPOCHSECONDS, and EPOCHREALTIME. The `history' builtin can remove ranges of history entries and understands negative arguments as offsets from the end of the history list. There is an option to allow local variables to inherit the value of a variable with the same name at a preceding scope. There is a new shell option that, when enabled, causes the shell to attempt to expand associative array subscripts only once (this is an issue when they are used in arithmetic expressions). The `globasciiranges' shell option is now enabled by default; it can be set to off by default at configuration time."
| From: | Chet Ramey <chet.ramey-AT-case.edu> | |
| To: | bug-bash-AT-gnu.org, gnu-announce-AT-gnu.org, bash-announce-AT-gnu.org, help-bash-AT-gnu.org | |
| Subject: | Bash-5.0 release available | |
| Date: | Mon, 7 Jan 2019 17:03:32 -0500 | |
| Message-ID: | <190107220332.AA15051.SM__44321.2129561745$1546899433$gmane$org@caleb.ins.cwru.edu> | |
| Cc: | coordinator-AT-translationproject.org, chet.ramey-AT-case.edu | |
| Archive-link: | Article |
Introduction ============ The first public release of bash-5.0 is now available with the URLs ftp://ftp.cwru.edu/pub/bash/bash-5.0.tar.gz ftp://ftp.gnu.org/pub/gnu/bash/bash-5.0.tar.gz and from the master branch of the bash git repository (http://git.savannah.gnu.org/cgit/bash.git/log/) and the usual GNU mirror sites. Bash is the GNU Project's Bourne Again SHell, a complete implementation of the POSIX 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. This tar file includes the formatted documentation (pdf, postscript, dvi, info, and html, plus nroffed versions of the manual pages). Please use `bashbug' to report bugs with this version. It is built and installed at the same time as bash. Installation ============ Please read the README file first. Installation instructions are provided in the INSTALL file. New Features ============ This is the fifth major release of bash. Read the file NEWS in the bash-5.0 distribution for a complete description of the new features. A copy of the relevant portions is included below. This release fixes several outstanding bugs in bash-4.4 and introduces several new features. The most significant bug fixes are an overhaul of how nameref variables resolve and a number of potential out-of-bounds memory errors discovered via fuzzing. There are a number of changes to the expansion of $@ and $* in various contexts where word splitting is not performed to conform to a Posix standard interpretation, and additional changes to resolve corner cases for Posix conformance. The most notable new features are several new shell variables: BASH_ARGV0, EPOCHSECONDS, and EPOCHREALTIME. The `history' builtin can remove ranges of history entries and understands negative arguments as offsets from the end of the history list. There is an option to allow local variables to inherit the value of a variable with the same name at a preceding scope. There is a new shell option that, when enabled, causes the shell to attempt to expand associative array subscripts only once (this is an issue when they are used in arithmetic expressions). The `globasciiranges' shell option is now enabled by default; it can be set to off by default at configuration time. There are a few incompatible changes between bash-4.4 and bash-5.0. The changes to how nameref variables are resolved means that some uses of namerefs will behave differently, though I have tried to minimize the compatibility issues. By default, the shell only sets BASH_ARGC and BASH_ARGV at startup if extended debugging mode is enabled; it was an oversight that it was set unconditionally and caused performance issues when scripts were passed large numbers of arguments. Bash can be linked against an already-installed Readline library rather than the private version in lib/readline if desired. Only readline-8.0 and later versions are able to provide all of the symbols that bash-5.0 requires; earlier versions of the Readline library will not work correctly. A complete list of changes between bash-4.4 and bash-5.0 is available in the file CHANGES; the complete list is too large to include in this message. Readline ======== Also available is a new release of the standalone Readline library, version 8.0, with its own configuration scripts and Makefiles. It can be retrieved with the URLs ftp://ftp.cwru.edu/pub/bash/readline-8.0.tar.gz ftp://ftp.gnu.org/pub/gnu/readline/readline-8.0.tar.gz and from the master branch of the GNU readline git repository (http://git.savannah.gnu.org/cgit/readline.git/log/) and the usual GNU mirror sites. The formatted Readline documentation is included in the readline distribution tar file. A separate announcement listing the changes in Readline is being distributed. As always, thanks for your help. Chet +========== NEWS ==========+ This is a terse description of the new features added to bash-5.0 since the release of bash-4.4. As always, the manual page (doc/bash.1) is the place to look for complete descriptions. 1. New Features in Bash a. The `wait' builtin can now wait for the last process substitution created. b. There is an EPOCHSECONDS variable, which expands to the time in seconds since the Unix epoch. c. There is an EPOCHREALTIME variable, which expands to the time in seconds since the Unix epoch with microsecond granularity. d. New loadable builtins: rm, stat, fdflags. e. BASH_ARGV0: a new variable that expands to $0 and sets $0 on assignment. f. When supplied a numeric argument, the shell-expand-line bindable readline command does not perform quote removal and suppresses command and process substitution. g. `history -d' understands negative arguments: negative arguments offset from the end of the history list. h. The `name' argument to the `coproc' reserved word now undergoes word expansion, so unique coprocs can be created in loops. i. A nameref name resolution loop in a function now resolves to a variable by that name in the global scope. j. The `wait' builtin now has a `-f' option, which signfies to wait until the specified job or process terminates, instead of waiting until it changes state. k. There is a define in config-top.h that allows the shell to use a static value for $PATH, overriding whatever is in the environment at startup, for use by the restricted shell. l. Process substitution does not inherit the `v' option, like command substitution. m. If a non-interactive shell with job control enabled detects that a foreground job died due to SIGINT, it acts as if it received the SIGINT. n. The SIGCHLD trap is run once for each exiting child process even if job control is not enabled when the shell is in Posix mode. o. A new shopt option: localvar_inherit; if set, a local variable inherits the value of a variable with the same name at the nearest preceding scope. p. `bind -r' now checks whether a key sequence is bound before binding it to NULL, to avoid creating keymaps for a multi-key sequence. q. A numeric argument to the line editing `operate-and-get-next' command specifies which history entry to use. r. The positional parameters are now assigned before running the shell startup files, so startup files can use $@. s. There is a compile-time option that forces the shell to disable the check for an inherited OLDPWD being a directory. t. The `history' builtin can now delete ranges of history entries using `-d start-end'. u. The `vi-edit-and-execute-command' bindable readline command now puts readline back in vi insertion mode after executing commands from the edited file. v. The command completion code now matches aliases and shell function names case-insensitively if the readline completion-ignore-case variable is set. w. There is a new `assoc_expand_once' shell option that attempts to expand associative array subscripts only once. x. The shell only sets up BASH_ARGV and BASH_ARGC at startup if extended debugging mode is active. The old behavior of unconditionally setting them is available as part of the shell compatibility options. y. The `umask' builtin now allows modes and masks greater than octal 777. z. The `times' builtin now honors the current locale when printing a decimal point. aa. There is a new (disabled by default, undocumented) shell option to enable and disable sending history to syslog at runtime. bb. Bash no longer allows variable assignments preceding a special builtin that changes variable attributes to propagate back to the calling environment unless the compatibility level is 44 or lower. cc. You can set the default value for $HISTSIZE at build time in config-top.h. dd. The `complete' builtin now accepts a -I option that applies the completion to the initial word on the line. ee. The internal bash malloc now uses mmap (if available) to satisfy requests greater than 128K bytes, so free can use mfree to return the pages to the kernel. ff. The shell doesn't automatically set BASH_ARGC and BASH_ARGV at startup unless it's in debugging mode, as the documentation has always said, but will dynamically create them if a script references them at the top level without having enabled debugging mode. gg. The localvar_inherit option will not attempt to inherit a value from a variable of an incompatible type (indexed vs. associative arrays, for example). hh. The `globasciiranges' option is now enabled by default; it can be set to off by default at configuration time. ii. Associative and indexed arrays now allow subscripts consisting solely of whitespace. jj. `checkwinsize' is now enabled by default. kk. The `localvar_unset' shopt option is now visible and documented. ll. The `progcomp_alias' shopt option is now visible and documented. mm. The signal name processing code now understands `SIGRTMIN+n' all the way up to SIGRTMAX. nn. There is a new `seq' loadable builtin. oo. Trap execution now honors the (internal) max invocations of `eval', since traps are supposed to be executed as if using `eval'. pp. The $_ variable doesn't change when the shell executes a command that forks. qq. The `kill' builtin now supports -sSIGNAME and -nSIGNUM, even though conforming applications aren't supposed to use them. rr. POSIX mode now enables the `shift_verbose' option. 2. New Features in Readline a. Non-incremental vi-mode search (`N', `n') can search for a shell pattern, as Posix specifies (uses fnmatch(3) if available). b. There are new `next-screen-line' and `previous-screen-line' bindable commands, which move the cursor to the same column in the next, or previous, physical line, respectively. c. There are default key bindings for control-arrow-key key combinations. d. A negative argument (-N) to `quoted-insert' means to insert the next N characters using quoted-insert. e. New public function: rl_check_signals(), which allows applications to respond to signals that readline catches while waiting for input using a custom read function. f. There is new support for conditionally testing the readline version in an inputrc file, with a full set of arithmetic comparison operators available. g. There is a simple variable comparison facility available for use within an inputrc file. Allowable operators are equality and inequality; string variables may be compared to a value; boolean variables must be compared to either `on' or `off'; variable names are separated from the operator by whitespace. h. The history expansion library now understands command and process substitution and extended globbing and allows them to appear anywhere in a word. i. The history library has a new variable that allows applications to set the initial quoting state, so quoting state can be inherited from a previous line. j. Readline now allows application-defined keymap names; there is a new public function, rl_set_keymap_name(), to do that. k. The "Insert" keypad key, if available, now puts readline into overwrite mode. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet@case.edu http://tiswww.cwru.edu/~chet/ -- If you have a working or partly working program that you'd like to offer to the GNU project as a GNU package, see https://www.gnu.org/help/evaluation.html.
Posted Jan 8, 2019 22:50 UTC (Tue)
by NightMonkey (subscriber, #23051)
[Link] (3 responses)
Posted Jan 9, 2019 4:29 UTC (Wed)
by wahern (subscriber, #37304)
[Link] (2 responses)
Posted Jan 9, 2019 5:13 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (37 responses)
These guys SERIOUSLY need to change something in their development model. Just look at their git: http://git.savannah.gnu.org/cgit/bash.git/log/
Posted Jan 9, 2019 7:59 UTC (Wed)
by sytoka (guest, #38525)
[Link]
Posted Jan 9, 2019 9:11 UTC (Wed)
by XTerminator (subscriber, #59581)
[Link] (35 responses)
Posted Jan 9, 2019 9:49 UTC (Wed)
by zdzichu (guest, #17118)
[Link] (4 responses)
As for being constructive: there are number of “good commit messages” guides (random searches: https://medium.com/compass-true-north/writing-good-commit... https://code.likeagirl.io/useful-tips-for-writing-better-...). Adopting *any* of the guidelines would increase quality of Bash repo.
Posted Jan 9, 2019 9:52 UTC (Wed)
by XTerminator (subscriber, #59581)
[Link]
Posted Jan 9, 2019 16:46 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (1 responses)
My reading of this is maybe it's just simpler to look at the patch and it's documented there - although I will admit that that's a pain when you're trying to find which patch did something.
For a sole developer - seeing as all the commits were Chet - this doesn't seem to me at all unreasonable. Unless of course Cyberax knows more than me, he certainly seems to think there's more than one person maintaining bash ("these guys" - plural) - actually I'd be surprised ...
Cheers,
Posted Jan 10, 2019 17:52 UTC (Thu)
by smurf (subscriber, #17840)
[Link]
Yeah, Chet seems to be the sole developer. And with good reason. With that kind of commit history I wouldn't even dream of helping with bash development. I also wouldn't help with security-or-whatever audits – this would be plenty reason to switch to a different shell, except for the fact that Debian's default shell is dash. :-P
No, being a single developer is not an excuse for shoddy commit management. How do you find regressions in that kind of mess??
Posted Jan 9, 2019 17:35 UTC (Wed)
by sb (subscriber, #191)
[Link]
Posted Jan 9, 2019 9:51 UTC (Wed)
by lobachevsky (subscriber, #121871)
[Link]
Posted Jan 9, 2019 9:53 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (28 responses)
Compare this to zsh: https://sourceforge.net/p/zsh/code/commit_browser
Posted Jan 9, 2019 23:15 UTC (Wed)
by flussence (guest, #85566)
[Link] (27 responses)
If I'd been productive in a tarball+email workflow for 30 years and some slashdot/hn armchair developers showed up calling me out for not using their pet VCS, I'd be inclined to flash them a bit of malicious compliance too.
Posted Jan 10, 2019 2:40 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (26 responses)
Patch + email workflow is compatible with multiple VCSes, starting from the venerable CVS. It can certainly be done with SVN, Mercurial and pretty much anything else more advanced than Microsoft SourceSafe.
Not maintaining usable history for a project like bash is bordering on insanity and criminal negligence these days.
Posted Jan 10, 2019 14:29 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (25 responses)
This is why so many critical infrastructure programs are poorly maintained! How many developers does bash have!?
If it's just Chet, he has every right to do it however it suits him. If you want to call best efforts "criminal negligence" that says more about you than him! There's plenty of "best practice" that I completely ignore because I don't have a 48hr day to do it in ...
Cheers,
Posted Jan 10, 2019 17:56 UTC (Thu)
by smurf (subscriber, #17840)
[Link] (5 responses)
Also, bash is security+mission critical software, if only by virtue of being the default login shell. While you don't exactly *need* a sensible change history for auditing the code, it'd make the job an order of magnitude easier.
Posted Jan 12, 2019 4:53 UTC (Sat)
by rra (subscriber, #99804)
[Link] (4 responses)
Hmmm. I wonder if Chet is getting a paycheck proportionate to maintaining security and mission-critical software for the entire Internet. Or ever indicated any desire to be in that role or ever agreed to shoulder the responsibility for that. Or, in the absence of such a paycheck and agreement, why anyone should expect any particular workflow from him.
We certainly have a much larger problem here, namely that people have built critical infrastructure on top of free software without ever figuring out how to make this process rewarding, comfortable, and supportive for the people maintaining that free software. But then turning around and blaming them for not maintaining that software to the standards desired this critical infrastructure they were never involved in, never approved, aren't being paid for, and that never considered their feelings at all doesn't sit well with me.
Posted Jan 12, 2019 14:43 UTC (Sat)
by smurf (subscriber, #17840)
[Link] (3 responses)
Chet may or may not want that responsibilty – but the fact is, he does have it. If he doesn't want it, then inviting collaborators and setting up a decent auditable workflow would seem to be a good idea. If he does, well, setting up a decent auditable workflow still is a good idea. We all make mistakes, and bash isn't exactly a simple program.
Posted Jan 12, 2019 15:29 UTC (Sat)
by pizza (subscriber, #46)
[Link]
Posted Jan 12, 2019 18:43 UTC (Sat)
by farnz (subscriber, #17727)
[Link] (1 responses)
Why should Chet change a workflow that works for him just because other people have started to depend on his work without doing sufficient due diligence to ensure that what he's doing fits theit needs? Instead, why don't people who don't want to depend on Chet's workflow switch to one of dash, zsh or ksh (to name three Bourne shells that aren't bash). Alternatively, why don't people who care fork bash and work on it in ways that they think are better?
Basically, why should Chet be expected to change because other people like his work? Why can't his work be allowed to fade into historical obscurity?
Posted Jan 14, 2019 12:09 UTC (Mon)
by Wol (subscriber, #4433)
[Link]
Or, if people really do want to depend on his work, why can't they start paying him to do it!!!
I'm probably as much the cheapskate as anyone else, but I do try and give back in kind. If you're not prepared to "put your money where your mouth is" you have no right to moan, and if you are prepared then you probably have a far better view of the situation.
The reality is MUCH important software is in this sort of mess, because nobody is prepared to put their hand in their pocket. One piece of software I use has a sole dedicated developer, who is struggling to make ends meet and is also fighting illness. How's that fair? He's doing his best to support Free Software and not doing very well out of it ...
Cheers,
Posted Jan 11, 2019 14:44 UTC (Fri)
by rleigh (guest, #14622)
[Link] (18 responses)
Posted Jan 14, 2019 12:14 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (17 responses)
What value is that? Not what value do YOU place on it, but what value does CHET place on it.
You can't base your argument on your values. I regularly get peed of by BT adverts saying "we're sure you'll love our heavily discounted (yeah ...) SIMS at £10 each". That's if you buy 5 of them! I pay £9 for two sims, with more data, calls and texts than my wife and I ever use. £10/SIM may be great value from BT's point of view, but from mine it's a waste of money ...
Cheers,
Posted Jan 15, 2019 11:28 UTC (Tue)
by cagrazia (guest, #124754)
[Link] (15 responses)
Posted Jan 15, 2019 12:00 UTC (Tue)
by pizza (subscriber, #46)
[Link]
Yank bash, and a sizeable portion of the internet will break. It is "hobbyware" only in the sense that nobody other than its authors care about it sufficiently enough to meaningfully contribute to its upkeep.
Meanwhile, even "deprecating" bash requires a nontrivial amount ongoing effort that you're expecting "someone else" to do -- ie pay for.
Posted Jan 20, 2019 2:54 UTC (Sun)
by dualbus (guest, #129437)
[Link] (12 responses)
Posted Jan 20, 2019 3:30 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (11 responses)
It also increases the chances of the next MD_Update disaster.
Posted Jan 20, 2019 4:10 UTC (Sun)
by pizza (subscriber, #46)
[Link] (10 responses)
Meanwhile, this little statement is worth repeating:
"Bash is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of
Posted Jan 20, 2019 4:13 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (5 responses)
Posted Jan 20, 2019 13:30 UTC (Sun)
by pizza (subscriber, #46)
[Link] (4 responses)
If *I* am building infrastructure, then *I* will make plans to handle "unspecified stuff going wrong"
What I don't do is expect other folks to do any (additional) unpaid work on behalf of my infrastructure, and I certainly don't denigrate the folks whose work I am already taking advantage of -- because, speaking personally about the Free Software I have released, I'm far more inclined to promptly help out folks that are respectful of the work I have already done, acknowledge that I owe them nothing, and who have not been publicly badmouthing me.
Is *that* so difficult to understand?
Posted Jan 20, 2019 20:41 UTC (Sun)
by mjg59 (subscriber, #23239)
[Link] (3 responses)
1) Chet's work is a great gift to the free software community and we have benefited hugely from it over decades
2) Over that time we've learned that there are ways to maintain software that make it easier for others to consume that work, contribute code back and identify and fix issues. Now that we're aware that there are better ways to do it, we're also aware of the additional costs imposed on consumers by not having a fine grained revision history. Overall people still seem to feel that the benefits provided by bash outweigh the drawbacks, but if it /were/ possible to convince Chet to change the way bash is maintained, life would still be better.
Posted Jan 20, 2019 22:30 UTC (Sun)
by pizza (subscriber, #46)
[Link]
No argument from me there!
...but whether or not it is possible to convince him to change his ways, denigrating him and his work is not the way to accomplish it.
Posted Jan 21, 2019 2:29 UTC (Mon)
by pabs (subscriber, #43278)
[Link] (1 responses)
Posted Jan 21, 2019 6:32 UTC (Mon)
by dualbus (guest, #129437)
[Link]
And the only time I'm aware of it being brought up as a specific discussion topic is here: https://lists.gnu.org/archive/html/bug-bash/2015-03/msg00... (spoiler alert: I gave up really quickly on maintaining that mirror)
Posted Jan 20, 2019 11:13 UTC (Sun)
by smurf (subscriber, #17840)
[Link] (3 responses)
The code is, effectively, less auditable and thus less secure when all you see is a sequence of tarballs. Chet appears not to care about any of that. His choice – but it confirms the decision to switch away from Bash which some (most?) distributions took, years ago, for performance/memory usage reasons.
Posted Jan 20, 2019 13:43 UTC (Sun)
by pizza (subscriber, #46)
[Link] (2 responses)
If Bash's development practices are somehow unacceptable to you, there are three ways to proceed. Convince its author to do what you want, fork it and do a better job, or switch to something "better". Either way it's going to cost you time, effort, and a non-trivial amount of hard currency.
(And yes, some distributions have switched away from bash for system scripts, primarily for reasons that have since been rendered irrelevant by systemd...)
Posted Jan 20, 2019 20:48 UTC (Sun)
by smurf (subscriber, #17840)
[Link] (1 responses)
The difference is that most of these acknowledge that their code is used in security critical areas anyway, and have started to adapt their practices accordingly. Apparently, Chet has not. As I wrote, his choice, just as mine is to hack on any script I come across until it no longer says #!/bin/bash on top.
Posted Jan 21, 2019 6:40 UTC (Mon)
by dualbus (guest, #129437)
[Link]
What does git have to do with security? I read the weekly change sets when they're pushed, and I have no trouble understanding what's being changed or why. Sure, it might not be the commit /style/ you prefer, but has little to do with the quality of the software, or its security characteristics.
Also, perhaps ask Chet to provide more detailed / specific commits instead of just assuming he doesn't want to?
Posted Jan 20, 2019 13:27 UTC (Sun)
by flussence (guest, #85566)
[Link]
Posted Jan 18, 2019 15:21 UTC (Fri)
by rleigh (guest, #14622)
[Link]
The existing approach may work for the maintainer, and that's fair enough. It's his project. But, it does greatly reduce the utility of the project history both for himself and for anyone else who wants to work upon it. There are existing good practices for using version control, and this approach violates many of them.
Bash 5.0 released
Bash 5.0 released
Bash 5.0 released
Bash 5.0 released
What exactly are you talking about? Not possible to be constructive in your criticism?
Bash 5.0 released
Bash 5.0 released
Thanks for the explanation. :)
Bash 5.0 released
Bash 5.0 released
Wol
Bash 5.0 released
Bash 5.0 released
Bash 5.0 released
Bash 5.0 released
Bash 5.0 released
Bash 5.0 released
Pure BS.
Bash 5.0 released
Wol
Bash 5.0 released
Bash 5.0 released
Bash 5.0 released
Bash 5.0 released
Bash 5.0 released
Bash 5.0 released
Wol
Bash 5.0 released
Bash 5.0 released
Wol
Bash 5.0 released
Bash 5.0 released
Bash 5.0 released
Bash 5.0 released
Bash 5.0 released
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details."
Bash 5.0 released
Yes. If you're building public infrastructure then you MUST plan for the future. Is it that difficult to understand?
Bash 5.0 released
Bash 5.0 released
Bash 5.0 released
Bash 5.0 released
Bash 5.0 released
Bash 5.0 released
Bash 5.0 released
Bash 5.0 released
Bash 5.0 released
Bash 5.0 released
Appropriate use of version control
