Open up irb and
type gets. It should work fine.
Then try system("choice /c YN") It should work as expected.
Now try gets again, it behaves oddly.
Can someone tell me why this is?
EDIT: For some clarification on the "odd" behavior, it allows me to type for gets, but doesn't show me the characters and I have to press the enter key twice.
Terminal input-output handling is dark and mysterious art. Anyone trying to make colorized output of bash work in windows PowerShell via ssh knows that. (And various shortcutting habits like Ctrl+Backspace only make things worse.)
One of the possible reasons for your problem is special characters handling. Every terminal out there can type characters in number of different modes, and it parses its own output in search for certain character sequences in order to toggle states.
F.e. here one can find ANSI escape code sequences, one of possible supported standards among different kind of terminals.
See there Esc[5;45m? That will make all the following output to blink on magenta background. And there is significantly more stuff like that out there.
So, the answer to your question taken literally is — your choice command messes something with output modes using special escape sequences, and ruby's gets breaks in that quirk special mode of terminal operation.
But more useful will be the link to HighLine gem documentation. Why one might want to implement platform-specific and obtrusive behavior when it is possible to implement the same with about 12 LOC? All the respect for the Gist goes to botimer, I've only stumbled into his code using search.
Related
I don't understand how to create custom escape sequence for Ctrl+Shift+S like in this question
My problem is that I want to use Ctrl+Shift+S in emacs no-window mode under MacOS terminal. Currently I'm trying to bind this escape sequence to Ctrl+Shift+F12 but I have troubles creating that escape sequence. Maybe there is a batter way to use complex (Ctrl-Shift+anykey) bindings in MacOS terminal with emacs in no-window mode?
You're probably assuming that F12 is a character. It is not. Conventionally, function keys send a sequence of characters.
In Terminal's preferences screen, you can review (most of) the key bindings:
You can also add a key definition (after deciding what characters it ought to send), and associate the Shift and Control modifiers with that key:
For the sake of example, I used the sequence that xterm would send. However, Terminal is not the same as xterm, and you may find other sequences more interesting.
Regarding the related question "What is the correct escape code for control/shift/s": there is no correct escape code because terminals (unless specially configured as illustrated above) do not distinguish between shifted- and unshifted-control characters. To determine what is "correct", you will have to examine your emacs bindings to see what you should send to make it recognize the function you are asking about.
I just want to be able to run a python script from the interpreter, so that I can work on my changes to my script in notepad or other editor, save, and then interactively test changed code in the python interpreter.
Also, IDLE is not a solution. I'm operating on a government computer that is blocking the port it uses to communicate interaction between console and module.
To clear up any confusion, here's a demonstration of what I'm trying to do:
So, how do I do it?
EDIT:
Okay so I found a statement that does what I want. exec(open('dir').read()). The problem I think is that the directory I want to refer to contains periods. But I'm sure this will work, because open('dir').read() produces a string of the contents of a document specified, as long as I reference the likes of C:\myTest.py, and exec() obviously runs strings as input. So how can I reference files from the location I want?
Okay so the problem seems to be that Windows addresses often contain what python sees as 'unicode exits'. I'm not sure what they do or how they work, but I know they start with \ and are followed by a single letter and that there are enough of them to use up half the alphabet. There are a few solutions but only one is worth a damn for this application. I came across an operator that can be used in conjunction with strings, similarly to how + can be used to concatenate multiple strings, it seems r or R if you prefer (interestingly), can be used immediately before a string to tell the interpreter to take the string 'literally' as a string, and nothing else.
One would think that the quotes would be enough to express this, but they aren't and I'll probably eventually find out why. But for now, here's the answer to my question. I hope someone else finds it useful:
In plain text: >>> exec(open(R'C:\Users\First.Last\Desktop\myScript.py').read())
As far as I can see, in Konsole both CTRL+ENTER and ENTER look like byte 13 in the stdin of the running app. But when I run mc which obviously uses ncurses lib, pressing CTRL+ENTER inserts the name of the file into the command line while ENTER opens the file. How is it implemented? I tried to look into sources, but they are totally unreadable for me.
mc (midnight commander) doesn't use ncurses for input, but may use it for output. Essentially it is looking for specific character sequences.
mc makes little use of the terminfo database, essentially only to check on the xterm mouse- and alternate-screen features.
In principle, it could read the user-defined capabilities from the ncurses terminfo database (see for example ncurses trapping extended keys (Control-left, Shift-Function etc)), but it does not.
Since you are looking at sources, see the source of mc, in lib/tty/key.c, which contains tables which mc uses as a set of predefined keys. Doing it that way "works" when mc is configured to use slang, for instance, though it has the drawback that it's hardcoded and may not actually match your terminal.
However - as I said, mc does its own input. Further down in key.c, you may see a chunk in get_modifier() ifdef'd with HAVE_TEXTMODE_X11_SUPPORT. Inside that is a call which ultimately goes to XQueryPointer, which mc uses to find the current state of the modifier keys — if it happens to be running in an X display, and if the feature is enabled. You are probably seeing that.
I'm currently in the process of planning out a custom Vim-like editor. It's going to be written in C and I want it to be as portable as possible between as many types of systems as possible.
I'm aware of curses (ncurses, I suppose), the tput command, and how terminals use control sequence (Esc-[ and the CSI character) to change backgrounds, move the cursor, etc.
Of the options above, it seems like ncurses would be the most recommended way of printing for the editor. BUT ncurses also has a LOT of stuff that I rather wouldn't use, and if it's reasonably feasible I'd rather make my own system. I'm not against using it, but .. anyways.
So, my question is: Is there any way to use control sequences in the vast majority of terminals without using a library? Whether through tput or another method?
Thanks!
tput(1) uses the terminfo(5) (or older termcap(5)) database, which provides the mapping from abstract commands such as move cursor to x,y to escape sequences for different terminals. When you run a command such as
$ tput cup 10 3 # move cursor to row/column 10/3
, the terminfo database is queried to find the correct string for your terminal, which is then simply written to stdout. To find the available commands (e.g., cup), look at the cap-name column in terminfo(5). tput determines what terminal you are using by looking at the TERM environment variable.
(This means that you can check what escape characters are being generated by simply doing $ tput [command] > [file] and opening [file] in some editor that can show control characters, which can be handy for exploration. The infocmp(1) command can also be used for this.)
If you use tput (or the underlying tputs(3)), your program is hence automatically portable to different terminals. This is what Vim uses by the way.
However -- in the modern world, pretty much all terminals (or terminal emulators rather) use ANSI escape codes, along with some extensions (see XTerm Control Sequences). I believe the escapes supported by xterm and their behavior have become something of a de facto standard at this point, with other terminal emulators simply copying xterm's behavior. Some text-based UI libraries like termbox seem to do away with support for non-ANSI terminals altogether, and output ANSI escapes directly.
Besides the already-mentioned termbox, there's also S-Lang, which includes a terminal handling component. I believe those are the two most popular "ncurses replacements". I'd give ncurses some time first though.
I'm trying out the coffee script repl inside Emacs (under ArchLinux) and I'm seeing these escape characters surrounding the prompt:
[1Gcoffee> [0K[9G
These shouldn't be colors as I already enabled the ansi-color-for-comint-mode. So does anyone recognize these?
P.S.: Funny thing is I don't have this issue under my Emacs+Cygwin setup!
I don't know where they're coming from (something to do with your shell prompt, obviously, but it's hard to say more than that).
I read them as:
ESC[1G - Move to column 1 (Cursor Character Absolute)
ESC[0K - Erase to right
ESC[9G - Move to column 9
It looks like an attempt by the shell to ensure that the prompt is at the far left of an empty line. Not sure what shell you have, but zsh does something similar when the PROMPT_SP option is enabled. I don't think it uses the above sequences, though.
Many, many, control sequences can be found here. Note that the sequence "ESC[" is interpreted as a "Control Sequence Introducer" (CSI) and is shown as that on that page.
I had the same problem and was able to solve it by adding
export NODE_NO_READLINE=1
to my .bashrc file.
So, the characters appear to have come from the CoffeeScript REPL's use of Readline. Perhaps the reason you didn't have the issue in Cygwin was because Readline wasn't available there.