And if you want an increasingly slower bash startup, you can add the following to your coworker's .bashrc/.bash_profile if they keep forgetting to lock their screen when they go to grab a snack:
echo 'sleep 0.01' >> ~/.bashrc # or ~/.bash_profile
I have never tried to measure the startup time for interactive bash, because my .bashrc only has a large number of environment variables and of command aliases, so I do not see any visible delay at startup.
However I have tried to benchmark bash against zsh, to see if one of them is faster.
The benchmark was inconclusive, because I have tried 2 scripts, but the execution times were essentially the same for both bash and zsh.
The 2 scripts invoked a small shell script on each of about ten thousand files and various file attributes were tested and compared in some shell conditional expressions.
Because the times were the same for bash and zsh, it is likely that the file operations dominated the execution time and not the shell startup time or the script interpretation, as I expected.
The shorter benchmark corresponded to an execution time of about 10 millisecond per shell script, so this is an upper limit for the bash startup time in non-interactive mode on my computer.
It is likely that the startup time was several times less.
In conclusion, the startup of bash in non-interactive mode, when it does not source .bashrc or other scripts, is no more than a few millisecond.
It is clear that someone who wants bash to start fast should be able to reach a startup time much, much less than a second.
Nearly 2s for a shell startup is ridiculous. I am starting to understand why the Apple fans are so excited about clawing back some performance with M1. My bash login shell is under 40ms on this cheap 4 year old i5 laptop. People must load some crazy stuff in their profiles
Um, no? Debian changed what /bin/sh is, which is what many shell scripts use, especially those startup scripts used by sysvinit. The shell of the root user remains, AFAIK, /bin/bash.
> I would be curious if mksh is also faster. ksh93 also claims great performance increases, but it is no longer (well) maintained.
mksh `printf` is not builtin, so if the script makes heavy use of it then it tends to be slower than bash.
ksh is very interesting because it has the ability to avoid spawning new processes on most command susbstitutions, making it usually much faster than all other POSIX shells.
But again this depends heavily on what the script being executed is doing, here's a highlight of what I described:
$ time mksh -c 'for i in $(seq 1000); do printf $(printf $(printf $(printf hello))); done' > /dev/null
real 0m2.121s
user 0m1.321s
sys 0m0.875s
$ time ksh -c 'for i in $(seq 1000); do printf $(printf $(printf $(printf hello))); done' > /dev/null
real 0m0.013s
user 0m0.008s
sys 0m0.005s
$ time dash -c 'for i in $(seq 1000); do printf $(printf $(printf $(printf hello))); done' > /dev/null
real 0m0.311s
user 0m0.279s
sys 0m0.073s
$ time bash -c 'for i in $(seq 1000); do printf $(printf $(printf $(printf hello))); done' > /dev/null
real 0m0.664s
user 0m0.538s
sys 0m0.186s
tl;dr: If you're seeing unreasonably short startup times, try `hyperfine 'bash -i'` instead.
Funny, I thought my startup time was going to be ginormous, considering I've literally committed to it 203 times so far[1]. Nope, 1.4 to 4.3 ms.
Update: Eyeballing the startup time it's definitely over a second, so I'm guessing OP is measuring something different from what I'm seeing. `hyperfine bash` is also below 5 ms, so I'm not sure how to measure actual startup time. `hyperfine 'bash -i'` does the trick, showing ~650 ms startup times. Turns out another blogger found this already[2] :)
I've found that `brew` itself is quite slow. I think the problemis just with how brew does it's package management. I'm not going to complain about it, because it's (IMO) better than MacPorts.
