related: #131681

please update the PR title to match contributing, the same as the last one would do.

Also FYI you can make a new separate branch and push it over the one you were using for the last PR
git push <remote> <branch with new changes>:<branch you are pushing to>

e.g. git push origin upgrade_bash:bash_default_upgrade --force

Thank you, will definitely remember that one.

@vcunat when you have a moment, if you can run a hydra jobset for this PR, it would be great. I know you are busy, no rush.
This PR is fairly simple, so hopefully it should go smoothly.

Should we keep bash_5 and bashInteractive_5 around as aliases (or vice versa) for those who might have already been using them?

I personally would tend to say no, as the upgrade should be straightforward. (I know I'm biased toward breaking things, to signify that something has changed, so I'm open to other opinions).
Perhaps we should add something in the next release notes ? I would prefer to do that in another PR after this one has been merged.

I don't see a reason not to do an update to the release notes and docs in this same PR

Hydra is quite busy with security rebuild from OpenSSL (master now, 21.05 soon), so it will take at least a few days before there's capacity for that.

No worries, I'll ping again next week. Thank you for having checked!

A hydra job has been created on aarch64-linux for this https://hydra.nixos.org/jobset/nixpkgs/bash-5#tabs-evaluations
no failure due to this upgrade has been detected.
It's not a complete assurance that things are working, but it's a strong enough signal to merge in my opinion.
I will wait a couple more days in case people are against this.

I would actually merge this right now, but it looks like some conflicts have cropped up...

Just rebased, merging then. Thank you all for the time and care given to this!

Broke one mrsh test: https://hydra.nixos.org/build/155384906 (bash changed behaviour).

@trofi sorry about that! The failure isn't super clear from reading the logs. I'm curious about the change of behavior if you have more information. You probably know this but the bash changelog is not complete and so it makes it very hard to know what will actually break.

I only superficially looked at the test. It compares the output from mrsh (unchanged) to ouput from bash on the same test script (bash changed from 4 to 5). Let me try to dig the details out.

The following command changed behaviour under sh (but not bash):

a=~/foo:~/bar:~/baz; echo $a

$ nix build -f '<nixpkgs>' bash bash_4
$ ls -l
lrwxrwxrwx 1 slyfox users 55 Nov  1 21:52 result -> /nix/store/wadmyilr414n7bimxysbny876i2vlm5r-bash-5.1-p8
lrwxrwxrwx 1 slyfox users 56 Nov  1 21:52 result-1 -> /nix/store/4y0aacvxrkj3v7wayxpfxjda3km7c72a-bash-4.4-p23

$ /nix/store/wadmyilr414n7bimxysbny876i2vlm5r-bash-5.1-p8/bin/sh -c 'a=~/foo:~/bar:~/baz; echo $a'
/home/slyfox/foo:~/bar:~/baz
$ /nix/store/wadmyilr414n7bimxysbny876i2vlm5r-bash-5.1-p8/bin/bash -c 'a=~/foo:~/bar:~/baz; echo $a'
/home/slyfox/foo:/home/slyfox/bar:/home/slyfox/baz
$ /nix/store/4y0aacvxrkj3v7wayxpfxjda3km7c72a-bash-4.4-p23/bin/bash -c 'a=~/foo:~/bar:~/baz; echo $a'
/home/slyfox/foo:/home/slyfox/bar:/home/slyfox/baz
$ /nix/store/4y0aacvxrkj3v7wayxpfxjda3km7c72a-bash-4.4-p23/bin/sh -c 'a=~/foo:~/bar:~/baz; echo $a'
/home/slyfox/foo:/home/slyfox/bar:/home/slyfox/baz

sh under bash-5 stopped expanding ~ in the middle of a string before :. Not sure if it's intended or not.

Looks intentional. From the bash-5.1-beta changelog:

1. Changes to Bash
   …
   g. Avoid performing tilde expansion after `:' in words that look like assignment statements when in posix mode.

Although, hmm, that seems to contradict POSIX, which says:

In an assignment (see XBD Variable Assignment), multiple tilde-prefixes can be used: at the beginning of the word (that is, following the <equals-sign> of the assignment), following any unquoted <colon>, or both.

I reported a Bash bug about the apparent POSIX violation with some more context.