Sometimes, I print data with special characters. After that my terminal looks like this:
As you can see, it is useless to clear the terminal.
Is there any way to get back to normal after special characters were printed except for closing the terminal and opening it again?
When you see such a mess on the screen reset command is your friend. Basically it will reset all special characters to their default values and re-initializes your terminal. Most probably you have this command in the system under /usr/bin directory as a link to tset.
If for any reasons reset is not present then you can run echo -e \\033c where \\033c is a special code, which should be read as ESC c.
You can even clean your terminal from other terminal with a little help of cat command. For example if your problematic terminal resides on /dev/pts/3 then run the following sequence:
$ cat >/dev/pts/3
ESC c, ENTER, Ctrl-D
and /dev/pts/3 should be cleaned up.
Related
Please,
I have a terminal application that requires no echoing of control characters back to the terminal.
I can happily issue 'stty -echoctl' at a terminal, run my application and obtain the result I am after. Further, I can include 'stty -echoctl' in .bashrc and everything is fine. (I have also added it to .profile but that seems to bring in .bashrc anyway)
I can then open another terminal (type 'konsole/gnome-terminal/xterm' in the original console and again I get the result I expect.
The problem I have (and this is in preparation of forking the program form another application) is that if i try
$ xterm -e ./V2.13
or even
$ xterm -e bash -c ./V2.13
the control characters are in fact echoed back to my app.??
EDIT:Additionally is there any need (benefit) in executing bash to execute my application ?
Sometimes when you ctrl-v with bash it will run the command even though you didn't intend to run it yet - is there a way to paste a command into the bash shell / terminal making sure you don't actually run any of the command(s)?
if you could set what was on the terminal prompt programmatically, you could do this with bash on MacOS:
export BASH_PROMPT="$(pbpaste)"
which ties into my other question that I just asked:
How to change the value that's in the prompt
There is a Readline variable:
enable-bracketed-paste
When set to On, Readline will configure the terminal in a way that will enable it to insert each paste into the editing buffer as a single string of characters, instead of treating each character as if it had been read from the keyboard. This can prevent pasted characters from being interpreted as editing commands. The default is off.
To turn this on, put something like
set enable-bracketed-paste on
into your ~/.inputrc.
This was introduced in Bash 4.4 / Readline 7.0.
Use ^X^E aka Ctrl+X Ctrl+E in bash to open your $EDITOR for command entry.
Paste and/or edit as much as you want, across as many lines as you want. When you're done, save and exit, and bash will run it.
(In vi mode, the shortcut is v)
Whenever I enter a terminal command in vim (e.g., !echo hello), I am momentarily kicked out to view the result of that terminal command and then prompted with Press ENTER or type command to continue. This is a bit jarring. I would like to stay within vim and with the command output printed out at the bottom.
I know vim :read will take the terminal output and actually put it into my buffer, but that is not what I am looking to do. Here is some reading if you are interested in a tangent.
It looks like when I run vim in Screen I get what I am looking for, but I am trying to get this to work with tmux and the stock Mac terminal.
After a ton of research, probably too much, I got it! It looks like vim will send commands to the terminal, which in turn defines the behavior of how the terminal commands are processed from vim. Put this into your .vimrc file:
set t_ti= t_te= " show results from terminal commands within vim!
From what I understand, this just makes sure to send nothing to the terminal, which yields my desired results!
Side note: the above addition to your .vimrc file will also prevent the vim buffer from clearing when exiting vim (e.g., :wq). I am okay with this! It is kind of nice sometimes to see what you were just working on :).
When using zsh, I sometimes accidentally press Escape out of habit, expecting it to clear the entire line as it does in Windows. Instead, it goes into a mode that I'm not sure how to get out of. The cursor goes back one character, and some keys perform some special commands, but all I really want to do is get out of this mode and be able to press Ctrl+U to clear the line.
Searching around has been tough - I get results for escaping characters.
Short answer: press a.
Medium answer: press a, then enter bindkey -e.
Long answer: Like a lot of UNIX shells, zsh has an emacs-like mode and a vi-like mode. You're in vi-like mode, and ESC takes you out of the vi-like insert mode. a puts you back into insert mode, with the cursor after the current character. (Sorry for the two different uses of "mode," but it is the accepted terminology in both cases.)
bindkey -e overrides the settings from the rc files and puts zsh into emacs mode, which only has one mode (i.e., no "ESC mode"), so this won't bother you any more. Unfortunately, it won't carry over to your next shell invocation. bindkey -v would switch from emacs mode back to vi mode.
In the absence of any other configuration, zsh defaults to emacs mode, so unless there's something in one of the rc files, the likely culprit is that the EDITOR variable is some form of vi, which causes zsh to default to vi mode. If you don't like vi mode, then you should probably hunt down what part of the system-wide or user-specific configuration is causing zsh to default to vi mode and turn it off by removing it or overriding it in one of those rc files.
If everything else fails, when you're in ESC mode, type :w then Enter to save, and then :q to exit. You can also type :wq and Enter
I tried this just now:
grep -RlI "id=\"kw\"" * | xargs vim
That gave me 16 results. It opened the first result in Vim. I made my very first edit and hit :q since I didn't know the shortcut to jump to the next file.
It threw me back to the console ( I am SSHed in to a server ). My console is messed up now. Anything I type I can't see, and anytime I hit enter it seems like it processes the command but the display/view is screwed up so
[meder#linode] is tabbed in on my console, at least halfway. reset does nothing since it seems to have messed up my real console.
Can anyone offer a solution that doesn't have this same downside? Or can anyone provide an explanation for why :qing out of the very first file messed up my console?
Background information: My PC is Debian Ubuntu, I am SSHed into a RHEL box. The files I opened were text/ascii files phtml/php files and not some weird binary files with crazy characters in them.
Here's a screenshot of what happened
EDIT #1: I just typed reset again and it seemed to work. The first reset did not work I think because somehow the console inserted some whitespaceish character inside it? Anyways, I would like an explanation for this weird behaviour.
Try:
vim -o `grep -RlI "id=\"kw\"" * `
From the man page for xargs:
Undefined behavior may occur if utility reads from the standard input.
That line isn't in the Linux man page but it is present on my Mac. If you want to run a program that you intend to read standard input, the usual linux version of xargs will need an argument to read its input from a file:
OPTIONS
--arg-file=file, -a file
Read items from file instead of standard input.
If you use this option, stdin remains unchanged
when commands are run. Otherwise, stdin is
redirected from /dev/null.
Vim is intended to run with both standard input and standard output connected to real (a very rare case these days) or pseudo tty devices. Wierd things will happen if you upset this arrangement.
The fundamental problem with your command was that, with standard input redirected to the pipe, xargs had no way to run a vim with a "normal" standard input. So the vim mode changes and command input were not what you expected.
You can probably fix this by typing a return, a tilde, and a period. This will force your ssh session closed from your end, you can then ssh in again, and run "ps" to check for anything left hung in the background that you should kill(1).
You can use :next or :n to get to the next file to edit. You can also use vim -o to open up all the matching files in different windows in Vim.
Not sure why your console is messed up though. I tried using your command and my console was fine.
Console options are set by stty, so you may want to save its options to a bash variable and restore them after vim exits, like this:
function vim()
{
STTYOPTS="$(stty --save)"
vim "$#"
stty "${STTYOPTS}"
}
But it is probably the better way to use zsh for this task: if you put the only line ttyctl -f into your ~/.zshrc, then zsh will automatically restore terminal options after program exits. ttyctl is a zsh builtin, so you cannot use it from bash.
Other folks covered what happened and what to do about it. As to why, the answer to that probably lies in what input Vim received from the xargs command and tried to execute as if that input came from a terminal. I don't know how to talk terminal, but you can imagine that Vim got some strange commands that crashed it or told it to quit. Similarly unpredictable things happen when you cat a binary file.
Anway, I have another idea. Have you tried using vimgrep to browse a list of files matching a pattern?
:vimgrep /id="kw"/ *
:copen
This greps for id="kw" in all files in the current directory. :copen opens up a window with a list of matches. You can browse that list, clicking enter to jump to a file position.
For more information, see
:help grep
:help :vimgrep
:help :copen
:help quickfix
If you really need that -I option, see
:help :grep
:help 'grepprg'
See also: Vim: Warning: Input is not from a terminal
Try to use ... | xargs sh -c '...' and then read from the controlling terminal device /dev/tty.
echo ~/.profile ~/.bashrc | xargs sh -c 'vim "$#" </dev/tty' dummy_script_name
# based on a tip by Laszlo Ersek on http://unix.derkeiler.com/Newsgroups/comp.unix.programmer/2010-03/msg00051.html
#find . -maxdepth 1 -type f | xargs sh -c 'rm -i "$#" </dev/tty' dummy_script_name