Under pdb in Python 2 I could CTRL-C and quit my Python program.
Under Python 3.6 I doesn't do that, just displays --KeyboardInterrupt-- and ignores me. In order to quit, I need to CTRL-D instead, but that will also terminate my bash session if I "do one too many".
Can I bring back CTRL+C behavior?
Python 3.6, macOS Sierra.
I still consistently have the same behavior. Maybe it’s a glitch in my environment but otherwise I can’t see the benefit of explicitly ignoring a user’s request to terminate a program with CTRL+C.
However, I have found that hitting ‘q’ triggers pdb quit which mostly ends up with the desired result, termination of the program. And, unlike CTRL+D has no risk of closing the launching bash session either.
edit - this did the trick 😀
(I have code that is made to trap exceptions, which is why a simple q/quit was hit or miss)
as per Is there a way to prevent a SystemExit exception raised from sys.exit() from being caught?
🧨 : note its warning about no cleanup code being run
# ~/.pdbrc
alias qq import os; os._exit(1)
Related
Is there a function that can be called from within the Python console that has the exact same effect as doing the following:
Calling
exit()
to exit the console, followed by calling
python
at the command prompt to re-enter a fresh python console.
NB: I am not seeking to just clear or de-clutter the screen, because using CTRL+L accomplishes that quite easily.
If you want to get rid of the variables defined in the session then this should do your job.
import gc
del <variable_name>
gc.collect()
I'm doing some engineering analysis with the help of a FEA program and Python. When the analysis ends I need to press a key to continue. But this is not a normal press any key to continue. Every code executed with the scripts stops. Like a handput debug break. Nothing runs until I press something or switch windows.
I cant use send keys and subprocesses because running code completely stops. Only solution I could come up with is to use another script in another command window with simple send keys command. This extra script is useless if computer is used or another window is active.
I'm a beginner level programmer and maybe I'm missing something simple. I guess the problem is caused by the FEA programs code but I'm not sure. So is there any way to prevent my code from stopping? Thank you for your time.
It seems that the FEA program does the windowing and you cannot do much about it. I actually automate scripting in DIANA FEA. For this program I would try something like pywinauto.
https://github.com/pywinauto/pywinauto
And call your python script from another python script.
from pywinauto import Desktop, Application
import time
app = Application().start("FEA_program.exe my_python_script.py")
while True:
time.sleep(5)
# send key presses to the app every arbitrary seconds
I would like to enter a password into the IDLE terminal in Windows without an echo.
Normally entering passwords is possible with python using the function getpass.getpass(), but in IDLE there comes up the following warning message:
GetPassWarning: Can not control echo on the terminal.
Warning: Password input may be echoed.
I found out, this is because IDLE replaces the sys.stdin with a different object:
if sys.stdin is not sys.__stdin__:
return fallback_getpass(prompt, stream)
However, I could not find a solution. Does anybody have an answer or another way to enter a password into the IDLE terminal without an echo?
As an IDLE maintainer with some familiarity with IDLE internals, I do not believe that it is possible to suppress character display but not otherwise change behavior in response to input('prompt') without major changes to IDLE code.
But even that would be insufficient for getpass.getpass since it calls one of unix_getpass, win_getpass, or default_getpass, and the first two use system_specific low-level functions that bypass stdin.
In terms of design intent: IDLE is, as its name says, a program development environment. Developed programs normally, and sometimes must be, executed by Python directly, without going through IDLE. Python normally runs attached to a terminal window. IDLE's Shell is based on a tkinter Text widget, which is a multiline editor, not a terminal. This is why one can enter, recall, and edit complete multiline statements rather than only a single line at a time.
I am working on a Tcl project where a certain procedure will run continuously. user can abort that procedure anytime using some Key-Combination. So basically, I need to trap the signal within Tcl code. So far, everything is done except one problem.
I am using Ctrl+Z i.e. SIGSUSP signal (SIGTSTP in case of Tcl) which technically does the job.
signal trap sigtstp onAbort
But, pressing Ctrl+Z immediately returns the Shell prompt, rest of the output from the program comes after that and when output comes to an end, no shell prompt returned (as it is already returned before). I need to press Enter again to get the prompt.
Following is the case I am refering to. You can see the prompt (polaris#ubuntu:~$) is returned in between output of the main program.
Also as output of pressing Ctrl+Z, it returned [40]+ Stopped, which is bit annoying. Can I avoid this ?
Can I avoid this whole problem using some other key-combination i.e. signal ? Or can I avoid this with Ctrl+Z also by tweking something ?
NOTE: I have tried using Ctrl+C. I got the exactly expected behavior with that. Unfortunately I can't use Ctrl+C as it is used for some other functionality.
Cz causes the shell to send the current foreground process a SIGSTOP(19). This signal cannot be caught or ignored and so your program will receive it and run the default handler. This is not killing the process as your question suggests you're trying to do. This only suspends it and you can bring it back into the foreground using fg on most modern shells.
Looks like you're out of luck. However, you might be able to rebind the keychord at the level of the shell. This is outside your program though and your end users don't have control over it. (Cf. https://superuser.com/questions/378018/how-can-i-do-ctrl-z-and-bg-in-one-keypress-to-make-process-continue-in-backgroun)
Also, if your program relies on user inputs for various actions (since you suggest that C-c does something else), perhaps you should make it a full fledged CUI application using curses or something?
In IDLE, there's no clear screen, and after reading the forums the best method is plainly to print a ton of "\n"s. However, after playing with IDLE, I made a discovery. When my game was waiting for an input after printing out instructions using print statements, instead of inputting any useful character, I entered 'control-z,' and IDLE began to remove the text that was display by the print statements, one by one.
My main question is, how do I manually in the code itself enter 'control-z', so I can utilize this functionality?
If you're confused by my story, here's some example code and try it yourself by hitting control-z.
print("Some Text")
print("More Text")
input("The Input (Hit Control - Z Here):")
^Z is a bit of a mess. The ascii control char ^D is usually interpreted as EOT, end of transmission, which on Unix and many other systems means end of file, close the application. Ascii ^Z is meant to be interpreted as SUB, substitute, whatever that means. Editors ofter use it as UNDO (meaning undo a ^X cut). Microsoft (and a few other old systems) at least sometimes interprets ^Z as end of file, with the same effect as ^D on *nix.
The Windows console closes a text app after ^Z . ^D is passes on to the app. IDLE, as a cross-platform app, closes on ^D. IDLE used to close on ^Z on Windows, but now, for me, it only erases the prompt. (I don't know if this alternative is intended.) I do not see the progressive deletion you report. What OS and what Python version are you running?
To answer your main question: you can't. input is usually used in assignment statements: string = input('prompt'). The way to imitate input statements is to directly assign 'user input': s = 'simulated user input'. However, this does not work for characters that get intercepted by the programs managing the input window and never sent to the python program.
IDLE's Shell generally imitates Python's interactive console. The latter (at least on Windows) makes everything, except the current input, read-only. Shell follows suite. Imitation is especially strict as regards executing user code. It is intended that user code tested in IDLE should run in Python without IDLE. It would be wrong for IDLE to clear the interactive shell in response to user code when Python cannot.
For editor and output windows, ^A (select all) followed by Backspace (delete), Delete, or ^X (cut) do clear the window.
Shell does, however, has more editing commands than many (most? all?) consoles and a menu system. These additions are allowed since they are interactive only and not accessible from user code. There have been various proposals and patches to enable clearing part or all of the shell window. https://bugs.python.org/issue6143 has some of the discussions and proposals.