Here's my issue. I'm outputting directly to console and also getting user input via the terminal. Sometimes, the user is typing a thing and then the text they were typing gets messed up when the console outputs something. It doesn't break the program, it's just annoying.
I looked at ncurses in the npm catalog, but it seems pretty complicated. All I want is to print stuff to the screen without disrupting user input.
Any help, and I do mean any help, is very much appreciated.
How are you reading from the terminal? If you're doing it in "raw" mode where you get input for each character (or each few characters), then when you get a character, set an "output inhibit" flag and also set a timeout that will clear the flag when the user has stopped typing for a bit. Whatever does your output needs to check the flag and hold off if it's set.
Alternatively, if the user is typing line-by-line, you could set the flag on each character and then clear it (and simply flush your output) when they enter a newline.
If the terminal is in "cooked" mode (your code doesn't see anything until the user types a newline) there's really little you can unless you bite the ncurses bullet.
Related
The script should treat 'enter' as sending the users string but instead it just prints '^M' to the terminal.
I'm not sure why this is happening suddenly, it wasn't happening yesterday. Something has changed about this particular terminal session because if I open a new terminal window it works as expected in that.
Any ideas?
I'm using iterm on Mac (xterm?)
TL;DR: just type the reset command on the OS shell whenever the terminal starts acting funny.
Terminal emulator programs (as iterm) feature complicated internal states in order to provide literally decades of features to allow prettier programs on the terminal.
Terminals started as keyboards that would physically print the typed text into paper, back in mainframe era - and "stdin" and "stdout" concepts: a single stream going forward with all data that is typed and another with all data that is printed out, are up to today, more than 50 years later, the default way to interact with the text terminal.
Internal state changes by programs that deal with the terminal in different ways (like being able to read a keypress without waiting for "enter"), should be reverted when the programs terminate. But due to errors and bugs that is not always the case.
I don't know which possible state would change "ˆM" to be displayed instead of a CR code being applied to the terminal. There are tens or hundreds of other possible misbehaviors, including completely messing up all characters. The reset command in modern *nixes (MacOS, Linux, BSDs) will fix everything.
Although, of course, if "enter" is not being applied, it won't be possible to issue the command at all from the os shell. You will have to start a new terminal session then. From within a Python program, if you happen to make a call to some code that will always break the terminal, you might run "reset" as a subprocess by calling os.system('reset').
In particular, "ˆM" represents "ctrl + M", which is a control character with value "13" (0x0d in hex). It is the value for the "Carriage Return" control code (AKA. "return", "enter", "CR"). If you never did this: try pressing "ctrl+M", and see that it behaves the same as "enter". It is being displayed in "human readable form" instead of acting as a control character in your case.
(regarding xterm and iterm: all they have in common is that they are both "terminal emulator" programs, xterm being one of the oldest existing such programs, which probably pioneered a lot of adaptations from text-only video modes to a graphic environment. "iterm" is just a normal modern app which implements terminal functionality)
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.
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.
I have a Tcl/Tk expect script, and log information is logged to external log file.
I can execute it on Linux server successfully without any wrong, and the log file do not have any weird ^H. But when the script is called by Jenkins job, run on the same Linux server. the log file will have a lot of ^H, And the expect will timeout.
What the possible reason could be?
The ^H is actually the backspace character, U+000008, and it is used in terminals (and terminal emulators) to move the current character insertion position one place to the left. This is used in turn to simulate various kinds of effects, such as making a character bold (by double-striking) or giving it an underline (by putting a _ on the same cell). Think like it's going to a traditional teletype, which prints things into the same position twice. It's definitely a hang-over from
the old days.
It seems that Jenkins (or maybe whatever it is calling, quite possibly maven though definitely not necessarily!) is using that device to back up over what it has written so it can write a new value there instead, probably for something like a simple download progress meter. Things that are writing to what they think is a terminal sometimes do this. You'll just have to cope. A \b in your Expect regular expressions will match it, though it is possibly unwise to do so, as whatever is being overwritten is transient info. If the characters are being written to a file, the col program (part of the nroff/groff suite) can be used to strip them; that might be easier.
Be aware that there are other ways that software can achieve the same effect, such as writing just a carriage return (which puts the cursor back at the start of the current line).
Warning: you know how they say "there's not such thing as a stupid question"? Well, this one is, or, I suspect it's really minor, but wth, why not ask. Search engines didn't bring me anything remotely useful, though that could be bad searchterm-fu.
I recently downloaded sqlite3 onto Ubuntu 10 to start learning SQL commands. I un-tar'd 3.7.12.01 and make installed.
After creating a test.db with create table test (id) I decided to see what I'd get if I cat it. Just because.
The result is an EOT character (u+0004) which is sitting right over my prompt. Illustrated screenshot: http://imgur.com/omfMa
I realise this is not the type of file you would use cat on. I only want to know, before I go further,
does the strange placement of this character signal any future issues when actually playing around with SQL, or some issue with newlines, or fonts (this is monofur set at a high font size) or similar?
I've never seen a result character placed directly over my prompt before.
The character is placed over your prompt, because it is a double-width character, and terminals in general are not good at handling double-width characters. It does not mean anything.
There are some control codes which can do very funny things with your terminal, such as changing colors, fonts etc.
But none of them do really harm - you should be able to reset your terminal to a healthy state, or close it and open a new one.