Is there a way to search LLDB commands similar to the readline library's history-search-backward in bash and GDB?
I want to be able to type some characters, and use up arrow to cycle through all commands that start with those characters.
lldb uses editline rather than readline. Editline has a backward search in command history feature (em-inc-search-prev) that's bound to ^R by default (though you can change this in your .editrc) It works like emac's ^S, you type characters to refine the search, and ^R to go to the previous match. To reverse direction and start searching forward you would use em-inc-search-next, but we haven't bound that to anything.
Related
I was working on my own bash prompt when hit strange behaviour (both iTerm and Terminal.app on macos). I managed to boil it down to the minimum working example:
~/.bash_profile:
WHITE="\[\033[1;37m\]"
COLOR_NONE="\[\033[0m\]"
# This always wraps correctly
PS1="\u:\w"
# This (added coloring) wraps incorrectly when using small window.
# PS1="${WHITE}\u:\w${COLOR_NONE}"
Now create a long directory name say
mkdir ~/very_long_name_very_long_name_very_long_name_very_long_name_very_long_name_very_long_name_very_long_name_very_long_name_very_long_name_very_long_name_very_long_name_very_long_name_very_long_name_very_long_name_very_long_name_very_long_name_very_long_name
and cd to it. Problem is: with the first version of the PS1 it wraps perfectly, while adding just one color breaks wrapping for small windows. Can anybody clarify of give a workaround? Adding \n to the end is an option, but looks ugly for short prompts.
Thanks!
Sources I have already seen:
BashFAQ/053 about colors
SO question about \[ and \]
Issue with \x01 and \x02
UPD:
bash version version 3.2.57(1)-release (x86_64-apple-darwin17)
Bash has always had trouble handling long prompts with invisible characters, so the usual practice is to avoid them. For example, you could automatically trim the length of the prompt by omitting the beginning of the path if it is too long, or you could automatically output a trailing newline if the path is very long. (In such cases, you might want to use $COLUMNS, which will normally tell you the width of the window.)
In patch 19 to bash v4.4 (which I realise is not really relevant to your environment since you seem to still be using the antique version of bash provided by a default OS X install), a long-standing bug was corrected, which had the effect of triggering a segfault in certain very rare cases of multiline prompts with both invisible and multibyte characters. The behaviour definitely changed between v4.4.18 and v4.4.19, but even with that patch very long prompts cause problems when the prompt extends to a third line.
There is a comment in lib/readline/display.c which indicates that the readline library assumes that prompts will not exceed two lines. I suggest that you use that as a limit.
In vim, to find a character you can use 'f' to find the next matching character in the line that your cursor is on, and 'F' to find the previous matching character in the line that your cursor is on.
Is there a way to move around like that on the bash command line?
I know that you can set bash to be in vim mode, by saying set -o vim, and this works great for my local machine, but I administer a lot of machines where I can't change that setting.
Ignoring for a moment the security issues associated with everybody in your office sharing the same user, you could add a key binding to the readline command character-search:
# ~/.inputrc
C-]: character-search
To use the search, type Ctrl-] followed by the character you want to search for. You can bind the command to any key sequence, not just Ctrl-], but for obvious reasons you probably don't want to emulate vi mode by binding it to the letter f.
This would be less invasive than turning on vi mode so most users would probably not even notice the change. However, somebody could easily stumble upon your key sequence by accident and become very confused. You would also have to use three keystrokes instead of the two you're accustomed to with vi.
I love emacs shells, but there is a confusing thing for people used to use the gnome shell (like me). The backwards search does not work the same way. C-r searches in the buffer, not in the command history, and M-r searches in the command history but when pressed twice toggles between direct and regexp search, i.e. does not search for the previous match in the command history. So, how to do that?
Edit: The shell I was looking when I wrote this is what you get with M-x shell, I didn't know there were other shells in emacs. See e.g. https://plus.google.com/112537550357635435516/posts/Wgpk2mH6hQh
Type M-r , search for something, and then press C-r to repeat the same search in the command history.
Press M-r, then write something, then press C-r as many times as needed.
Lots of times I'll use Ctrl-R for reverse search and mistype some letter. Bash jumps up hundreds of lines and I'm in the middle of commands I was using a week ago.
Is there a shortcut for jumping back down to the lastest commands I had typed?
Edit: after testing it out on a CentOS server and Mac OS X, it looks like this only happening on OS X.
I've struggled with this same issue.
You can solve this by aborting with ctrl-c. Whether you're in the middle of a reverse search or scrolling through history with the arrows, aborting returns you to a prompt with the history scroll just after the last command.
UPDATE
Here's a nice trick I just learned. Bash and many other programs use Readline under the hood for command-line interpretation. Key bindings for Readline can be configured in a .inputrc file or with the bind command. The bindings can make use of a few functions provided by Readline. For example, I use Bash in vi mode but I still like to use Emacs-style ctrl-A so I have this line in my .bashrc file:
bind '\C-a:beginning-of-line'
To list all the available Readline functions:
bind -l
Among the functions is end-of-history. The function does like its name suggests. The difference between this approach and just using the abort command is that this keeps you on the same prompt.
If using libreadline, Alt-> (or Meta->). More info on Readline shortcuts or search for Commands for Manipulating the History in the man page.
On Mac, try command + .
It works for me.
I was trying alt+. and alt+shift+. , neither works for me. And then found command + . actually works
Maybe not exactly what you want, but you can fix your mistyped character(s) by using backspace when you're in the CTRL-r (reverse-i-search) mode.
You may wan to try "suggest box"-like history HSTR. It reads the bash history and allows quick navigation and filtering - you can see the context of similar history entries. Once you select a history entry it can be edited on the command line.
In Zsh with emacs binding set the actual default key sequence is ^[> binded to end-of-buffer-or-history command rather than command-. suggested above (or end-of-history depending on effect you want to achieve)
Cmd-. produces in Apple Terminal the similar or the same key sequence as Ctrl-C, which can be confirmed by running something useless and long, e.g. find . >/dev/null 2>&1 and pressing one and then other keys on keyboard.
Ctrl-C forces input to be ended and reset. and history scroll is just a side effect for it.
I'm using Terminal on Snow Leopard.
At the command line, if I've typed foo.bar.baz.bang.quuz.quux, when i tap option-B, it moves the cursor backward word by word -- stopping at every period, because it considers a period to be a word boundary. Likewise, option-F moves forward word by word.
In irb (0.9.5, ruby 1.8.7), option-B and -F also have this behavior, but the period is no longer treated as a word boundary, which makes these keyboard shortcuts significantly less useful.
How can I change this?
EDIT: Curiouser and curiouser: On an EC2 instance which has the same irb and ruby versions, the period is treated as a word boundary.
I think this has more to do with the Readline module.
The word break characters can be changed. Run this in your IRB and see what characters is Readline using:
Readline.basic_word_break_characters
Readline is part of the standard ruby library: http://ruby-doc.org/stdlib/libdoc/readline/rdoc/index.html
Could this be of relevance here?
http://jorgebernal.info/2009/11/18/fixing-snow-leopard-ruby-readline/
In any case make sure option-B/F are actually bound to forward and backward-word in your inputrc files, like John pointed out.
Also word boundaries are determined by your locale (see the "locale" command), and more specifically by LC_CTYPE (character classification). I don't think that's the problem here, but you might want to check out and compare your locale settings just in case.
Readline also uses the following configuration files:
/etc/inputrc
~/.inputrc (or a filename specified by the environment variable INPUTRC)
This can cause different behavior on different machines (but probably not between ruby versions - I guess ruby adds another layer of configuration on top).