|
|
Subscribe / Log in / New account

Bash 5.0 released

Version 5.0 of the Bash shell has been 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.


to post comments

Bash 5.0 released

Posted Jan 8, 2019 22:50 UTC (Tue) by NightMonkey (subscriber, #23051) [Link] (3 responses)

Like OpenSSL, I don't think these foundational F/OSS projects are getting the love they need and deserve. Thank you Chet and crew for continuing to develop Bash, where many of us system plumbers live and breathe. :)

Bash 5.0 released

Posted Jan 9, 2019 4:29 UTC (Wed) by wahern (subscriber, #37304) [Link] (2 responses)

Comparison to OpenSSL is apt considering feature 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."

Bash 5.0 released

Posted Jan 9, 2019 17:26 UTC (Wed) by k8to (guest, #15413) [Link] (1 responses)

Primarily I'm surprised by bash using its own malloc.

Bash 5.0 released

Posted Jan 9, 2019 22:37 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

Be thankful they've upgraded from sbrk.

Bash 5.0 released

Posted Jan 9, 2019 5:13 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (37 responses)

Ugh.

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/

Bash 5.0 released

Posted Jan 9, 2019 7:59 UTC (Wed) by sytoka (guest, #38525) [Link]

fork and extend ;-)

Bash 5.0 released

Posted Jan 9, 2019 9:11 UTC (Wed) by XTerminator (subscriber, #59581) [Link] (35 responses)

What exactly are you talking about? Not possible to be constructive in your criticism?

Bash 5.0 released

Posted Jan 9, 2019 9:49 UTC (Wed) by zdzichu (guest, #17118) [Link] (4 responses)

I gather it's rather obvious from looking at Cyberax' link. Commit messages in Bash repository are completely useless. They do not explain why the change is done (and what the change is about, which is often not clear), short messages do not convey any meaning and 5.0 commit was a big code drop of bundled unrelated changes.

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.

Bash 5.0 released

Posted Jan 9, 2019 9:52 UTC (Wed) by XTerminator (subscriber, #59581) [Link]

Thanks for the explanation. :)

Bash 5.0 released

Posted Jan 9, 2019 16:46 UTC (Wed) by Wol (subscriber, #4433) [Link] (1 responses)

On the other hand, all the changes were to tiny filesets apart from the last one. Plus the last one said DOCUMENTATION, implying it was NOT code.

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,
Wol

Bash 5.0 released

Posted Jan 10, 2019 17:52 UTC (Thu) by smurf (subscriber, #17840) [Link]

Huh? It says "Sources and documentation". Of course it's code. And translations. And libreadline. And every other friggin' thing that is mentioned in that announcement, plus very likely a bunch that are not.

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??

Bash 5.0 released

Posted Jan 9, 2019 17:35 UTC (Wed) by sb (subscriber, #191) [Link]

Just to point out that they do document their changes (see http://git.savannah.gnu.org/cgit/bash.git/tree/CWRU/chang...). They just don't seem to want to do it in the commit messages.

Bash 5.0 released

Posted Jan 9, 2019 9:51 UTC (Wed) by lobachevsky (subscriber, #121871) [Link]

Well, there are tiny commits with unhelpful commit messages that are the patch releases and gigantic squashed source dumps for the major releases; no history beyond that.

Bash 5.0 released

Posted Jan 9, 2019 9:53 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (28 responses)

Their git repo is basically just a list of tarball dumps. It's useless.

Compare this to zsh: https://sourceforge.net/p/zsh/code/commit_browser

Bash 5.0 released

Posted Jan 9, 2019 23:15 UTC (Wed) by flussence (guest, #85566) [Link] (27 responses)

This git repo likely only exists to shut up demands from non-participating trophy collectors who expect every line of code on the internet to be compatible with github's “import” button.

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.

Bash 5.0 released

Posted Jan 10, 2019 2:40 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (26 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.
Pure BS.

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.

Bash 5.0 released

Posted Jan 10, 2019 14:29 UTC (Thu) by Wol (subscriber, #4433) [Link] (25 responses)

> Not maintaining usable history for a project like bash is bordering on insanity and criminal negligence these days.

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,
Wol

Bash 5.0 released

Posted Jan 10, 2019 17:56 UTC (Thu) by smurf (subscriber, #17840) [Link] (5 responses)

This is not "best effort". Not by a very long shot. It's trivially easy to maintain a reasonable commit history.

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.

Bash 5.0 released

Posted Jan 12, 2019 4:53 UTC (Sat) by rra (subscriber, #99804) [Link] (4 responses)

> Also, bash is security+mission critical software

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.

Bash 5.0 released

Posted Jan 12, 2019 14:43 UTC (Sat) by smurf (subscriber, #17840) [Link] (3 responses)

I'm not blaming him. I'm saying that the practices of 20 years ago (a solo coder who periodically surfaces to release a tarball with the next version) do not make sense in today's world.

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.

Bash 5.0 released

Posted Jan 12, 2019 15:29 UTC (Sat) by pizza (subscriber, #46) [Link]

Yes, today's world is not the same as the world 20 years ago. So why is today's world holding a solo coder to much higher (and time-consuming) standards while expecting said solo coder's compensation to be the same (ie nothing) as it was 20 years ago?

Bash 5.0 released

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?

Bash 5.0 released

Posted Jan 14, 2019 12:09 UTC (Mon) by Wol (subscriber, #4433) [Link]

> 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?

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,
Wol

Bash 5.0 released

Posted Jan 11, 2019 14:44 UTC (Fri) by rleigh (guest, #14622) [Link] (18 responses)

Commits containing only a single focussed change with descriptive log messages is not exactly new. Plenty of projects have been doing this for decades, right back to CVS/RCS. There's nothing git-specific about this practice. Having a bunch of unrelated disparate changes in a single commit with nondescript log messages removes much of the value of having version control.

Bash 5.0 released

Posted Jan 14, 2019 12:14 UTC (Mon) by Wol (subscriber, #4433) [Link] (17 responses)

> Having a bunch of unrelated disparate changes in a single commit with nondescript log messages removes much of the value of having version control.

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,
Wol

Bash 5.0 released

Posted Jan 15, 2019 11:28 UTC (Tue) by cagrazia (guest, #124754) [Link] (15 responses)

I think there's no need to argue for one position or the other. It is crystal clear that bash should be deprecated as soon as possible by all distribution, as it is more a hobbyware than a real critical-mission software.

Bash 5.0 released

Posted Jan 15, 2019 12:00 UTC (Tue) by pizza (subscriber, #46) [Link]

Make no mistake, the only reason most folks use F/OSS is because "someone else" pays for its development.

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.

Bash 5.0 released

Posted Jan 20, 2019 2:54 UTC (Sun) by dualbus (guest, #129437) [Link] (12 responses)

It is mind boggling how dismissive you're being of other people's work and effort, just because they don't make commits in a specific way.

Bash 5.0 released

Posted Jan 20, 2019 3:30 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (11 responses)

No it's not. Because eventually somebody else will have to dig through the history in order to find out the source of the next vulnerability.

It also increases the chances of the next MD_Update disaster.

Bash 5.0 released

Posted Jan 20, 2019 4:10 UTC (Sun) by pizza (subscriber, #46) [Link] (10 responses)

So you are saying that someone else might have to do some work at some unspecified time in the future? Stop the internets!

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
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details."

Bash 5.0 released

Posted Jan 20, 2019 4:13 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (5 responses)

> So you are saying that someone else might have to do some work at some unspecified time in the future? Stop the internets!
Yes. If you're building public infrastructure then you MUST plan for the future. Is it that difficult to understand?

Bash 5.0 released

Posted Jan 20, 2019 13:30 UTC (Sun) by pizza (subscriber, #46) [Link] (4 responses)

> Yes. If you're building public infrastructure then you MUST plan for the future. Is it that difficult to understand?

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?

Bash 5.0 released

Posted Jan 20, 2019 20:41 UTC (Sun) by mjg59 (subscriber, #23239) [Link] (3 responses)

Two things that can simultaneously be true:

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.

Bash 5.0 released

Posted Jan 20, 2019 22:30 UTC (Sun) by pizza (subscriber, #46) [Link]

> but if it /were/ possible to convince Chet to change the way bash is maintained, life would still be better.

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.

Bash 5.0 released

Posted Jan 21, 2019 2:29 UTC (Mon) by pabs (subscriber, #43278) [Link] (1 responses)

Has anyone talked to Chet about changing to a more fine grained revision history before?

Bash 5.0 released

Posted Jan 21, 2019 6:32 UTC (Mon) by dualbus (guest, #129437) [Link]

The initial git migration was discussed here: http://lists.nongnu.org/archive/html/bug-bash/2011-11/msg...

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)

Bash 5.0 released

Posted Jan 20, 2019 11:13 UTC (Sun) by smurf (subscriber, #17840) [Link] (3 responses)

Yeah. We all know the boilerplate in those licenses. All programs have them. So does the kernel. So what?

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.

Bash 5.0 released

Posted Jan 20, 2019 13:43 UTC (Sun) by pizza (subscriber, #46) [Link] (2 responses)

So you're saying that, somehow, "caveat emptor" doesn't apply here?

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...)

Bash 5.0 released

Posted Jan 20, 2019 20:48 UTC (Sun) by smurf (subscriber, #17840) [Link] (1 responses)

No, I'm saying that c.e. applies to everything. Bash dash openssh kernel libreoffice windows msoffice – doesn't matter, they all say that, they only differ in how many words they use.

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.

Bash 5.0 released

Posted Jan 21, 2019 6:40 UTC (Mon) by dualbus (guest, #129437) [Link]

> 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. (...)

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?

Bash 5.0 released

Posted Jan 20, 2019 13:27 UTC (Sun) by flussence (guest, #85566) [Link]

You might be in for a rude awakening if you continue to feel entitled to infinite return on investment from all the software you use.

Appropriate use of version control

Posted Jan 18, 2019 15:21 UTC (Fri) by rleigh (guest, #14622) [Link]

Version control serves several purposes. Most of them rely upon having a clean history. Firstly, having clear and appropriate commit messages helps to find changes in the history when you need to find when a particular change was made. Secondly, having discrete changes in each commit makes it easier to revert selected changes, as well as to review changes in isolation.

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.


Copyright © 2019, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds