Prezto: [Bug] ^D while command is running inserts a space

[hiqua]

Hi,

if I hit ^D while running e.g. sleep 10, a space is appended to the next prompt. This means that one has to do ^C ^D to close a terminal when one has already entered ^D, instead of just entering ^D until the command no longer runs.

The problem disappears if I comment this line: https://github.com/sorin-ionescu/prezto/blob/282b478fd2eb6658c063d4f32b9856201e5b886c/modules/editor/init.zsh#L424

I have been able to reproduce it with a fresh user / prezto install with no other customization.

zsh: 5.4.2-3 on Debian Stretch (version from testing)
prezto: last version

I don't know how to fix it without removing this functionality though.

[hlecuanda]

Hi... i'm trying to reproduce the issue, without success, so far. there are a lot of places keybindings can break: Terminal emulator, terminal multiplexer, wrong $TERM setting, even some curses software doing funny stuff with stty and undocumented glitches.

It would really help me if you could provide me with the output of reporter so i can reproduce your environment locally. (the only thing that would beat this is a full fledged container or vagrant box).

Before sending or publishing reporter's output, make sure no API keys or other secrets made their way to the cloning script. unfortunately there's no universal way to avoid this as secrets could be anything from environment vars to hardcoded stuff.. n.n

[hiqua]

Hi,
I can reproduce this bug with a Debian Docker image (docker pull debian), and by following the normal prezto installation steps. You would need to apt install zsh git before.

With your current setup, what happens when you run ^D while sleep 10 is running? Does it close the terminal right after the command exits?

Edit (steps to reproduce):
Dockerfile:

FROM debian:stretch
RUN apt-get update && apt-get -y install zsh git
COPY setup.sh .
RUN ./setup.sh

setup.sh:

#!/bin/zsh
git clone --recursive https://github.com/sorin-ionescu/prezto.git "${ZDOTDIR:-$HOME}/.zprezto"
setopt EXTENDED_GLOB
for rcfile in "${ZDOTDIR:-$HOME}"/.zprezto/runcoms/^README.md(.N); do
  ln -s "$rcfile" "${ZDOTDIR:-$HOME}/.${rcfile:t}"
done
chsh -s /bin/zsh

Then docker build, which returns e.g. af795a7c86be, then:

docker run -it af795a7c86be
and reproduce the bug mentioned in my first post.

[hlecuanda]

wonderful! I'll have a look. _Debian_ and _debian-derived_ distros do have a bunch of site-wide functions and bindings defined on /etc/zshrc which _may_ be causing some conflict with prezto. I noticed that when migrating my environment from FreeBSD whose zsh port has no site-level customization, i.e. /etc/zsh/* are blank from the get-go.

[hiqua]

Could be, however I looked at the files in /etc/zsh, there is indeed a zshrc that loads quite a lot of things, but the bug is still here when I move all these files to a different location.

I looked at the files that are installed along with zsh and zsh-common (on which zsh depends in Debian), and there doesn't seem to be other files that are specific to Debian. But I'll let you have a look, I hope you can find the root cause.

I'm glad that you suggested this however, because my terminal startup is way faster when I remove these files. Not sure if it's worth opening a new issue.

[hlecuanda]

I usually remove most of what debian does, in its site-wide files, however not all of it is bloat.

they do add important variables in /etc/zsh/zshenv which gets executed anyways.

If this is your distro of choice, you could add the following to your dotfiles, so you don't have to clear the /etc/zsh/* files when moving your environment to another machine or upgrading your OS:

.zshenv

export DEBIAN_PREVENT_KEYBOARD_CHANGES
typeset skip_global_compinit

prezto does compinit and adds more sensible mappings later on, so this avoids going through initializing the completion system twice.

.zpreztorc:

# add zrecompile to whatever is already on the line:
# zstyle ':prezto:load' zfunctions (mine looks like this):
zstyle ':prezto:load' zfunctions zargs zmv zrecompile zsh-add-hook
# internally prezto uses zargs and zmv. check man zshcontrib 
# for other useful stuff you can add here

.zlogin:

# before "compile completion dump..."
fpath=($fpath[@] /usr/share/zsh/functions /usr/share/zsh/vendor-completions )
# vendor-completions adds native zsh completion for *ugh* systemd cli utilities (journalct, systemctl, etc)
# and  functions adds native zsh completions for almost all standard Linux commands 

# after zcompile:
# autoload -Uz zrecompile # this gets done by the zstyle on .zpreztorc, uncomment if you 
# decided not to modify .zpreztorc so the function gets autoloaded here.
bashcompinit
zrecompile

seems counterintuitive, but zrecompile does some sort of magic and makes the function and
completion caches way faster. Basically "compiles" all functions to bytecode,and writes them to the cache (.zwc files wherever there is a functions directory) but avoids loading them to memory, so they still behave like lazy-loading functions (they get loaded only the first time you use them, and stay in memory afterwards). Also, the cache is refreshed ONLY when something changes, so next time you log in, all that work is already don and startup is orders of magnitude faster, without compromising on feature availability.

---

Another _more drastic_ alternative is to add:

.zshenv

unsetopt GLOBAL_RCS

This will effectively skip loading any /etc/zsh/* files from that point on. However you might want to add the following to your .zshrc:

.zshrc:

# makes completion work when doing sudo:
zstyle ':completion:*:sudo:*' command-path /usr/local/sbin \
                                           /usr/local/bin  \
                                           /usr/sbin       \
                                           /usr/bin        \
                                           /sbin           \
                                           /bin            \
                                           /usr/X11R6/bin

none of the above will fix this issue though. :rofl: i still have to check it out, but I thought it important to let you know what worked for me on Debian derived distros n.n

[hiqua]

Did you manage to reproduce the issue?