Re: Problems with handicapped 'bash' from glibc package

[Mark H Weaver]

address@hidden (Ludovic Courtès) writes:

> Andreas Enge <address@hidden> skribis:
>
>> On Wed, Feb 12, 2014 at 05:39:35PM +0000, Mark H Weaver wrote:
>>> While we're on the subject of 'bash', should we be applying the patches
>>> in http://ftp.gnu.org/gnu/bash/bash-4.2-patches/ ?
>>
>> Is there a chance of convincing the bash people to release bash 4.2.1?
>> It seems absurd to off-load the work of applying 45 patches from the last
>> three years on the users.
>
> Yeah, that’s annoying.
>
> Basically, these patches are the version control system of Bash
> (really!).  So in my view, if the maintainer doesn’t publish a new
> version, then it means that users can live without these patches.
>
> I haven’t checked what the current patch set is about, though.

The patches are bug fixes.  Things like:

* bash42-003: When using the pattern replacement and pattern removal
  word expansions, bash miscalculates the possible match length in the
  presence of an unescaped left bracket without a closing right bracket,
  resulting in a failure to match the pattern.

* bash42-004: When used in contexts where word splitting and quote
  removal were not performed, such as pattern removal or pattern
  substitution, empty strings (either literal or resulting from quoted
  variables that were unset or null) were not matched correctly,
  resulting in failure.

* base42-007: When used in contexts where word splitting and quote
  removal were not performed, such as case statement word expansion,
  empty strings (either literal or resulting from quoted variables that
  were unset or null) were not expanded correctly, resulting in failure.

* base42-008: Bash-4.2 does not attempt to save the shell history on
  receipt of a terminating signal that is handled synchronously.
  Unfortunately, the `close' button on most X11 terminal emulators sends
  SIGHUP, which kills the shell.

* base42-009: Under certain circumstances, running `fc -l' two times in
  succession with a relative history offset at the end of the history
  will result in an incorrect calculation of the last history entry and
  a seg fault.

...etc.

I don't want to run a shell with known bugs.
I want these fixes on my system.

What do you think?

      Mark