when I sshed into another machine in xterm, the character I deleted by either backspacce or ctrl+k, remains on the screen. but physically they have been deleted, as when you exectue the script, the machine responds in a way that the delete has conducted. The only way to display properly is to let the cursor moving through the deleted words, either by space or typing other characters.
Same thing applies when you using vim. specifically after page down, the screen displays a overlap between the previous page and current page.
The screen displays properly without ssh.
I am using gentoo with the following compile flag (if it is related).
[ebuild R ] x11-terms/xterm-314 USE="openpty truetype unicode -Xaw3d -toolbar" 0 KiB
Sounds like a locale problem. Some Linux's by the way honor an stty -iutf8 setting, and others may not. Either that, or a difference in locale settings on the local and remote machines is the first place to check.
Thomas's answer led me to a solution for this very same problem. My LANG environment variable was incorrectly set on my local machine. For my case,setting LANG=en_US.UTF-8
fixed the problem.
Related
I'm trying to make a bash script that behaves differently based on the terminal program that someone is using (Putty, mobaxterm, etc). Is there any way to retrieve this kind of information from a bash script?
I was searching around online but I was not able to find anything (or I'm just wording it incorrectly, which could be a distinct possibility).
thank you
You need to understand that these are terminal emulators. There is a simple, crude identification function for (most?) modern line terminals (now that's an oxymoron!) but it will return something like vt102 or xterm i.e. whatever the emulator is emulating; not the identity of the program performing this emulation. Incidentally, this is usually used when the session is initiated, and reflected in the value of the $TERM environment variable.
The common way to do this is the environment variable TERM. Try
echo $TERM
That should output the terminal emulator's type, indicating its capabilities. Often, though not always, the value of TERM will be the name of the terminal emulator. For example, xterm may set TERM to xterm, or to xterm-color, depending on configuration.
Note that the user can change this variable, so it may contain something completely different.
That said, if you want to do fancy things with the terminal from a script, you don't need to build support for different terminals by hand. There are various libraries that offer all the usual functions (clear terminal, resize window, change font etc.). The most popular one is terminfo; there are various packages that build on terminfo.
This is a very specific issue but, based on what I've seen online, a surprisingly common one. I'm on a rather old version of Scientific Linux 5, which is based on Red Hat. I use vim with the Solarized vim color scheme, and my TERM environment variable is usually set to xterm-256color. This worked fine until I started using tmux. On non-empty lines in vim, the color scheme only extended to the end of the document's characters, the remaining whitespace being plain back background.
The stock fix for this in online guides is to set TERM='screen-256color'. However, upon doing this I would get the ominous warning: WARNING: terminal is not fully functional - (press RETURN), when trying to do innocuous things like read man pages. However, everything seemed to be working fine, and the Solarized bug was fixed.
I've found a functional fix - using TERM='xterm-256color' by default and adding this line to my .bashrc:
alias v='function _vim(){ TERM='screen-256color'; vim $1; TERM='xterm-256color'; };_vim'
but it seems like a hack. Anecdotally, I've also set alias tmux='tmux -2', which is a common suggestion with color-scheme-related issues.
I also know that the terminfo screen-256color is available on my machine.
So, really, the main befuddling thing is that, when using TERM='screen-256color', I'm getting those warnings about full functionality when nothing seems to be wrong.
I don't have root access, so ideally any fix suggestions wouldn't need that.
EDIT: I should mention that TERM='screen-256color-bce' gave the same problems as TERM='screen-256color'.
The user's environment is not specified, but likely using bash and less (Scientific Linux 5 does not have more).
The package list on Scientific Linux 5's ftp site, shows ncurses-5.5-24.20060715.src.rpm, which does not include screen-256color (it was added to ncurses in October 2006). That system might have the later terminal database by some post-install change.
An application using termcap would not see this terminal description. Scientific Linux's bash and less programs could have used termcap rather than terminfo. A quick check of the changelog for bash-3.2-21.el5 says
* Fri Feb 1 2008 Miroslav Lichvar <mlichvar#redhat.com> - 3.2-21
- Link with libtermcap
On some systems, a missing termcap entry will cause a warning. But with Scientific Linux 5, the given warning message comes from less, which checks its terminal description (using the termcap interface), to ensure that it can clear the remainder of the current line, the remainder of the screen and the entire screen.
In Scientific Linux 5, the less package is built with ncurses. A problem with less using TERM=screen-256color would be one of these possibilities
the screen-256color entry is not really installed, or
there is some problem with the termcap interface provided by ncurses.
While there were ongoing performance-fixes for the screen program around this time, the former seems the more likely, as seen in this discussion of a poorly-written entry for screen-256color in early 2006: Re: screen-256color terminfo entry?. What I get from reading this is that there was some poorly-written terminal description (not part of ncurses) which produced the problem. By the time it was proposed for inclusion in ncurses (October 2006), the problem had been repaired. In any case, it would have been corrected at that point.
I am attempting to fill my keyboard with more bindings for tmux and vim, and I thought about using Ctrl+1, Ctrl+2, etc.
In tmux Ctrl+4 caused it to create a vertical split, which was interesting, then I tried it outside of tmux inside of cat and got this:
% cat
^#^[^\[1] 5730 quit (core dumped) cat
Here I typed Ctrl+1 (produced no output), Ctrl+2 (^#), Ctrl+3 (^[), and Ctrl+4 after which point it promptly died like this.
Now I will say that I have Ctrl+\ bound to vertical split in tmux, so that makes sense, but at this point I'm wondering why these bindings are like this. I fear that it means I can never distinguish e.g. Ctrl+3 from the Esc key.
There's not a real definite answer. It's all based on the operating system you're using. For example, I'm using Ubuntu 12.04 on one computer, and its key bindings are different than what I have another system with an older version that I keep as a server.
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.
Next week I am getting an exam on using basic commands and shell scripting using terminal in Ubuntu. Please help me out with two quick questions:
-Does a practice environment for the Ubuntu terminal exist? I don't want to dual boot with Linux, so I want to find somewhere I could practice using some basic terminal commands as Cygwin seems to be quite different from the ubuntu terminal.
-What does the col command in Linux do? The manual page is here: Link, but I find that hard to understand, and since it doesn't work in Cygwin, it's hard to interpret! Also, why would one use man piped to col -b -x?
Thank you very much and sorry for the probably silly questions!
You can use the Ubuntu LiveCD boot (boots up an Ubuntu system without actually installing it) and experiment with the Ubuntu terminal shell. Its actually the same CD as the standard Ubuntu installtion CD... you just chose "Try Ubuntu" instead of "Install Ubuntu" once it boots up:
https://help.ubuntu.com/community/LiveCD
col is program to filter out reverse-linefeeds (i.e. the backspace character) from text input. In the olden days of line printers, a common method to achieve boldface print was to print a character, then print a backspace character, then print the character again. This would make the printer strike the character twice in the same place. Some programs would emit text files formatted in this way (man is one such program)-- but if you then tried to display that text file to your terminal screen, you might end up seeing something like this: "here is b^Hbo^Hol^Hld^Hd text".
col -b simply filters text input to strip out those extra backspace and double-strike characters. The -x option converts tab characters to space characters, which might be useful if the output was formatted for a device with a particular tab width, but then displayed on a different device.
man pages often have the backspace/double-strike text embedded in them, so man piped into col was often useful.
Nowadays, most terminal emulators actually know how to handle the backspace/double-strike, so col doesn't get used as much.
Far better (easier to use, install, maintain, etc.) than Cygwin, and perhaps less resource-using than a virtual machine, is http://andlinux.org . That will give you a shell on your Windows desktop, and you can play with the col command to better understand it.
Win-bash is essentially the same shell as linux, but on windows. You can use this to experiment outside Linux but I'm not sure how effective it is.
Other options are virtual machines, and if you don't mind a reboot, you can install ubuntu with wubi which means it can be deleted from windows' add/remove programs when you are done with it. (Or just use the live disc)
Col has very limited use for most people, it only affects programs that write lines asynchronously as opposed to line by line...