I use Ctrl+q as tmux's prefix key in my Linux server.
Now I connect my Linux server on my MacBook in iTerm2.
I want to map command+q to control+q in iTerm2.
So I config keys tab in iTerm2 preferences and add key bindings command+q to trigger send a hex code. I try sending hex code 0x11 (ctrl) 0x47 (q), but it is not work.
Why?
Related
I have a mariadb installed on my system, and I want to connect it with spring boot using jpa, so I've forgot my port number
Can someone tell me how I can find it in navicate
If you haven't connected to the database using Navicat yet and you don't already have the port, then there's no way you can find out the port from Navicat.
If you are currently connected to the database through Navicat, simply click the connection tab and you'll be shown with this dialog Then you can see the port. Even if you're not using Navicat, most tools that I know of will always need a specific port for the database connection so if you ever save the connection info on the tools, and the port is unchanged, then you can find it there.
If you're using Windows, you can try this method:
a. Make sure the database service is running then open task manager > go to "details" tab and find process name "mysqld.exe" :
if you have multiple process, note down all of the "PID" numbers.
b. Open Command Prompt (as administrator if required) then type the following netstat -aon | findstr "PID" then press "Enter"; for example, the "PID" is 2668 so like this:
You might get result of two or more rows depending on the connection made to your database but the port will all be the same. In that example, the port is 4238, that is beside the word TCP:
Protocol
Local Address (local IP:port)
Foreign Address
State
PID
TCP
0.0.0.0:4238
0.0.0.0:0
LISTENING
2668
Another method you can try is simply checking the "my.ini/my.cnf" file. If you don't know where to locate that, in Windows, open "run" dialog and type "services.msc" then click "OK".
Find MariaDB/MySQL service name (or whatever custom service name you gave to it), right click it then select "Properties":
Once the "Properties" dialog open, highlight and drag your mouse to the right (end) at the text below the "Path to executable" area to locate where your "my.ini" file is.
You can just highlight the path where the "my.ini" file, paste in "Run" then click "OK" and the file will be opened:
You can find the port under [mysqld] and [client] section. Both should have the same port but depending on your MariaDB version, the information might not be the same as this screenshot:
Additional:
IF somehow you are connected to the database through a tool (like Navicat) and able to run query but (strangely) unable to check the connection properties, then you can execute this query to get the database port number: SHOW VARIABLES LIKE '%port%';
I'm trying to perform ESC key press over telnet connection in Robot Framework. Is there anyway to straight away send the key press over Telnet.Write keyword or any other alternative.
${esc}= Evaluate chr(int(27))
Telnet.Write Bare ${esc}
This worked for me
I am trying to transfer some text files on SFTP Server using Putty command line option.
I have a batch file with the following commands:
(
echo cd /inbox
echo mput c:\temp\*.txt
echo bye
echo cd c:\temp\
echo del c:\temp\*.txt
) |echo open <username#ip> <port no> -pw password
However, when I execute the batch file I get stuck at "Keyboard interactive prompt from Server"
Appreciate any suggestions on how to get over this point to avoid manual intervention while executing this batch file?
I have figured out the reason i was experiencing this issue. I my password i had a special character ^ (power symbol), and while i had passed correct password in batch file it was somehow skipping only that ^ character in password. To overcome this I tried to provide password in batch within double quotes "password" and then my issue was resolved.
Just sharing my experience.
enter image description here
Well I had a similar problem when trying to use putty to make an ssh connection, exactly the same warning message "Keyboard interactive prompt from Server". I could write the username but it never accepted the password, also my external ip address did not even made connection, local ip server address worked but password always failed, I was prepared to make a restore from backup, but since I had physical contact with the server, I just plugged an USB Keyboard and "voilá" all problems ended. Maybe Kernel had not loaded the keyboard ascii software or something and somehow it is also needed on remote ssh connection.
I am using TeraTerm to send strings over COM port using the Serial connection in TeraTerm. I had tried to use PuTTY but it refuses to connect to the COM port and I am not sure why. It says
Unable to open connection to COM4
Unable to configure serial port
That is neither here nor there, but it does mean that PuTTY like will not be usable for my application.
One thing PuTTY does well, though, is it includes the option for "Local line editing" which means I can make the serial window wait for the "Enter" keystroke before it sends it over COM port. I am looking for a way to make TeraTerm do that as well as right now it sends every character as it is entered into the window.
ie if I type in the word "Test", the window is sending T/r/n, e/r/n, s/r/n, t/r/n as opposed to Test/r/n
If someone could help me solve this in TeraTerm, or help me fix my PuTTY connection, that would be much appreciated as well.
When typing characters into TT, the characters are sent out as you type them, and there is no way to configure it otherwise. If anything is sent with each character, this is configurable, but there is no way to configure TT in such a way to "send nothing" until you type 'enter', as other "terminals" do.
Some devices receive the commands in a buffered way and have a short timeout between the characters, so you are never able to "type" a command in TT. For example, many USB devices which use USB-to-serial internals (like ST development tools and MCUs). This is because the USB sends "frames" with each character you type, and the device expects to receive a "full command" in a frame, if the frame is not a valid command, is discarded.
When you type "test", unless you are lightning fast, four frames will be sent. If that is your case, you have to use another terminal program (there are plenty available). If for any reason you are restricted to TT, then you can use the following trick:
write the command in your favorite editor, like PN2, Notepad++, etc., (or even TT itself in a separate terminal, not connected to your target board) copy it with ctrl+c or whatever, and then switch to TT and press either alt+v or alt+r to send it out without, respective with, a CRLF ending (see the edit menu in TT/VT). The ending can be configured from the setup/terminal menu, and (if enabled in setup/additional_settings/copy_and_paste menu) the mouse's right or mid clicks can be also used.
I usually have a list of commands pre-written, opened in a different window, and instead of typing, the "work" is a sequence of "double click in pn2 window" (to select command), ctrl+c (to copy it), "right click in TT window" (to send it out).
I am trying to use PuTTY to communicate over my computer's serial line. I have configured the correct serial line, baud rate, number of data bits, stop bits, parity, and flow control, and established the connection. When I click OK to open the connection, I am shown a black screen and each of my key presses are sent without being shown on the screen (the window remains black). How do I configure PuTTY so that it only sends my commands or opcodes after I press enter?
I have used PuTTY while at college for Telnet / SSH and it always showed my commands and input them only after I pressed the enter key, so I am a bit confused.
The settings you need are "Local echo" and "Line editing" under the "Terminal" category on the left.
To get the characters to display on the screen as you enter them, set "Local echo" to "Force on".
To get the terminal to not send the command until you press Enter, set "Local line editing" to "Force on".
Explanation:
From the PuTTY User Manual (Found by clicking on the "Help" button in PuTTY):
4.3.8 ‘Local echo’
With local echo disabled, characters you type into the PuTTY window are not echoed in the window by PuTTY. They are simply sent to the server. (The server might choose to echo them back to you; this can't be controlled from the PuTTY control panel.)
Some types of session need local echo, and many do not. In its default mode, PuTTY will automatically attempt to deduce whether or not local echo is appropriate for the session you are working in. If you find it has made the wrong decision, you can use this configuration option to override its choice: you can force local echo to be turned on, or force it to be turned off, instead of relying on the automatic detection.
4.3.9 ‘Local line editing’
Normally, every character you type into the PuTTY window is sent immediately to the server the moment you type it.
If you enable local line editing, this changes. PuTTY will let you edit a whole line at a time locally, and the line will only be sent to the server when you press Return. If you make a mistake, you can use the Backspace key to correct it before you press Return, and the server will never see the mistake.
Since it is hard to edit a line locally without being able to see it, local line editing is mostly used in conjunction with local echo (section 4.3.8). This makes it ideal for use in raw mode or when connecting to MUDs or talkers. (Although some more advanced MUDs do occasionally turn local line editing on and turn local echo off, in order to accept a password from the user.)
Some types of session need local line editing, and many do not. In its default mode, PuTTY will automatically attempt to deduce whether or not local line editing is appropriate for the session you are working in. If you find it has made the wrong decision, you can use this configuration option to override its choice: you can force local line editing to be turned on, or force it to be turned off, instead of relying on the automatic detection.
Putty sometimes makes wrong choices when "Auto" is enabled for these options because it tries to detect the connection configuration. Applied to serial line, this is a bit trickier to do.