5 ms·

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 withou

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 9y ago
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 9y ago
  This is on Mac OS. I might try the tracing idea though.
chubot 9y ago
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.
brown9-2 9y ago
An easy way to figure this out is to add `set -x` to .bash_profile or its equivalent.
ploxiln 9y ago
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).
dahart 9y ago
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 9y ago
  Yep, I have profiled my shrc scripts in exactly this fashion before for exactly this reason.

cturner 9y ago

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 9y ago
This is on Mac OS. I might try the tracing idea though.

chubot 9y ago

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.

brown9-2 9y ago

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

ploxiln 9y ago

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).

dahart 9y ago

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 9y ago
Yep, I have profiled my shrc scripts in exactly this fashion before for exactly this reason.