I am install VMware station 12 in win7 to run a ubuntu 14.04 LTS server.
When using vi, the key is in chaos.
For example, in insert mode(after I press 'i'), backspace can not delete the character which on left of cursor, instead it left move the cursor.
Sometimes the 'x' can delete the character, sometimes it can not.
Sometimes the enter will replicate all characters
In summary, the behavior of vi is total different than normal linux. How to set this?
I have not install "enhanced keybroad driver", but only vi have this problem.
I think it's just normal behaviour which happens because of wrong typing.
The thing with backspace for example is a normal thing, add the following to your .vimrc to solve this:
set backspace=indent,eol,start
Related
I'm trying to install Elementary OS in VirtualBox, but the minimum resolution of the OS is 1024x768 and VirtualBox always boots in a much lower resolution. I can't install Guest Additions until the OS has been fully installed and I am on the desktop. I can't go through with the installation, though, because I only see about 60% of the screen in the top left corner. I've tried increasing video resolution to 128mb, but as I thought, that didn't work. Is there a way to increase the resolution with Guest Additions or something else before booting the system to install it?
I had an issue with the installation of Elementary OS 6 with VirtualBox for the same reason. The right side and bottom portion of the installer screens were cutoff. That area of the screen has buttons for back, submit, cancel.
I resolved this by making to selection to erase/complete install, then using the tab key twice followed by the enter key. Apparently this sequence of keystrokes allowed me to initiate the full installation script successfully.
same issue here,
end up add boot kernel parameter to fix this,
when first boot prompt(5 secs),
hit any key within the 5 secs count down to show boot options,
hit TAB to edit first option,
add the vga=ask to the end of boot kernel lines.
then it will show another 30 secs count down for VGA mode selection,
hit ENTER to choose proper one, in my case I choose 1280x800x32.
that's all,
more detail regarding boot vga parameters can refer to this URL.
https://linuxhint.com/set_screen_resolution_linux_kernel_boot/
I'm learning how to use ncurses and I'm in a weird situation.
It seems my output can't go over 24 lines.
Moreover, whenever I run my software, and the execution finishes his job, my terminal stops working as before, and I have 2 different situations:
if I've launched my run from a line behind line 24 I can use the terminal, but if I keep scrolling when at the last line of the window, nothing more happens: all input and output keep happening in the last line, without any new line appearing at enter pressure.
if I've launched the run above line 24 the terminal will only become 24-lines high.
Both situations require me to reset the terminal, then everything works again.
I'm on MAC OSX machine.
There is a problem with the screen-size:
The easiest one to see is if you has LINES environment variable set to 24. The use_env manpage gives some clues about that.
The reason why it sounds like a problem with screen-size is that the description of the problem suggests that the program is setting the scrolling region to 24 lines.
If there is no problem with LINES, then a place to check is by running stty -a to see what the operating system supposes the screen-size to be. That is reported on the first line of stty's output as "rows".
In some cases (for instance in remote network connections), it is possible to have a session where the remote host cannot obtain the screen-size. As a workaround, you could run the resize program (an xterm utility) to update the operating system's notion of the screen-size.
By the way, your other question NCurses not restoring terminal behavior appears to be a duplicate of this. You should consolidate your questions into a single one which provides enough information for someone to offer useful information about the problem.
Is there any way to tap on keypad button in calabash -android (like :1,2,3,4)
Note : Tap should be physical tap , as we got with "keyboard_enter_text" command in iOS
For Android you can use keyboard_enter_text"1,2,3,4".
You have to have touched the field first, so that it is in focus.
Is that what you are asking for?
Calabash doesn't support it but you can use adb to press keyboard keys
adb shell input text "what%syou%want%stype"
In ruby you can execute terminal commands in a couple of ways but I use backticks
`adb shell input text "what%syou%want%stype"`
See here for more info - http://krazyrobot.com/2014/02/calabash-android-enter-text-from-keyboard-using-adb/
EDIT: Not too sure on the cause of the downvote but here's a bit more info on my answer in case it makes any more sense to anyone.
The equivalent function of keyboard_enter_text for calabash-android has the same name. It is in the TextHelpers module of calabash-android. To use it, you have to
require 'calabash-android/text_helpers'
However the implementation of keyboard_enter_text seems to be different behind the scenes for android in as far as it sets the text value in the field to the whole word/phrase like it has been pasted in, rather than with individual keypresses like it does for ios. As far as I know you can simulate the individual keypresses using adb commands if that is what you want.
I'm not sure why you would need to click on the keyboard buttons specifically, rather than just be happy that the text is in the field, as it is slower, but if you do for some reason then the adb commands should work.
We've been struggling for a while now to understand the keyboard scancode behavior in Linux.
When we open a normal bash shell, the arrow keys works as expected: UP shows the previous item in the history etc. However when you spawn a process, arrows does not work as expected anymore. For example, UP prints ^[[A instead of the previous command.
To demonstrate this, do something like:
bash$ ping www.google.com
Now, press UP or DOWN etc. and you will see the wrongly mapped key codes while the process is running. However, when you terminate the process the arrow keys will work again.
We've tested it on CentOs, Ubuntu, Mac and even in different shells (bash, sh, zsh) and the same happens everywhere. I've also tried different keyboard modes using kbd_mode where we tested with RAW and XLATE modes.
The closest thing I could see while searching for answers were IPython users have experienced the same behavior when IPython was not build against readline. However, this is not related to our case as far as I can see.
We are developing a C++ Tcl based console application which uses cin and cout to communicate with, and get input from the user. We are having issues with the arrow keys when we try to access the history of previously entered commands. This is a major issue for us as 99% of people expects the arrow characters to just work.
Any ideas on how we could overcome this would be much appreciated.
You must set the terminal into raw mode to get the scan codes and handle them (that is: disable ICANON, you want the non-canonical mode). You probably also want to disable ECHO (so that it doesn't print your input on the terminal).
That is what readline or linenoise are doing. See here for some code. Esp. see the function linenoiseEnableRawMode. Some other simple sample Python code is here where I have written a simple console media player which checks for the keypresses left ("\x1b[D") and right ("\x1b[C").
The relevant calls are to tcgetattr (to get the current terminal state and modify that state struct to get into raw mode and enable some other useful behavior stuff) and tcsetattr (to set the state).
readline, libedit or linenoise are some libraries which do all that work for you and provide you with history, autocompletion, etc.
At the end, you must restore back the old state, otherwise you get the behavior you are describing in your shell.
Problem A:
I start gdb in command line with "gdb test"
I press ctrl-x,ctrl-a before I do anything else
Then I set break point using "b main"
Then I start running the program using "r"
Till this point, if I press the Up arrow key the src window will not scroll. Instead, something will appear in my command window - "^[0A". If I try to refresh the screen with ctrl-l, "^L" is what appears in the command window.
I don't think this is supposed to happen. Under this situation I can't even quit tui mode with c-x,c-a ("^X^A" will appear instead). Am I doing something wrong? I realize this problem occurs so long as I use the "run" command inside the TUI interface. I can, however, use the run command in TUI if I start gdb with "gdb -tui"
Problem B
I can't see the output of my program in TUI mode. GDB's own output can be seen, but not that of the program being debugged. This occurs both when I enter TUI using ctrl-x,ctrl-a and when using -tui command-line option.
Is there any way to fix this?
I've read some TUI articles on the net and some people seem to use TUI "exclusively". I suppose TUI can work properly, it's just there's a set of rules that must be carefully followed?
EDIT: I use gnome-terminal in ubuntu 11.04
Run gdb with -tui option instead (https://bbs.archlinux.org/viewtopic.php?id=112660)
~/.inputrc was the culprit in GDB 7.7 because of:
set editing-mode vi
set keymap vi
If I remove those lines it works.
This seems to be mentioned at in the following bug report: https://sourceware.org/bugzilla/show_bug.cgi?id=15163
I have requested a workaround at https://sourceware.org/ml/gdb/2015-06/msg00009.html and Andrew Burgess replied that he had just submitted a well received patch to add:
tui enable
tui disable
so in future versions we should have commands as an alternative to the shortcuts.
But then I saw the light and moved from TUI to GDB Dashboard: https://github.com/cyrus-and/gdb-dashboard which is simply more powerful and less buggy. See also: How to highlight and color gdb output during interactive debugging?
Change your terminal to get rid of your first problem. I used to use gnome-terminal my self, but then changed to terminator. Some terminals don't support keys like Alt sometimes (used to experience this in vim with some Alt+something maps)
You can change forcus to another window by 'focus winName', in your case, use 'focus src'
got this from here
Not sure about your 2nd problem. Good luck!
I think you are looking for, "focus next." it switches you among (there can be more than two) the windows. I'm sure there is a short-cut for this too. Please note, this is almost the same answer as user1888039, so if you agree you should up-vote that answer.
Problem A:
Use Ctrl+X then press a to enter or exit TUI mode.
Or as you mentioned run gdb -tui
Problem B:
Note that your program print could be ran over by the (gdb) prompt. In other words, it is possible that your program prints but the " (gdb)" is printed over it after.
To easily check if this is indeed the case, try to print either a line longer than 6 characters or multiple lines each time.
You should see part of your print.