I am making a SSH client for a special device which does not have a all keys on it's keyboard, my question is how is the Esc,Alt,Ctrl and arrow keys encoded in the string sent to the shell? is it just '\033'?
I know how the Enter key behaves, it gives an ^M, from here
But when i press Ctrl+v and then Ctrl nothing appears, when i press Ctrl+v and then Ctrl+c in the teminal i get: ^C , so is Ctrl just ^ ?
But what about alt
Further more i found:
left ^[[D
right ^[[C
up ^[[A
down ^[[B
can i just write these commands as command below, to libssh:
rc = libssh2_channel_write(self.channel, [command UTF8String], strlen([command UTF8String])))
The problem is I get the following response from ssh: zsh: substitution failed in both bash on my mac and in my SSH program:
-bash: :s^[^C: substitution failed
Key sequence encoding depends on the terminal device. Each terminal device can make up its own encoding. The Linux console, xterm, GNU screen, gnome-terminal, konsole, vt220, etc. all have different (but similar) capabilities and key encodings.
If you need to know the encoding of a key sequence for a particular terminal device, then you should query the terminfo database for the TERM you are interested in.
Chances are the terminal emulates something similar to ECMA-48, so that it s a starting point. However, do not hard-code ECMA-48 into your application; some users might use a different terminal—especially if they ssh into the system before using your application to ssh out.
See the ncurses web site for more documentation.
If you are attempting to create your own terminal device (e.g., emulating a user pressing keys at a terminal), then it's up to you to choose the encoding you want. For it to work, you'll have to make sure your terminal device's key encoding is in the remote system's terminfo database and that the TERM environment variable is set properly. To minimize the work you need to do, you're probably best off emulating an existing popular terminal, such as GNU screen or vt220. To get their key encodings, see their terminfo database entries.
Related
I'm wondering whether others have experienced this issue (below in bold) and/or found a workaround: in macOS (any version that I've tried which provides Terminal access, so I'm assuming OS X on up; on any hardware), a Terminal or iTerm2 window gets named with the active top-level process until it ends or you quit it. Expected behavior for all systems with Terminal access, right?
When using SSH in Terminal or iTerm2 on macOS, the name of the remote machine populates the top of the window. Also expected. The unexpected comes when you exit out of the SSH session, and the name of the remote machine you had SSH'ed into persists in the window banner; there is no more visibility in the window banner of your current top-level running process, until and unless you close the window (losing some access to command history), and open a new window.
I've never seen this process-stuck behavior on the banner of a Terminal window in any other OS; various forms of Terminal on Linux distros exit out of SSH and get back to showing the top-level running process fine, as does CMD or PowerShell in Windows. What's going on with macOS, and why has this behavior never been addressed, at least as for as my limited DuckDuckGo-fu (or !G-fu) can find?
Has anyone else experienced this?
Insight welcome. Thanks!
There's no "process stick" going on.
Let's address several things here.
First, please note... "shell" != "terminal", and if you think it does, you are mistaken.
You state:
When using SSH in Terminal or iTerm2 on macOS, the name of the remote
machine populates the top of the window.
Yes, if the remote shell sets the terminal window title. Usually in a prompt. Sometimes in a shell initialization rc file. With ksh you even see people overloading things like cd(1), which is a little silly.
Then you state:
The unexpected comes when you exit out of the SSH session, and the
name of the remote machine you had SSH'ed into persists in the window
banner
Because the remote shell set the title of the terminal window and the local shell does not reset it when it regains control.
And finally:
What's going on with macOS, and why has this behavior never been
addressed, at least as for as my limited DuckDuckGo-fu (or !G-fu) can
find?
If you want whatever shell you are using to do something, configure it to do that thing. Otherwise, it will not do that thing. There's nothing to address... it's not broken.
macOS default init for ksh doesn't set any prompt at all, for zsh all that's set up is user name, machine name, and current $PWD, and bash is the same. None of them set the terminal window title.
Seems rather obvious what's going on.
So. If you want your terminal window titles to reflect this information:
the local shell needs to set the window title
the remote shell(s) need to set the window title
It seems you have the second one handled, so fix the first one. Most people do it by adding control codes to the shell prompt so that it changes the window as reliably as possible.
You may find this reference helpful.
I need script which works in the background, waiting for a key to be pressed. I have a script which works when terminal is on. When I try to use & - it's not working correctly. The script works in background but keypress doesn't do anything. When I try use nohup then I have error of read - bad descriptor.
Can someone help me?
When the terminal is on (and is selected, in case of a terminal emulator running on x server), the input (key strokes, etc.) is directed to the terminal; hence, your program works.
Now, consider an example: let's say that you created a script that runs on the background, and it is activated by pressing the letter "a". If pressing "a" triggered your script (with terminal closed), then the user would never be able to (for example) type the letter "a" in a word document or a web search without triggering the script!
Therefore, what you are looking for is a key bind, or a keyboard shortcut, which would bind a key (combination) such as ctl+j+k to launch the script you want.
In Linux, that can be done somewhat easily, see this for Ubuntu or this for Lubuntu.
Important: if your script needs to be root to work, then you generally will have to evoke it via gksu or gksudo, otherwise it will not run
I'm using cygwin and sometimes, when I am typing in vim on a file over ssh and I switch to a different window and minimize cygwin and then come back to cygwin sometime later, I get a problem.
The problem is that for some reason, my keyboard doesn't work normally anymore, and it appears that for some reason, it thinks that my Control key on my keyboard is always being pressed. I know this because when I press just the 'V' key on my keyboard, vim says it's in Visual Block mode, and when I just press the 'R' key, it tries to Redo any changes.
The bad thing is that this also means that I can't actually exit from vim because I can press the : key, but then pressing wq doesn't actually enter in the normal wq symbols because it's interpreting it as ctrl w, ctrl q.
The only way I can fix it is by closing the entire window and restarting cygwin, but this means I lose any unsaved work, which is annoying.
Note: This doesn't happen when I use vim locally in cygwin (not over SSH)
What is causing this problem?
It is my first time to use emacs -nw. But I have problem at the first when I type M-x. In the minibuffer, it shows "Mark set" instead of M-x
I don't know why it happens. How can I deal with it?
PS: My os is Macosx and I connect remote by using ssh and then I type emacs -nw but I cannot use M-x
Update:08/30/2015
When I see the options under M-x customize-group ns, it seems that Alt is actually used as Meta? Why it didn’t works.
14Hide Ns Alternate Modifier: [Value Menu] meta |
15 [ State ]: STANDARD. |
16 This variable describes the behavior of the alternate or option key. More |
37Hide Ns Right Alternate Modifier: [Value Menu] Use the value of ns-alternate-modifier |
38 [ State ]: STANDARD. |
39 This variable describes the behavior of the right alternate or option key. More |
When using Emacs in the terminal (switch -nw), you might not have a Meta key, depending on your platform etc. In particular, the Alt keyboard key might not function as the Meta key. You might find some information (e.g. here, or by googling) about how to get it working as Meta for your context (platform etc.), but you might not.
You can always use ESC (the Escape key) followed by a key to act the same as the Meta modifier applied to that key. For example, instead of M-x, you can use ESC x.
(You press and release ESC, and then do the same for x. ESC is not a modifier key -- you do not hold it pressed while hitting x.)
Your problem is that OSX is stealing the key. There are a few things which will make your life easier
Install emacs using homebrew. The version which comes with OSX is old
Use iterm2 instead of the default term.app - much better and feature rich
In iterm2, you can set a key override for either the left or right option as +ESC, which will make it all work.
This will all work on a local machine, but you may run into additional problems if your connecting to a remote machine and running emacs there. It is a similar problem, your key settings may no be getting stolen/dropped by the ssh session - all depends on your terminal, your ssh config and the remote system.
Note that with emacs, you often don't need to run remote. Emacs comes with a built-in system called Tramp, which is very powerful. Using tramp, you can open remote directories and edit the files as if they were local files. You run emacs locally and tramp uses ssh to open the remote files, read the contents into the local emacs buffer and then write the changes back tot he remote file. Helps to have ssh keys setup so you don't have to worry about passwords (but you will need an ssh-agent to make this work easily).
In general, when you find emads does not respond to a key press, especailly if you try C-h k and nothing happens when you hit the key bindings you can't get to work, it is almost certain that something in-between you and emacs is stealing the keys - this is often the window manager or OS, but it can also be due to terminal emulators etc. In over 20 years of using emacs, I've never had emacs 'do nothing' when you hit a key combination - if emacs recieves the key input, it will respond with something, even if that something is to tell you there is no key binding for the keys you pressed. If emacs does absolutely nothing, you know the message just isn't get through!
Open Terminal Preferences
Select Profiles
Keyboard
Check the box for "Use Option as Meta Key"
I want to view the output of a bash command in a vim split window :split. To this end I installed "Conque Shell" which displays bash in a split window upon :ConqueTermSplit bash. I can then run my shell command and watch the output in insert mode. However, to return to the other window I need to type <CTRL-W> <Up> in command mode, so I need to leave insert mode. Hence the display of the command output freezes and continues only if I return to this window and enter insert mode. So how can I leave "Conque Shell" without leaving insert mode.
Note that other ways of viewing the bash output in a second window might solve my problem as well. However it should update while I am working in the other window and allow me to signal e.g. <CTRL-C> to the application.
The ConqueTerm documentation says:
3.1.5 Keep updating terminal buffer *ConqueTerm_ReadUnfocused*
If set to 1 then your Conque buffers will continue to update after you've
switched to another buffer.
Note: Conque buffers may continue to update, but they will not scroll down as
new lines are added beyond the bottom of the visible buffer area. This is a
limitation of the Vim scripting language for which I haven't found a
workaround.
>
let g:ConqueTerm_ReadUnfocused = 1
AFAIK Vim has no support for asynchronous sessions, so this is more of a response to your request for potential alternative options.
The way that I currently get around this issue is by using tmux, which is described as:
a terminal multiplexer: it enables a number of terminals (or windows),
each running a separate program, to be created, accessed, and
controlled from a single screen.
So, basically, instead of splitting your screen in Vim you would split it using tmux, and then in one window run Vim and in the other run whatever other program you want which will update completely independently of Vim. And just like Vim you can switch between the windows (or panes as they are called in tmux lingo) using a couple of key strokes.
There is another terminal multiplexer available called GNU screen, which is also quite popular. And the reason I mention that is because I like to have options, and also there are two plugins for Vim that allow you to send output directly to an attached screen or tmux session. For GNU screen, slime.vim, and for tmux, tslime.vim.
Using VIM and ConqueTerm you can use CTRL + W and UP / Down to change windows in split mode.
Just click on ESC first to exit the insert mode.
It works well on my side.