I was having a similar problem when connecting via ssh to Mac OS X using a terminal emulator. Although I'd set LANG to de_DE.UTF-8 I couldn't type in any characters with umlauts.
The fix I found was to create/edit ~/.inputrc (or edit the following lines in /etc/inputrc):
set input-meta on
set output-meta on
set convert-meta off
Now I can type umlauts. I believe this applies to xterms in general.
You should be able to do something with wmctrl:
wmctrl is a UNIX/Linux command line tool to interact with an EWMH/NetWM compatible X Window Manager.
The tool provides command line access to almost all the features defined in the EWMH specification. It can be used, for example, to get information about the window manager, to get a detailed list of desktops and managed windows, to switch and resize desktops, to make windows full-screen, always-above or sticky, and to activate, close, move, resize, maximize and minimize them.
Just write scripts for Ann and Bill that look something like this:
#!/bin/bash
xterm &
sleep 2 ## sleep just to let the terminas appear and become the active window
wmctrl -r :ACTIVE: -e 5,-1,-1,660,540
----------- -- -- -- --- ---
| | | | | |---> Window height
| | | | |-------> Window width
| | | |-----------> Window Y coordinates
| | |--------------> Window X coordinates
| |----------------> Gravity
|--------------------------> Apply to the active window
Gravity can be one of (source):
- NorthWest (1)
- North (2),
- NorthEast (3),
- West (4),
- Center (5),
- East (6),
- SouthWest (7),
- South (8),
- SouthEast (9)
- Static (10).
A gravity of 0 indicates that the Window Manager should use the gravity specified in WM_SIZE_HINTS.win_gravity.
You should be able to figure out a way of specifying the terminal window specifically if you look through man wmctrl. Otherwise, use my sleep && active hack.
Update in response to your comment:
I can get the active window to move to the bottom right hand corner of my screen with this:
wmctrl -r :ACTIVE: -e 4,3040,900,620,620
I'm not really sure what the gravity is doing, but specifying X and Y works. I am running a system with an extended desktop spread over two screens:
$ xrandr | grep -w connected
VGA-0 connected 1440x900+1600+0 (normal left inverted right x axis y axis) 408mm x 255mm
DP-3 connected 1600x900+0+0 (normal left inverted right x axis y axis) 344mm x 194mm
So, 1600+1440 = 3040 which means that 3040 will place my window at the bottom right. You will need to tweak according to your setup of course.
Best Answer
This is also the behavior of
xterm, which is widely considered as the de facto standard for terminal emulation; and I'm pretty certain that it's also backed by corresponding standards that these terminal emulators follow.TAB is not a printable character (
isprint(9)returns 0), [and in my opinion the practice of storing TABs in text files is a big mistake all throughout the computer world, not just for the troubles it causes with terminal emulation; but this is a debate for another day, I don't want to start a tabs vs spaces flamewar here :)]TAB is a control character that moves the cursor in the same row to the next TAB stop. It's like all those various other cursor moving escape sequences that the terminal supports.
Just for fun, you can also notice that TAB doesn't wipe out the characters underneath. If there's any actual content that it jumps through then it leaves those unchanged, totally breaking the visual result and copy-pasting compared to what you'd probably expect.
Many terminal emulators out there don't copy TABs to the clipboard but copy spaces instead (jumping through cells in the "erased" state converts them to spaces I guess). It's a special quirk in VTE (the terminal emulation widget used both by GNOME Terminal and Terminator) and presumably in a few other terminal emulation engines to preserve the TAB characters under certain circumstances (e.g. if it didn't jump over an already existing character).
As much as I dislike the current behavior just like you and would much rather prefer that a TAB jumped to the next line and would be preserved while copy-pasting or when rewrapping the lines on a resize, I'm afraid such a deviation from the standard is likely to cause various sorts of bugs in various applications.
TAB is not a printable character, it's a control instruction. Just like with any other nonprintable characters, including escape sequences, you shouldn't send them to the terminal unless you know exactly what you're doing. Unfortunately this expectation from the terminal (and its backing standards), and the widespread use of TABs in text files and expecting
catto "just work" really don't play well together.