C-s does not work to save to file when running bpython in virtualenv

I am running bpython on Ubuntu 14.04 within a virtualenv and when pressing Ctrl+s nothing happens but when I run bpython with the system python interpreter Ctrl+s works as expected.

This happens even though I tell bpython which config to use: bpython --config /path/to/bpython/config

What are you expecting to Ctrl+s to do, forward i-search? Do you have a config that sets Ctrl+s to that instead of the default which is saving?

I am expecting it to ask me for name of file to save to just like when not running within a virtualenv. I wasn't using any config at first but then I tried to use a config which explicitly set Ctrl+S to save to file but that didn't change anything

why would it behave any differently when run within a virtualenv?

Ah got it. Hm maybe it's a different version? I can't reproduce this. So the message asking you to choose a filename doesn't come up?

@thomasballinger

@thomasballinger yes, nothing happens

Could you check the version of each of the installations?

looks like I have a newer version (0.15) in my virtualenv, where Ctrl+s is not working. using the system interpreter I get version 0.12. I hope I'm checking the version the right way though, I imported bpython and checked bpython.version

Hm, thinking of other things to try. What's does the help message that comes up with F1 say the save key is? (it's in the Features: section)

also, what OS?

It says it's Ctrl+s but nothing happens when I press it. My OS is Ubuntu 14.04.1 64-bit with gnome flashback desktop environment.

I don't know what to look at next. Let me know if anything else seems weird about your installation.

You could try using all the other hotkeys to see which ones work? They're each similar to ctrl-s in different ways, so knowing that some others also didn't work could point toward a solution.

Could be a conflict with other hotkeys? I was having a similar issue, Mint 18 + zsh + bpython 0.16 + python 3.5.2 running in an virtualenv, C_s didn't save the current session to file (nothing happened) but if I remapped save session to F8 it prompted me to enter a file name and saves the file. I suspect that by default zsh intercepts C_s to be fwd-i-search, hence conflicts with bpython's key binding.

👍 cant use ctrl-s on os x mavericks w/ bpython in a virtualenv, python installed via homebrew.

@billyzs

@billyzs I'm using bash, not zsh, and nothing conflicts with Ctrl+S to my knowledge (I've tried finding any bindings with that combination but still haven't found anything). However remapping to something else worked

@stantonk

@stantonk Since you're on OS X, does running

stty stop undef

before you run bpython fix this?

To anyone with this problem right now looking for a workaround: you can use F7 to open the current session in a text editor (vim by default, if you don't have $VISUAL or $EDITOR set to something else) and then copy the session from there.

With MacOS X Terminal, zsh or bash, bpython 0.16, no virtualenv : C-s does nothing. Other keys C-x C-r F1 F7 F8 do work. I had to install watchdog (with pip, no problem). C-s is not defined in Terminal keyboard preferences and does nothing also outside of bpython. I acknowledge the workaround with F7.

@palbarede

@palbarede just an idea, but could you post the output you get from running stty -a in bash?

bash-3.2$ stty -a speed 9600 baud; 30 rows; 89 columns; lflags: icanon isig iexten echo echoe -echok echoke -echonl echoctl -echoprt -altwerase -noflsh -tostop -flusho pendin -nokerninfo -extproc iflags: -istrip icrnl -inlcr -igncr ixon -ixoff ixany imaxbel iutf8 -ignbrk brkint -inpck -ignpar -parmrk oflags: opost onlcr -oxtabs -onocr -onlret cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow -dtrflow -mdmbuf cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = <undef>; eol2 = <undef>; erase = ^?; intr = ^C; kill = ^U; lnext = ^V; min = 1; quit = ^\; reprint = ^R; start = ^Q; status = ^T; stop = ^S; susp = ^Z; time = 0; werase = ^W;

C-s is bound to stop and unbound with :

stty stop undef

Then C-s works as announced in bpython, prompting to save file.

Thanks.

@thomasballinger

@thomasballinger yes, running stty stop undef first fixes it.

~  $  which python
/usr/local/bin/python
~  $  python --version
Python 2.7.12
~  $  bash --version
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin15)
Copyright (C) 2007 Free Software Foundation, Inc.

El Capitan, OS X 10.11.6

@thomasballinger

@thomasballinger also, I'm in iTerm2

This has plagued me for SO LONG! I too am using iTerm2 v3.0.13 on macOS 10.12.3 and "bpython version 0.16 on top of Python 3.6.0". I have found that 'stty stop undef' works, but now that I know about F7 I really don't need it. I'd much rather go immediately into VIM and clean up the session before saving it anyway. It's pretty awesome that you can rewrite to the temp file and it will re-execute when you quit your editor.

I should have hunted for this sooner.

‘stty stop undef’ doesn’t work for me in bash or zsh on MacOs 10.14. (Mojave).

I also noticed that when I exit bpython and run ‘stty -a’, stop is mapped to ^S again.

I’ve tried finding other keys to use (e.g. F13), but none of them seem to work. But F7 as a workaround is still valid.

I also fought this issue for a while. After some googling, I figured out that this is related to flow control, which is why stty stop undef seems to work in some cases.

It did not work for me, however.

After even more googling, I discovered that you can disable C-s for good by adding the following to the end of your .bashrc or .zshrc file:

stty -ixon

See https://unix.stackexchange.com/a/332793 for more info.

Now C-s works as expected in bpython!

The ctrl+q/ctrl+s shortcuts are indeed generally used for flow control in your terminal (XON/XOFF). If you suffer from this issue please make sure to report your version of bpython. It might have something to do with different backends being used?

I’m using bpython 0.19.

I’ve been trying it on macOS with iTerm2 and Zsh, Windows 10 with PowerShell, and Ubuntu 18.04 with the Terminal app (doing research on alternative Python REPLs for an article I’m writing for realpython.com).

On Windows I’ve been using the curses backend, for macOS and Ubuntu whatever backend is used by default when running the bpython command.

It seems like the issues with keybindings are not so much bugs in bpython but a symptom of terminal configurations.

It gives me a starting point to reproduce and debug this :)

I have the same problem using bpython in bash.
There is a shortcut asigned to C-s that make this:

Ctrl+S: Stop all output to the screen. This is particularly useful when running commands with a lot of long, verbose output, but you don’t want to stop the command itself with Ctrl+C.

So if you use C-s in CLI the system stop the screen and don't save the file.

@stantonk

Same issue occurs when I run bpython from wsl2 (both in system and in virtual env).
However running either stty stop undef or stty -ixon, as mentioned by @stantonk and @somacdivad fixes the issue for me too.
I am running wsl2 with Ubuntu 18.04 with Python 3.10.0 and bpython 0.21

Navigation Menu

Repository navigation

C-s does not work to save to file when running bpython in virtualenv #638

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

C-s does not work to save to file when running bpython in virtualenv #638

Description

Activity

thomasballinger commented on Oct 8, 2016

logileifs commented on Oct 8, 2016

logileifs commented on Oct 8, 2016

thomasballinger commented on Oct 8, 2016

logileifs commented on Oct 8, 2016

thomasballinger commented on Oct 8, 2016

logileifs commented on Oct 8, 2016

thomasballinger commented on Oct 8, 2016

thomasballinger commented on Oct 8, 2016

logileifs commented on Oct 9, 2016

thomasballinger commented on Oct 10, 2016

billyzs commented on Oct 23, 2016

stantonk commented on Dec 16, 2016

logileifs commented on Dec 17, 2016

thomasballinger commented on Dec 18, 2016

thomasballinger commented on Dec 18, 2016

palbarede commented on Dec 21, 2016

thomasballinger commented on Dec 22, 2016

palbarede commented on Dec 23, 2016

stantonk commented on Jan 2, 2017

stantonk commented on Jan 2, 2017

RichardBronosky commented on Feb 10, 2017

HappySpaceInvader commented on Feb 21, 2020

somacdivad commented on Apr 9, 2020

supakeen commented on Apr 11, 2020

somacdivad commented on Apr 11, 2020

supakeen commented on Apr 11, 2020

Nideapum commented on Jun 20, 2021

nnonchev commented on Oct 23, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions