e3491c9e40
The status quo of `bash` not being interactive is frustrating for many users,
because trying to use it interactively is just messed up, and
`bashInteractive` is not intuitive and barely discoverable.
This was brought to my (and many others) attention by @stahnma in his
[talk at CfgMgmtCamp 2025](https://cfp.cfgmgmtcamp.org/ghent2025/talk/YUVUTN/),
where he highlighted this as one of the frustrations he ran into when
learning Nix.
Why this is fine:
- No reason for not making interactive the default was given in the original commit (6c6ff6f36f), but probably it was due to the increase in closure size
- The closure size only increases by 6.9MiB (19.5%) today, with the
added dependency on the store paths for readline and ncurses, which
are needed on systems in almost all cases anyways
- If somebody really needs to get a more minimal system, they can use
the newly-introduced `bashNonInteractive` instead now
- Though to apply it consistently, they'll need to do that in an
overlay like
```
final: prev: {
bash = self.bashNonInteractive;
}
```
Or alternatively using the `system.replaceDependencies.replacements`
NixOS option approach.
While there's also other such `*Interactive` packages that could use the
same treatment, `bash` is a great start.
This was already attempted before in
https://github.com/NixOS/nixpkgs/pull/151227, but was not continued for
unknown reason.
To avoid stdenv becoming bigger, all uses of bash in the (working)
stdenv's are changed to the explicitly non-interactive version here.
This commit will however still cause a mass rebuild for all packages (and reverse deps)
making use of the default bash.
25 lines
621 B
Nix
25 lines
621 B
Nix
{ pkgs }:
|
|
[
|
|
pkgs.coreutils
|
|
pkgs.findutils
|
|
pkgs.diffutils
|
|
pkgs.gnused
|
|
pkgs.gnugrep
|
|
pkgs.gawk
|
|
pkgs.gnutar
|
|
pkgs.gzip
|
|
pkgs.bzip2.bin
|
|
pkgs.gnumake
|
|
pkgs.bashNonInteractive
|
|
pkgs.patch
|
|
pkgs.xz.bin
|
|
|
|
# The `file` command is added here because an enormous number of
|
|
# packages have a vendored dependency upon `file` in their
|
|
# `./configure` script, due to libtool<=2.4.6, or due to
|
|
# libtool>=2.4.7 in which the package author decided to set FILECMD
|
|
# when running libtoolize. In fact, file-5.4.6 *depends on itself*
|
|
# and tries to invoke `file` from its own ./configure script.
|
|
pkgs.file
|
|
]
|