xterm escape codes for some things sometimes screwy
Every now and then, I don't release the shift key in time before pressing <enter> in a terminal, and it just works and I don't cry. Sometimes, after running *something* that I haven't identified yet, it doesn't just work - it craps out and puts in some escape sequences: goodterm> cat -v <shift-enter> badterm> cat -v <shift-enter> ^[[27;2;13~ Anyone know how to restore the previous mappings and/or identify what screws it up (presumably some damn ncurses crap)? -- Tim Connors
On Sat, May 25, 2013 at 10:44:09AM +1000, Tim Connors wrote:
Sometimes, after running *something* that I haven't identified yet, it
possibly something that output a Ctrl-O to switch to the "alternate" character set. Printing ^O again will switch it back.
Anyone know how to restore the previous mappings and/or identify what screws it up (presumably some damn ncurses crap)?
typing "^V^O<RETURN>" in a bash shell often fixes it when bash prints "bash: ^O: command not found" (where ^V and ^O are Ctrl-V and Ctrl-O respectively) echo -e "\0017" works just as well. or any other method of outputting a Control-O running "reset" is also useful, and "stty sane" too, especially if the terminal is in non-echoing mode. i usually do all three in that order when my terminal goes weird (e.g. from accidentally catting a binary file) craig -- craig sanders <cas@taz.net.au> BOFH excuse #216: What office are you in? Oh, that one. Did you know that your building was built over the universities first nuclear research site? And wow, aren't you the lucky one, your office is right over where the core is buried!
On Sat, 25 May 2013, Craig Sanders wrote:
On Sat, May 25, 2013 at 10:44:09AM +1000, Tim Connors wrote:
Sometimes, after running *something* that I haven't identified yet, it
possibly something that output a Ctrl-O to switch to the "alternate" character set. Printing ^O again will switch it back.
Anyone know how to restore the previous mappings and/or identify what screws it up (presumably some damn ncurses crap)?
typing "^V^O<RETURN>" in a bash shell often fixes it when bash prints "bash: ^O: command not found" (where ^V and ^O are Ctrl-V and Ctrl-O respectively)
echo -e "\0017" works just as well. or any other method of outputting a Control-O
None of the above in this case (and of course, stty sane I had tried too) (I hope my dynamic resetting of PROMPT_COMMAND and writing things to the terminal windowtitle and icon title values doesn't end up toggling ctrl-O an even number of times - I did try to temporarily unset my automatic voodoo)
running "reset" is also useful, and "stty sane" too, especially if the terminal is in non-echoing mode.
But reset worked, thanks. I wonder if there's a less drastic (ie, no screen & history clear) subset of what reset does that would help me. Unfortunately, I don't know how to toggle this xterm back into a fault state (since ctrl-O isn't working for me) to test.
i usually do all three in that order when my terminal goes weird (e.g. from accidentally catting a binary file)
Or the cat accidentally catting on the keyboard. -- Tim Connors
On Sat, May 25, 2013 at 03:43:53PM +1000, Tim Connors wrote:
(I hope my dynamic resetting of PROMPT_COMMAND and writing things to the terminal windowtitle and icon title values doesn't end up toggling ctrl-O an even number of times - I did try to temporarily unset my automatic voodoo)
dunno, PROMPT_COMMAND is one of the things i disable from debian's .bashrc files. along with purging the bash-completion and command-not-found packages. some people like them but i find they're far more annoying than useful. command-not-found because it's verbose and i mistype things like ls as sl often enough to find it annoying; and bash-completion because i find the restrictions imposed by command-specific completion rules to be worse than the benefits (i.e. i'm happy with just default filename completion) - and quite often the rules are broken and I can't force it to complete a filename with an extension the broken rules don't like. worse, all three slow down my shell. that's just unforgivable.
running "reset" is also useful, and "stty sane" too, especially if the terminal is in non-echoing mode.
But reset worked, thanks. I wonder if there's a less drastic (ie, no screen & history clear) subset of what reset does that would help me. Unfortunately, I don't know how to toggle this xterm back into a fault state (since ctrl-O isn't working for me) to test.
depends on the terminal emulator - i reluctantly switched from mrxvt (excellent, but no unicode support) to roxterm (best of the libvt terms) and it has right-click menu options for "Reset" and "Reset & Clear". others might have similar. craig -- craig sanders <cas@taz.net.au> BOFH excuse #270: Someone has messed up the kernel pointers
Craig Sanders <cas@taz.net.au> writes:
and i mistype things like ls as sl often enough to find it annoying;
There is a specific fix for that particular typo: apt-get install sl :-) IIRC command-not-found, when installed, is enabled host-wide, rather than in /etc/skel/.bashrc, so to disable it on shared hosts I have # Ignore Ubuntu's attempt to slow exit(127) to a crawl. unset command_not_found_handle TimC, I wonder if identifying what the escape sequences that are emitted *do* would help isolate what caused them to be generated. (I don't recognize them offhand myself, and I'm not sure how to tput-in-reverse.)
On Mon, 27 May 2013, Trent W. Buck wrote:
TimC, I wonder if identifying what the escape sequences that are emitted *do* would help isolate what caused them to be generated. (I don't recognize them offhand myself, and I'm not sure how to tput-in-reverse.)
I do wonder whether it's emacs on a terminal (perhaps terminating abruptly and not restoring terminal defaults - or perhaps gnuclient being suspended or something like that). Because emacs knows all about that keybinding: http://lists.gnu.org/archive/html/bug-gnu-emacs/2013-02/msg01402.html http://emacs.1067599.n5.nabble.com/bug-13839-xterm-mintty-control-sequences-... googling surprisingly returned at least some slightly relevant results: "^[[27;2;13~" xterm So it's happened at least one other time since I sent the original mail. xterm's ctrl->middle_click->soft_reset worked to reset the keybinding, obviously without resetting my screen history. Now I just have to work out why it got into that mode in the first place, and how to get a softer `reset` command. -- Tim Connors
On Mon, 27 May 2013, 11:21, Tim Connors wrote: } So it's happened at least one other time since I sent the original mail. } xterm's ctrl->middle_click->soft_reset worked to reset the keybinding, } obviously without resetting my screen history. Now I just have to work } out why it got into that mode in the first place, and how to get a softer } `reset` command. "tput reset" seems like a softer version of reset... would that work? T.
On Sat, May 25, 2013 at 03:43:53PM +1000, Tim Connors wrote:
On Sat, 25 May 2013, Craig Sanders wrote:
On Sat, May 25, 2013 at 10:44:09AM +1000, Tim Connors wrote:
Sometimes, after running *something* that I haven't identified yet, it
possibly something that output a Ctrl-O to switch to the "alternate" character set. Printing ^O again will switch it back.
Anyone know how to restore the previous mappings and/or identify what screws it up (presumably some damn ncurses crap)?
typing "^V^O<RETURN>" in a bash shell often fixes it when bash prints "bash: ^O: command not found" (where ^V and ^O are Ctrl-V and Ctrl-O respectively)
echo -e "\0017" works just as well. or any other method of outputting a Control-O
None of the above in this case (and of course, stty sane I had tried too)
(I hope my dynamic resetting of PROMPT_COMMAND and writing things to the terminal windowtitle and icon title values doesn't end up toggling ctrl-O an even number of times - I did try to temporarily unset my automatic voodoo)
running "reset" is also useful, and "stty sane" too, especially if the terminal is in non-echoing mode.
But reset worked, thanks. I wonder if there's a less drastic (ie, no screen & history clear) subset of what reset does that would help me. Unfortunately, I don't know how to toggle this xterm back into a fault state (since ctrl-O isn't working for me) to test.
This is an X thing. Some X program has re-mapped the action of the Cr keycode when augmented by Shift to send an escape sequence. Ncurses can't do this, and so can't undo it either. Reset works because xterm goes back to its initial keycode mappings. Keep an eye on which X (i.e. GUI) programs you run from your xterm to see if you can correlate which one causes the problem. Cheers ... Duncan.
i usually do all three in that order when my terminal goes weird (e.g. from accidentally catting a binary file)
Or the cat accidentally catting on the keyboard.
-- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html
participants (5)
-
Craig Sanders -
Duncan Roe -
Tim Connors -
Tony Crisp -
trentbuck＠gmail.com