2

I have a small problem with zsh, it uses the CPU at 100% sometimes. In the image below: htop

How can I solve it? I have killed it many times, but it always starting again.

The configuration file is simple, it's default from oh-my-zsh plus some stuff for virtualenvwrapper and pyenv:

 source /usr/bin/virtualenvwrapper.sh
 export PATH="/home/plugaru/.pyenv/bin:$PATH"
 eval "$(pyenv init -)"
 eval "$(pyenv virtualenv-init -)"

And yes, I am using Atom :)

  • could you past your .zshrc configuration file please? – aurelien Nov 26 '16 at 10:02
  • If you do not wish to share your configuration file, you could verify it with wiki.archlinux.org/index.php/Zsh – aurelien Nov 26 '16 at 10:03
  • You'll also help answerers by editing the question to confirm that yes, you are using atom. (-: – JdeBP Nov 26 '16 at 10:12
8

This bug is the result of some questionable design in Atom. It's not specific to the Z Shell, moreover. People experience it with other shells, too.

Atom wants to know the environment variables of your interactive login shell for some reason. To do this, it spawns an instance of your chosen shell, tells it to run the env command (after running all of its startup scripts) using the shell's -c command line option, and captures the output of that. It tries to ensure that it doesn't hit any shell aliases, so it runs command env, and it tries to get the environment as it would be for a login shell by giving your chosen shell a -l command-line option as well.

The Atom developers found that people weren't setting their environment up correctly for non-interactive login shells. To bodge around this, they made it also supply the shell with the -i option that tells the shell to think that it is an interactive login shell even if its standard I/O does not appear interactive.

Unfortunately, they happen to invoke an interactive shell in such a way that shells such as the Z Shell go the whole hog and try to read input interactively. But Atom doesn't supply them with any input, just an end-of-file.

Enter the Z Shell's and the Bourne Again shell's ignoreeof options as the final element of this comedy. These options mean that the shells keep trying to read input, even if they get end-of-file on standard input. They do so in a pretty tight loop. Hence the CPU usage.

Further reading

  • Wow, thanks a lot for description. I haven't thought that the problem is in Atom. – PlugaruT Nov 26 '16 at 14:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.