Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bash autocompletion causes slow interactive login times #101

Closed
ElvishJerricco opened this issue Sep 21, 2018 · 8 comments · Fixed by #178
Closed

Bash autocompletion causes slow interactive login times #101

ElvishJerricco opened this issue Sep 21, 2018 · 8 comments · Fixed by #178

Comments

@ElvishJerricco
Copy link

When I set programs.bash.enableCompletion = true;, it adds 0.8s to my login time, regardless of whether the shell is interactive or not. Annoying enough that now I just disable it.

@LnL7
Copy link
Owner

LnL7 commented Oct 8, 2018

I recall something about this related to the fact that the default version of bash on macOS is really old. Using the nix version of bash as your login shell might resolve this if that's the case.

@ElvishJerricco
Copy link
Author

ElvishJerricco commented Oct 8, 2018

@LnL7 I have:

{ pkgs, ... }: {
  users.users.will = {
    description = "Will Fancher";
    home = "/Users/will";
    shell = "/run/current-system/sw/bin/bash";
  };
  environment.shells = [ pkgs.bashInteractive ];
}

So I thought I had that set up right. And in fact:

$ echo $BASH
/run/current-system/sw/bin/bash
$ echo $BASH_VERSION
4.4.12(1)-release

However, oddly enough, if I do these things directly from SSH then I get different results:

$ ssh hostname 'echo $BASH'
/bin/bash
$ ssh hostname 'echo $BASH_VERSION'
4.4.12(1)-release

It's using /bin/bash, though it does appear to be a recent version.

EDIT: Weird:

$ ssh hostname /bin/bash --version
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin16)
Copyright (C) 2007 Free Software Foundation, Inc.

@LnL7
Copy link
Owner

LnL7 commented Oct 17, 2018

With #109 non-interactive cases shouldn't suffer from this anymore, but unless that was the cause somehow there's not much that can be done about it I think.

@LnL7 LnL7 closed this as completed Oct 17, 2018
@ElvishJerricco
Copy link
Author

@LnL7 though it's definitely less of a problem for only interactive logins to be slow, I think it's still a problem. The issue should probably remain open and be renamed.

@ElvishJerricco ElvishJerricco changed the title Bash autocompletion causes slow login times Bash autocompletion causes slow interactive login times Oct 17, 2018
@LnL7
Copy link
Owner

LnL7 commented Oct 17, 2018

Oh, I confused this with #98.

@LnL7 LnL7 reopened this Oct 17, 2018
@ElvishJerricco
Copy link
Author

but unless that was the cause somehow there's not much that can be done about it I think.

@LnL7 How does NixOS avoid this problem? I remember reading somewhere that Bash can lazily load completions. Maybe we need to do that?

@LnL7
Copy link
Owner

LnL7 commented Oct 17, 2018

Not sure, that's why my initial suspicion was the default bash 3.2.

@Kaali
Copy link

Kaali commented Dec 12, 2019

Pushed a fix for this which speeds up the interactive bash startup time significantly. Bash loads the completions from /share/ on demand, so they don't have to be preloaded. NixOS also fixed this in the same way in NixOS/nixpkgs#32534

LnL7 pushed a commit to Kaali/nix-darwin that referenced this issue Jan 21, 2020
As described in detail here: NixOS/nixpkgs#32533
bash will load completion scripts in $p/share/bash-completion/completions/ on
startup instead of letting bash-completion do it's lazy loading. Bash startup
will then slow down (very noticeable when bash-completion is installed in a
profile).

This commit leaves loading of scripts in the hands of bash-completion,
improving startup time for everyone using `enableCompletion`.

Fixes LnL7#101
@LnL7 LnL7 closed this as completed in #178 Jan 21, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants