xterm

Lets say I have one terminal where the output of "tty" is "/dev/pts/2" From another terminal, I want to send a command to the first terminal and execute it. Using: echo "ls" > "/dev/pts/2" only prints "ls" in the first terminal Is there a way to execute the string? No; terminals don't execute commands. They're just channels for data. You can sort of run a command and attach it to another terminal like this, though: ls </dev/pts/2 >/dev/pts/2 2>/dev/pts/2 It won't behave exactly like you ran it from that terminal, though, as it won't have that device set as its controlling terminal. It's

I'm trying to get a curses program working with my terminal spanning my monitor. However, the x coordinate can't move past the 223rd column, instead it loops around. In the source, this seems to be due to them being defined as 8-bits, and having the position values start only after the first 32 values (i.e. x = raw_x - ' '). Here's an example program from https://gist.github.com/sylt/93d3f7b77e7f3a881603 that demonstrates the issue when compiled with libncurses5. In it, if your cursor moves more than 233 columns to the right of the window, the x value will loop back over to 0 - ' ', i.e. -32

Short version: When using emacs' xterm-mouse-mode, Somebody (emacs? bash? xterm?) intercepts xterm's control sequences and replaces them with \0. This is a pain on wide monitors because only the first 223 columns have mouse. What is the culprit, and how can I work around it? From what I can tell this has something to do with Unicode/UTF-8 support, because it wasn't a problem 5-6 years ago when I last had a big monitor. Gory details follow... Thanks! Emacs xterm-mouse-mode has a well-known weakness handling mouse clicks starting around x=95. A workaround , adopted by recent versions of emacs,

I've come across both xterm-color and xterm-256color as options when trying to set up my terminal program to use color - i.e. you can set your TERM environment variable to either one. I was wondering if anyone can describe the difference between the two? I've searched for documentation on my ubuntu server as well as my mac but haven't found any. I've only been able to find various binary files in /usr/share/terminfo xterm-256color describes Xterm with support for 256 colors enabled. xterm-color describes an older branch of Xterm that supports sixteen colors. xterm-color is not recommended,

I am testing the various different terminals that I tend to use to SSH into Linux boxes that I have Tmux set up on. Basically I noticed this behavior, and I am hoping that somebody could offer an explanation of what's going on. Now it may be the case that this is specific behavior that affects the Prompt app. I am using Vim within Tmux, and on Panic's Prompt app on my iPhone5 I was having the behavior that 256 colors were not enabling when the .vimrc set the colors using the set t_Co=256 directive. Here, Vim was correctly displaying the colors when it was not run through Tmux. Also, OS X's

How can I run a command on xterm startup i.e. when an xterm terminal is launched a the command is already executed? I have edited the .bashrc file to add this line: xterm "ls" But this does not work. Please suggest what should I do to acheive this. Thanks. According to the bash manual, ~/.bashrc is used for interactive shells. xterm runs a shell, so perhaps your "does not work" causes a chain of xterm's. The xterm program sets these environment variables which are useful for scripting: XTERM_VERSION and XTERM_SHELL . In your ~/.bashrc file, you could use the former to run the xterm -ls once

I'm trying to retrieve the coordinates of cursor in a VT100 terminal using the following code: void getCursor(int* x, int* y) { printf("\033[6n"); scanf("\033[%d;%dR", x, y); } I'm using the following ANSI escape sequence: Device Status Report - ESC[6n Reports the cursor position to the application as (as though typed at the keyboard) ESC[n;mR, where n is the row and m is the column. The code compiles and the ANSI sequence is sent, but, upon receiving it, the terminal prints the ^[[x;yR string to the stdout instead of stdin making it imposible for me to retrieve it from the program: Clearly,