In tcsh, the \eP and \eN commands take into account the whitespace-normalized prefix of the current line, not just the first word.

For instance if my history contains

git pull upstream feature-dancing-pigs
git clone

and I type

% git pull

and then hit \eP in tcsh, I get

% git pull upstream feature-dancing-pigs

if I hit \eP in zsh, I get a history item that just matches the command

% git clone

I want to configure zsh to emulate the tcsh behavior. Is it possible?

I've tried zsh with the default emacs key configuration and with an explicit

bindkey "\eP" history-search-backward

As it turns out

bindkey "\eP" history-beginning-search-backward

does have the expected behavior I was just using ^[ initially in place of \e.


There is a function documented in zshcontrib called up-line-or-beginning-search, you can view this by running.

man zshcontrib | less '+/^\s*up-line-or-beginning-search'

These widgets are similar to the builtin functions up-line-or-search and down-line-or-search: if in a multiline buffer they move up or down within the buffer, otherwise they search for a history line matching the start of the current line. In this case, however, they search for a line which matches the current line up to the current cursor position, in the manner of history-begin‐ ning-search-backward and -forward, rather than the first word on the line.

if you look at the instructions given at the top of the ZLE FUNCTIONS section in man zshcontrib

These functions all implement user-defined ZLE widgets (see zshzle(1)) which can be bound to keystrokes in interactive shells. To use them, your .zshrc should contain lines of the form
autoload function
zle -N function

Personally I have followed the instructions above, but I suspect nowadays you may not need to... in your ~/.zshrc

# register the function with the autoloader
autoload -U up-line-or-beginning-search
# define new zle widget
zle -N up-line-or-beginning-search
# bind UP key
[[ -n "${key[Up]}" ]] && bindkey "${key[Up]}" up-line-or-beginning-search
  • Also, I just now figured out that the syntax I was using originally had no chance of working. The syntax for a literal escape in zsh is \e. it appears that history-beginning-search-backward actually does do what I intended and mimics the tcsh behavior. May 20 '16 at 2:49
  • @GregoryNisbet glad you got it working. I wondered what the ^[ and other sequence your mentioned were referring to. I assumed UP. I believe these sequences are different from one terminal to another. Also I suspect "\eP" is not a literal escape sequence but a zsh syntactic sugar that produces UP in a terminal agnostic way, so you don't need to deal with the literal characters. But I should ask a question about this as I'm a bit unsure myself. May 20 '16 at 3:01
  • The existing organization of this question doesn't make much sense since I made an assumption about the syntax for binding keys in zsh that turned out to be wrong. It's also not immediately clear to me how 'up-line-or-beginning-search' differs from 'history-beginning-search-or-backward' (I don't have it in my zshcontrib) May 20 '16 at 22:23
  • @GregoryNisbet good points. The reason I gave up-line-or-beginning-search as an answer, and how it differs from history-beginning-search-or-backward is that once you bind <UP> to a search you lose the ability to move up a line in a zsh multiline buffer. So I don't - consider history-beginning-search-or-backward to be a long-term solution. At some point you might want to use multiline buffers. This is a huge feature of zsh. I just wrote a multiline heredoc command with zsh 5 minutes ago. so you might need to "upgrade" to up-line-or-beginning-search anyway. May 20 '16 at 22:37
  • 1
    exactly - thats the problem with history-beginning-search-or-backward, you lose the normal behaviour of the <UP> key. I suggest if you want to find out more about the mulitline commands check out this intro to zsh by Seth House, google it and then if you you get stuck, you could ask a new question here unix.se May 20 '16 at 22:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.