Breakage with zsh when doing Ctrl+C

[jleclanche]

Since recently, in zsh, doing yaourt -Su followed by Ctrl+C at the "Continue upgrade ? [Y/n]" prompt results in shell breakage; password prompts no longer work properly for example.

This doesn't happen on bash. I haven't tested in yaourt-git yet.

[arakis]

Hello,
since some months, i have the same problem, that in some scenarios control chars are written.

Example:
$ yaourt

After the list is complete, i should enter a number. When pressing CTRL+C, yaourt should be terminated. (it was so in the history). But, only "^C" will be written, it will not terminated. The "^C"'s ware not removable via backspace.

Sometimes (i found no way to "safely" reproduce this"), after exiting yaourt, my command line is "broken". When pressing the up-key, i see control chars, and the enter-key do not work always on input's. I need to close the terminal and reopen it.

Some facts:

• It seems to be not an yaourt-only problem, because even the normal shell is broken after exiting it (only in rare scenarios, i described it above). But....it "happens" only after using yaourt(!!)
• It occurs first time after an system upgrade, but not after an yaourt-upgrade itself. I tried to upgrade it after this issue, but it does not resolved it. I can't check wich package is the matter...its too long ago.
• It's not an problem of the terminal (xfc4-termianl) or shell (zsh with presto): When running "$ xterm bash", this problem occurs, too.
• It occurs on native virtual terminal (text mode only), too.
• I reinstalled with --force the package "readline" and "yaourt".
• the /etc/inputrc is not modified. There's no local .inputrc, same with yaourtrc.
• password prompts to not work after the problem occurs (restart shell solve this)

Here's an example of the location in the yaourt script, after this issue occurs:

prompt $(gettext 'Enter n° of packages to be installed (ex: 1 2 3 or 1-3)')
read -ea packagesnum

starting bash and typing "read -ea packagesnum" will work as expected.

But in my case, it occurs in bash, too.

So, how can a application (yaourt) break an underlinding shell? This should not be possible. Is this now a bug of the shell environment (for example readline) or yaourt?

Greetings from Germany,
Sebastian

[alex404]

I'm getting the same problem in zsh. I'm glad I'm not the only one... this issue has been seriously weirding me out.

[eaufavor]

It seems that yaourt -Su then control+c generates some broken chars in zsh so that normal enter is not valid sometimes. Pressing ctrl+enter instead of enter after inputing password will make it work temporally. Typing "reset" will fix it for current zsh session . But it is still annoying to me.

[eaufavor]

@arakis After checking the upgrade time of yaourt and zsh. It seem that the most suspected causes are bash and readline as they are updated at 4.23 which is very close to the date I began to have this bug. Yaourt on the other hand has not been upgraded since a year ago.

[jleclanche]

This could be a bug in yaourt exposed by a readline upgrade.

[tuxce]

Do you have the same problem if you run yaourt without color ?

yaourt --nocolor <...>

[jleclanche]

Confirmed, reproduced the issue with --nocolor.

Repro:

yaourt -S xcursor-tux
Ctrl+C
passwd
<enter>

[tuxce]

I don't think it's a yaourt issue, I can reproduce it just by running :

bash -c "echo test; read"

and ctrl-c

Can you confirm me that ?

[jleclanche]

Unable to reproduce with your test case.

[tuxce]

Ok, forget about the test, the breakage remains after a zsh exit if I stay in the same terminal.

It seems like yaourt changes the state of the terminal, but I don't know how for now :|

I executed an stty before and after running yaourt, here is the diff :

-lnext = ^V; flush = ^O; min = 1; time = 0;
+lnext = <undef>; flush = ^O; min = 1; time = 0;
 -parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts
--ignbrk brkint ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
+-ignbrk brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl ixon -ixoff

I search why.
You can preserve terminal state by adding this to .zshrc :

ttyctl -f

[SammysHP]

One idea without looking into the diff or the source: By default most terminals work in the cooked mode. User input is sent to the program only after pressing Enter. To read for example "Question (Y/n)" the terminal must be in the raw mode.

http://en.wikipedia.org/wiki/Cooked_mode

Maybe zsh does not reset the mode after the program exits, but bash does.

[mickael9]

I think this might actually be a bug in bash (or readline) that doesn't reset the terminal correctly if a trap is set.

Here is a minimal test-case that triggers the bug :

#!/bin/bash
cleanup() { :; }
trap cleanup 0
read -e dummy

Edit : the bug is introduced with this bash commit : http://git.savannah.gnu.org/cgit/bash.git/commit/?id=9b86eb22c434c8848c9d592cba32d7e8fdf61459

[mickael9]

A patch has been published : https://lists.gnu.org/archive/html/bug-bash/2014-09/msg00031.html

[dschoepe]

I can confirm that that patch fixes the problem for me. For some reason, the patch hasn't made it into the bash yet though.

[xuhdev]

I have the same problem with zsh.

[jlovison]

I've had the same issue with zsh -- just in case anyone stumbles across this issue before it gets fixed, a temporary solution is using Ctrl+D to send an end-of-control to the terminal -- works fine for both sudo password entry and [Y/n] confirm prompts.