[portlander12345]

Slightly off-topic, but this reminded me of a mystery: Does anyone else experience that bash takes a long and variable time to start, on many systems and without any fancy setup of any kind? What can a shell be doing that it takes three or four seconds to start?

[cturner]

Is part of this an experience of cygwin? Forking is slow under cygwin. If you can get to a recent Windows 10 with local admin rights, you can install windows-services for linux, and bash should perform well even on ten-year-old hardware.

If you getting unusual slowness in linux/BSD, some things to check: (1) any significant overhead on the system that could be making forking slow; (2) some option in your $HOME/.bashrc that is adding latency, e.g., indexing options or dynamic stuff in your PS1; (3) unusual filesystem stuff, e.g., your home directory is mounted over NFS.

If you're in linux and it is reproducible, run strace against a bash launch, and ctrl+c it when it gets stuck. Have a look at the recent system calls.

[portlander12345]

This is on Mac OS. I might try the tracing idea though.

[dahart]

Yes, that happens all the time for me. And more often than not, it's because of all the crap I put in my startup scripts without realizing it until it gets too big. Sometimes it's the volume of crap other people have put in /etc/bashrc. Sometimes it's a slow filesystem causing one of the startup commands to hang a little. Sometimes it's a command that's just big and bloated.

It's instructive to dig in and debug it, you may be really surprised how much insane amounts of stuff a shell can be doing in those 3-4 seconds. Just some examples of what my shells are doing: archiving my history (diffing & zipping files), bash completion, git completion, read color definitions, run OS-specific scripts, run host-specific scripts, add (read & parse) lots of aliases & functions, run /etc/bashrc (which on my macOS laptop is almost 3k lines long)

The last performance issue I had was my history archiving junk got too big, I was saving my full .bash_history into an archive every day without clearing .bash_history, so they kept getting bigger. Diffing against the previous day, and writing a smaller file, fixed it.

You can binary search by putting a couple of "date +%s%N" in your .bashrc or .bash_profile to find out what's taking the longest.

[loeg]

Yep, I have profiled my shrc scripts in exactly this fashion before for exactly this reason.

[chubot]

I don't have this experience -- I highly suspect NFS or another network file system.

On my system, hitting Ctrl-Shift-T inside xterm is almost instant, and that starts a bash process. Likewise for Ctrl-B C in tmux.

Bash's startup files are annoying, but you can probably pinpoint the problem with strace.

Or maybe try running:

    strace bash

vs.

    strace bash --norc --rcfile=/dev/null

However this isn't the full story because bash's startup sequence is a nightmare and neither of those is likely to be exactly what happens when you're starting a new shell.

[ploxiln]

My bash always starts near instantaneously, because I have never tolerated it not doing so.

bash-completion (available in many package managers) used to be one culprit, should be less of one now due to on-demand completion loading, but still noticeable. I don't use it. Another is rvm, nvm, etc (managers of ruby or nodejs versions for development, install process typically adds to your .bashrc).

[brown9-2]

An easy way to figure this out is to add `set -x` to .bash_profile or its equivalent.