I am running a machine with SunOS and NO graphical enviroment. Does someone know how to change the keyboard layout from the console??
Thanks
Select your layout
Type the following command to select your layout from a list:
kbd -s
If your language isn't in the list, have a look at this blog post on how to create your own layout. You might have to take a look at this if you have a non-standard (e.g. Apple) layout.
Reload your keymap
Reload your keyboard translation table with the following command:
loadkeys
The change should persist through reboots, unless you're using an in-memory OS like SmartOS
have a look at the loadkeys command
If it's running a recent Solaris 10 update release or patch set, or a release newer than Solaris 10 (such as Solaris Express or OpenSolaris), try kbd -s -- on older Solaris x86 releases, try kdmconfig.
From Keyboard Layout on the Console
To view the current console keyboard layout setting:
$ nlsadm get-console-keymap
keymap=US-English
To list available values for the console keyboard layout setting:
$ nlsadm list-console-keymap
Arabic
...
To set the console keyboard layout to Japanese:
# nlsadm set-console-keymap Japanese
See also:
man nlsadm
Change the LAYOUT value in /etc/default/kbd (use kbd -s to get a list of allowed values). Then run kbd -i and finally reboot.
Related
Why does tmux change the terminal from xterm to screen, and how can I fix the resulting text color change in emacs? I think the easiest way would be to prevent it from changing to screen in the first place.
I can use TERM=xterm emacs file.ext to do it temporarily, but that's just a workaround that doesn't solve the root of the problem.
Furthermore, the function keys no longer work in emacs when using tmux. Instead of F3 and F4 being macro shortcuts, they just print a tilde as they would in the shell. This seems unrelated to xterm/screen mentioned above. What is happening here, and how I can fix this?
tmux sets TERM to screen because that terminal description is limited to things that tmux knows how to work with. Like screen, tmux translates features from the outer terminal description to the inner.
If a special key (function-key, cursor-key, etc) does not have an exact match in the terminal description, tmux will ignore it.
The default configuration for PuTTY sends different escape sequences for F1-F4. The sequences which PuTTY sends are not in the terminal description for xterm.
Here's a comparison of the two (as a CSV file, but readable enough):
NAME,putty,xterm
kf1,\E[11~,\EOP
kf2,\E[12~,\EOQ
kf3,\E[13~,\EOR
kf4,\E[14~,\EOS
kf5,\E[15~,\E[15~
kf6,\E[17~,\E[17~
kf7,\E[18~,\E[18~
kf8,\E[19~,\E[19~
kf9,\E[20~,\E[20~
kf10,\E[21~,\E[21~
kf11,\E[23~,\E[23~
kf12,\E[24~,\E[24~
kf13,\E[25~,\E[1;2P
kf14,\E[26~,\E[1;2Q
kf15,\E[28~,\E[1;2R
kf16,\E[29~,\E[1;2S
kf17,\E[31~,\E[15;2~
kf18,\E[32~,\E[17;2~
kf19,\E[33~,\E[18;2~
kf20,\E[34~,\E[19;2~
You'd have trouble getting PuTTY to send F13-F20, but will certainly run into trouble using PuTTY and tmux with TERM=xterm.
Regarding colors, the same issue applies. The screen terminal description tells applications that the terminal can support 8 colors, and tells how to display those eight colors. If your external terminal can do more, then tmux and screen hide that.
The conversion is not perfect. GNU screen has a feature where it looks for a corresponding screen.$TERM terminal description (i.e., concatenating the outer TERM value to screen). tmux does not do that: it makes assumptions regarding xterm. But PuTTY is not xterm...
ncurses has several of those concatenated terminal-names for terminal descriptions, but no one has suggested a way for tmux to use them automatically.
When I open files with emacs it adds 12;rgb:1c1c/1c1c/1c1c on the top. How can I prevent this?
I have installed emacs on a clean reinstalled debian system.
Emacs: GNU Emacs 24.4.1
Terminal Emulator: MobaXterm Personal Edition v7.7
System (local): Windows 7 Ultimate
System (remote): Debian 8.0 "jessie" stable
As noted, "MobaXterm" is not "xterm". According to its webpage it is
Based on PuTTY/MinTTY with antialiased fonts and macro support
Lacking a detailed change history, and the problem reported by the OP, it seems that MobaXterm is based on PuTTY from a while back, and does not implement all of the control sequences which PuTTY does, much less those of xterm.
The particular sequence which is not recognized (referring to XTerm Control Sequences) may be this:
OSC Ps ; Pt ST
OSC Ps ; Pt BEL
...
Ps = 1 2 -> Change text cursor color to Pt.
That is part of a group of controls predating ANSI color support in xterm, referred to as dynamic colors.
Based on comments in other places, it seems that the problem could lie within the OP's Emacs configuration, by using scripts which do an ad hoc test of TERM to decide if it can do colors, rather than inspecting the terminal capabilities. See Terminal emacs colors only work with TERM=xterm-256color where someone worked around this problem by modifying their init.el to add special cases for rxvt and xterm.
Emacs of course is capable of doing colors in different terminals. See emacs colors based on $TERM environment variable for comments. And TERM=xterm on Debian has provided color for quite a while. So in a typical configuration, color should "just work".
However, there are different ways to configure Emacs. Attempting to reuse some 256-color script can fall into the hole dug by developers who assume that every terminal is just like the one in front of them. See the Emacs wiki page X Term Colors for an example.
!! SOLVED IN MOBAXTERM VERSION 8.2 !!
Looks like your terminal settings are out of sync. The settings of your terminal need to agree with the termcap/terminfo settings on the server. Try to set the TERM variable in the shell on the server to a value which better matches the terminal emulation capabilities of your terminal (common values are xterm, xterm-color, vt520, and vt102) or correspondingly change the settings of the terminal to match the current TERM value. (If the terminal is buggy, you may need some trial and error to find a mode which works well for you.)
VT220 works fine; Edit Session / Terminal Settings / Type: vt220
Is there a compelling reason why gnome-terminal (and, under the hood, maybe the VTE widget) sets $TERM to xterm rather than xterm-256color? Clearly it supports 256 colors.
For a while, I had a line in my .bashrc/.zshrc to simply export TERM=xterm-256color, because that's usually the terminal emulator that I'm using. But then I open up tmux, and the behavior / colors are wrong in many CLI applications, such as emacs and htop, because tmux will set the TERM variable to screen-256color, then the shell loads and executes my .*rc file, which then sets the TERM incorrectly.
For now, I have:
if [ "$TERM" != "screen-256color" ]; then
export TERM="xterm-256color"
fi
I don't like this, because what if one day I break out my actual VT-220 or use a different terminal emulator?
For a long time, people used to look at $COLORTERM, and if that was set (along with TERM=xterm) they switched it to TERM=xterm-256colors instead.
Later, gnome-terminal (actually vte) removed setting $COLORTERM, but introduced $VTE_VERSION.
The newest version (gnome-terminal 3.16, vte 0.40) sets TERM=xterm-256color right away (which is again not quite correct, because it supports 16M colors, but there's no way to denote it in terminfo.)
IPython's history-search-backward feature is one of my favorite features. history-search-backward allows you to type part of a command and then search backward through your readline history for commands that began with that part of the command. By default (I believe) these are bound to UpArrow or Ctrl+P and DownArrow or Ctrl+N (for backward and forward respectively).
They are not working for me. Instead they just go linearly through my history instead of taking into account the characters I've already typed to (allgedly) filter my history.
I'm running IPython 0.13.2 (with Python 2 and 3) on Arch Linux from within XTerm.
If I hit Escape, Ctrl+P, then UpArrow and DownArrow work exactly as I want them to.
Additionally if I change my ipython_config.py to include
c.TerminalInteractiveShell.readline_parse_and_bind = ['"\\e[B": history-search-forward', '"\\e[A": history-search-backward']
then I can just do Escape UpArrow for the desired behaviour. (Here's the rest of my config file.)
Ctrl+V UpArrow produces ^[[A as I expect. I have the python readline library installed (which seems to fix common problems with macs running IPython).
I have these lines in my .bashrc
bind '"\e[A": history-search-backward'
bind '"\e[B": history-search-forward'
and they work exactly as I want them to within bash.
I have no idea what else to try next, so I've come here. Please help, I hope I've included enough information and done enough research.
The culprit was set keymap vi set in my .inputrc. I removed that and IPython history went back to what I expected. Thanks to #Thomas K!
I'm wondering how to set the mouse cursor position under X11? Is it possible at all and if, where do I have to look for appropriate functions? X window system, KDE/Gnome/...?
Sounds like you're using X, so what you probably want is XWarpPointer. To give an absolute position on the whole screen, use the Root Window as dest window.
(You can get a quick and dirty list of X functions using ls /usr/share/man/man3/ | grep '^X')
I know the question is old, but I just discovered xdotool and it seems great:
http://www.semicomplete.com/projects/xdotool/
Try using xte command (part of xautomation package). Details here
If you are doing it in an xterm, the Xterm understands ANSI control codes. There is a list of these codes here.
To do from a shell script, use the xwit commandline tool.