Why isn't zsh autocomplete using history behaving consistently from login to login?
Clash Royale CLAN TAG#URR8PPP
up vote
0
down vote
favorite
After adding the following lines to my .zshrc:
autoload -U up-line-or-beginning-search
autoload -U down-line-or-beginning-search
zle -N up-line-or-beginning-search
zle -N down-line-or-beginning-search
bindkey "^[[A" up-line-or-beginning-search
bindkey "^[[B" down-line-or-beginning-search
I ran exec zsh
(from zsh), and the lines above did not take effect. I then did the following (not sure this context is necessary, but maybe relevant):exit
to drop me back into my login shell (bash), exit
to log out, then ssh machine
to log back in, then exec zsh
, and then the lines above were working.
Does anyone know why?
EDIT
My title question was incorrect. It turns out that .zsh is behaving inconsistently from login to login with regard to the lines above only. Sometimes they work as expected, sometimes they do not. I've attempted to find a pattern, but cannot. I think (but am not sure) login is key as once I've ssh
ed into the machine, the behavior seems to remain the same regardless of different zsh instances.
The output from read (up) (down)
is always the same as is the output from history 0
and the up and down arrows otherwise seem to behave themselves.
May or may not be useful info--for the failing case (I haven't been able to get it to work in a while now):
%bindkey | grep 'or-beginning'
"^[[A" up-line-or-beginning-search
"^[[B" down-line-or-beginning-search
%zmodload | grep zle
zsh/zle
%up-line-or-beginning-search
up-line-or-beginning-search:zle:19: widgets can only be called when ZLE is active
up-line-or-beginning-search:zle:21: widgets can only be called when ZLE is active
%read
^[[A^[[B^C% (up,down,ctrl-c)
zsh zle
add a comment |Â
up vote
0
down vote
favorite
After adding the following lines to my .zshrc:
autoload -U up-line-or-beginning-search
autoload -U down-line-or-beginning-search
zle -N up-line-or-beginning-search
zle -N down-line-or-beginning-search
bindkey "^[[A" up-line-or-beginning-search
bindkey "^[[B" down-line-or-beginning-search
I ran exec zsh
(from zsh), and the lines above did not take effect. I then did the following (not sure this context is necessary, but maybe relevant):exit
to drop me back into my login shell (bash), exit
to log out, then ssh machine
to log back in, then exec zsh
, and then the lines above were working.
Does anyone know why?
EDIT
My title question was incorrect. It turns out that .zsh is behaving inconsistently from login to login with regard to the lines above only. Sometimes they work as expected, sometimes they do not. I've attempted to find a pattern, but cannot. I think (but am not sure) login is key as once I've ssh
ed into the machine, the behavior seems to remain the same regardless of different zsh instances.
The output from read (up) (down)
is always the same as is the output from history 0
and the up and down arrows otherwise seem to behave themselves.
May or may not be useful info--for the failing case (I haven't been able to get it to work in a while now):
%bindkey | grep 'or-beginning'
"^[[A" up-line-or-beginning-search
"^[[B" down-line-or-beginning-search
%zmodload | grep zle
zsh/zle
%up-line-or-beginning-search
up-line-or-beginning-search:zle:19: widgets can only be called when ZLE is active
up-line-or-beginning-search:zle:21: widgets can only be called when ZLE is active
%read
^[[A^[[B^C% (up,down,ctrl-c)
zsh zle
That's not relevant to the question, but why didn't you justsource .zshrc
instead?
â dessert
Nov 9 '17 at 22:51
@dessert - I'd read thatsource
isn't quite the same as a fresh shell in some cases and was trying to avoid the ambiguity (unsuccessfully, as it turns out)
â zzxyz
Nov 9 '17 at 22:59
@dessert I would caution that âÂÂfixingâ the question is often better done in answers or comments; let the asker use terminology that makes sense to them. Corrections in answers and comments will then be seen by future readers who come here by way of similar wording.
â Jeff Schaller
Nov 9 '17 at 23:20
@zzxyz It's not really an answer but to add onto what dessert said: you could callreset
beforesource .zshrc
.
â cprn
Nov 9 '17 at 23:24
1
@JeffSchaller OK, but I just suggested this edit, OP himself approved it.
â dessert
Nov 9 '17 at 23:26
add a comment |Â
up vote
0
down vote
favorite
up vote
0
down vote
favorite
After adding the following lines to my .zshrc:
autoload -U up-line-or-beginning-search
autoload -U down-line-or-beginning-search
zle -N up-line-or-beginning-search
zle -N down-line-or-beginning-search
bindkey "^[[A" up-line-or-beginning-search
bindkey "^[[B" down-line-or-beginning-search
I ran exec zsh
(from zsh), and the lines above did not take effect. I then did the following (not sure this context is necessary, but maybe relevant):exit
to drop me back into my login shell (bash), exit
to log out, then ssh machine
to log back in, then exec zsh
, and then the lines above were working.
Does anyone know why?
EDIT
My title question was incorrect. It turns out that .zsh is behaving inconsistently from login to login with regard to the lines above only. Sometimes they work as expected, sometimes they do not. I've attempted to find a pattern, but cannot. I think (but am not sure) login is key as once I've ssh
ed into the machine, the behavior seems to remain the same regardless of different zsh instances.
The output from read (up) (down)
is always the same as is the output from history 0
and the up and down arrows otherwise seem to behave themselves.
May or may not be useful info--for the failing case (I haven't been able to get it to work in a while now):
%bindkey | grep 'or-beginning'
"^[[A" up-line-or-beginning-search
"^[[B" down-line-or-beginning-search
%zmodload | grep zle
zsh/zle
%up-line-or-beginning-search
up-line-or-beginning-search:zle:19: widgets can only be called when ZLE is active
up-line-or-beginning-search:zle:21: widgets can only be called when ZLE is active
%read
^[[A^[[B^C% (up,down,ctrl-c)
zsh zle
After adding the following lines to my .zshrc:
autoload -U up-line-or-beginning-search
autoload -U down-line-or-beginning-search
zle -N up-line-or-beginning-search
zle -N down-line-or-beginning-search
bindkey "^[[A" up-line-or-beginning-search
bindkey "^[[B" down-line-or-beginning-search
I ran exec zsh
(from zsh), and the lines above did not take effect. I then did the following (not sure this context is necessary, but maybe relevant):exit
to drop me back into my login shell (bash), exit
to log out, then ssh machine
to log back in, then exec zsh
, and then the lines above were working.
Does anyone know why?
EDIT
My title question was incorrect. It turns out that .zsh is behaving inconsistently from login to login with regard to the lines above only. Sometimes they work as expected, sometimes they do not. I've attempted to find a pattern, but cannot. I think (but am not sure) login is key as once I've ssh
ed into the machine, the behavior seems to remain the same regardless of different zsh instances.
The output from read (up) (down)
is always the same as is the output from history 0
and the up and down arrows otherwise seem to behave themselves.
May or may not be useful info--for the failing case (I haven't been able to get it to work in a while now):
%bindkey | grep 'or-beginning'
"^[[A" up-line-or-beginning-search
"^[[B" down-line-or-beginning-search
%zmodload | grep zle
zsh/zle
%up-line-or-beginning-search
up-line-or-beginning-search:zle:19: widgets can only be called when ZLE is active
up-line-or-beginning-search:zle:21: widgets can only be called when ZLE is active
%read
^[[A^[[B^C% (up,down,ctrl-c)
zsh zle
edited Nov 10 '17 at 1:31
asked Nov 9 '17 at 22:43
zzxyz
1399
1399
That's not relevant to the question, but why didn't you justsource .zshrc
instead?
â dessert
Nov 9 '17 at 22:51
@dessert - I'd read thatsource
isn't quite the same as a fresh shell in some cases and was trying to avoid the ambiguity (unsuccessfully, as it turns out)
â zzxyz
Nov 9 '17 at 22:59
@dessert I would caution that âÂÂfixingâ the question is often better done in answers or comments; let the asker use terminology that makes sense to them. Corrections in answers and comments will then be seen by future readers who come here by way of similar wording.
â Jeff Schaller
Nov 9 '17 at 23:20
@zzxyz It's not really an answer but to add onto what dessert said: you could callreset
beforesource .zshrc
.
â cprn
Nov 9 '17 at 23:24
1
@JeffSchaller OK, but I just suggested this edit, OP himself approved it.
â dessert
Nov 9 '17 at 23:26
add a comment |Â
That's not relevant to the question, but why didn't you justsource .zshrc
instead?
â dessert
Nov 9 '17 at 22:51
@dessert - I'd read thatsource
isn't quite the same as a fresh shell in some cases and was trying to avoid the ambiguity (unsuccessfully, as it turns out)
â zzxyz
Nov 9 '17 at 22:59
@dessert I would caution that âÂÂfixingâ the question is often better done in answers or comments; let the asker use terminology that makes sense to them. Corrections in answers and comments will then be seen by future readers who come here by way of similar wording.
â Jeff Schaller
Nov 9 '17 at 23:20
@zzxyz It's not really an answer but to add onto what dessert said: you could callreset
beforesource .zshrc
.
â cprn
Nov 9 '17 at 23:24
1
@JeffSchaller OK, but I just suggested this edit, OP himself approved it.
â dessert
Nov 9 '17 at 23:26
That's not relevant to the question, but why didn't you just
source .zshrc
instead?â dessert
Nov 9 '17 at 22:51
That's not relevant to the question, but why didn't you just
source .zshrc
instead?â dessert
Nov 9 '17 at 22:51
@dessert - I'd read that
source
isn't quite the same as a fresh shell in some cases and was trying to avoid the ambiguity (unsuccessfully, as it turns out)â zzxyz
Nov 9 '17 at 22:59
@dessert - I'd read that
source
isn't quite the same as a fresh shell in some cases and was trying to avoid the ambiguity (unsuccessfully, as it turns out)â zzxyz
Nov 9 '17 at 22:59
@dessert I would caution that âÂÂfixingâ the question is often better done in answers or comments; let the asker use terminology that makes sense to them. Corrections in answers and comments will then be seen by future readers who come here by way of similar wording.
â Jeff Schaller
Nov 9 '17 at 23:20
@dessert I would caution that âÂÂfixingâ the question is often better done in answers or comments; let the asker use terminology that makes sense to them. Corrections in answers and comments will then be seen by future readers who come here by way of similar wording.
â Jeff Schaller
Nov 9 '17 at 23:20
@zzxyz It's not really an answer but to add onto what dessert said: you could call
reset
before source .zshrc
.â cprn
Nov 9 '17 at 23:24
@zzxyz It's not really an answer but to add onto what dessert said: you could call
reset
before source .zshrc
.â cprn
Nov 9 '17 at 23:24
1
1
@JeffSchaller OK, but I just suggested this edit, OP himself approved it.
â dessert
Nov 9 '17 at 23:26
@JeffSchaller OK, but I just suggested this edit, OP himself approved it.
â dessert
Nov 9 '17 at 23:26
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
2
down vote
% echo echo echo >> ~/.zshrc
% exec zsh
echo
%
So an exec zsh
does indeed run the echo
just added to ~/.zshrc
. Perhaps run
zsh -ixc exit >grepthis 2>&1
and then inspect the grepthis
file for whether your lines were read or not, or if other bindkey
related things happened afterwards, or ...
What does-x
? It's not inman zsh
.
â cprn
Nov 9 '17 at 23:30
1
@cprn seezoptions(1)
or search all of them viazshall(1)
â thrig
Nov 9 '17 at 23:32
Thanks, got it. Also, for anyone with the same issue: redirectingcommand 2>&1 >logfile
doesn't work on myzsh
but the following shortcut is equivalent and works:command &>logfile
â cprn
Nov 9 '17 at 23:38
Yeah, my terminal got clobbered with output. I spent a few minutes going over it, but didn't see anything nefarious or different between the failure and success cases. Both output the relevant lines from my .rc (toward the end)
â zzxyz
Nov 9 '17 at 23:47
1
@cprn oh oops > needs to happen leftwards of 2>&1
â thrig
Nov 9 '17 at 23:54
 |Â
show 1 more comment
up vote
0
down vote
I still don't know why it sometimes worked, but the following helped me:
http://zshwiki.org/home/zle/bindkeys
Hitting '<ctrl-v><up>'
(rather than "^[[A"
) as the key sequence fixed things. Fortunately it also worked in vim.
The <ctrl-v><up>
sequence is printable, but not directly typable: 0x1B 0x4F 0x42
Also, (as the article also says), there are friendly bindings for some of the simpler keys that in my system are defined in /etc/zsh/zshrc
.
So on my system, the following also works:
bindkey "$key[Up]" up-line-or-beginning-search
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
% echo echo echo >> ~/.zshrc
% exec zsh
echo
%
So an exec zsh
does indeed run the echo
just added to ~/.zshrc
. Perhaps run
zsh -ixc exit >grepthis 2>&1
and then inspect the grepthis
file for whether your lines were read or not, or if other bindkey
related things happened afterwards, or ...
What does-x
? It's not inman zsh
.
â cprn
Nov 9 '17 at 23:30
1
@cprn seezoptions(1)
or search all of them viazshall(1)
â thrig
Nov 9 '17 at 23:32
Thanks, got it. Also, for anyone with the same issue: redirectingcommand 2>&1 >logfile
doesn't work on myzsh
but the following shortcut is equivalent and works:command &>logfile
â cprn
Nov 9 '17 at 23:38
Yeah, my terminal got clobbered with output. I spent a few minutes going over it, but didn't see anything nefarious or different between the failure and success cases. Both output the relevant lines from my .rc (toward the end)
â zzxyz
Nov 9 '17 at 23:47
1
@cprn oh oops > needs to happen leftwards of 2>&1
â thrig
Nov 9 '17 at 23:54
 |Â
show 1 more comment
up vote
2
down vote
% echo echo echo >> ~/.zshrc
% exec zsh
echo
%
So an exec zsh
does indeed run the echo
just added to ~/.zshrc
. Perhaps run
zsh -ixc exit >grepthis 2>&1
and then inspect the grepthis
file for whether your lines were read or not, or if other bindkey
related things happened afterwards, or ...
What does-x
? It's not inman zsh
.
â cprn
Nov 9 '17 at 23:30
1
@cprn seezoptions(1)
or search all of them viazshall(1)
â thrig
Nov 9 '17 at 23:32
Thanks, got it. Also, for anyone with the same issue: redirectingcommand 2>&1 >logfile
doesn't work on myzsh
but the following shortcut is equivalent and works:command &>logfile
â cprn
Nov 9 '17 at 23:38
Yeah, my terminal got clobbered with output. I spent a few minutes going over it, but didn't see anything nefarious or different between the failure and success cases. Both output the relevant lines from my .rc (toward the end)
â zzxyz
Nov 9 '17 at 23:47
1
@cprn oh oops > needs to happen leftwards of 2>&1
â thrig
Nov 9 '17 at 23:54
 |Â
show 1 more comment
up vote
2
down vote
up vote
2
down vote
% echo echo echo >> ~/.zshrc
% exec zsh
echo
%
So an exec zsh
does indeed run the echo
just added to ~/.zshrc
. Perhaps run
zsh -ixc exit >grepthis 2>&1
and then inspect the grepthis
file for whether your lines were read or not, or if other bindkey
related things happened afterwards, or ...
% echo echo echo >> ~/.zshrc
% exec zsh
echo
%
So an exec zsh
does indeed run the echo
just added to ~/.zshrc
. Perhaps run
zsh -ixc exit >grepthis 2>&1
and then inspect the grepthis
file for whether your lines were read or not, or if other bindkey
related things happened afterwards, or ...
edited Nov 9 '17 at 23:50
answered Nov 9 '17 at 23:25
thrig
22.6k12853
22.6k12853
What does-x
? It's not inman zsh
.
â cprn
Nov 9 '17 at 23:30
1
@cprn seezoptions(1)
or search all of them viazshall(1)
â thrig
Nov 9 '17 at 23:32
Thanks, got it. Also, for anyone with the same issue: redirectingcommand 2>&1 >logfile
doesn't work on myzsh
but the following shortcut is equivalent and works:command &>logfile
â cprn
Nov 9 '17 at 23:38
Yeah, my terminal got clobbered with output. I spent a few minutes going over it, but didn't see anything nefarious or different between the failure and success cases. Both output the relevant lines from my .rc (toward the end)
â zzxyz
Nov 9 '17 at 23:47
1
@cprn oh oops > needs to happen leftwards of 2>&1
â thrig
Nov 9 '17 at 23:54
 |Â
show 1 more comment
What does-x
? It's not inman zsh
.
â cprn
Nov 9 '17 at 23:30
1
@cprn seezoptions(1)
or search all of them viazshall(1)
â thrig
Nov 9 '17 at 23:32
Thanks, got it. Also, for anyone with the same issue: redirectingcommand 2>&1 >logfile
doesn't work on myzsh
but the following shortcut is equivalent and works:command &>logfile
â cprn
Nov 9 '17 at 23:38
Yeah, my terminal got clobbered with output. I spent a few minutes going over it, but didn't see anything nefarious or different between the failure and success cases. Both output the relevant lines from my .rc (toward the end)
â zzxyz
Nov 9 '17 at 23:47
1
@cprn oh oops > needs to happen leftwards of 2>&1
â thrig
Nov 9 '17 at 23:54
What does
-x
? It's not in man zsh
.â cprn
Nov 9 '17 at 23:30
What does
-x
? It's not in man zsh
.â cprn
Nov 9 '17 at 23:30
1
1
@cprn see
zoptions(1)
or search all of them via zshall(1)
â thrig
Nov 9 '17 at 23:32
@cprn see
zoptions(1)
or search all of them via zshall(1)
â thrig
Nov 9 '17 at 23:32
Thanks, got it. Also, for anyone with the same issue: redirecting
command 2>&1 >logfile
doesn't work on my zsh
but the following shortcut is equivalent and works: command &>logfile
â cprn
Nov 9 '17 at 23:38
Thanks, got it. Also, for anyone with the same issue: redirecting
command 2>&1 >logfile
doesn't work on my zsh
but the following shortcut is equivalent and works: command &>logfile
â cprn
Nov 9 '17 at 23:38
Yeah, my terminal got clobbered with output. I spent a few minutes going over it, but didn't see anything nefarious or different between the failure and success cases. Both output the relevant lines from my .rc (toward the end)
â zzxyz
Nov 9 '17 at 23:47
Yeah, my terminal got clobbered with output. I spent a few minutes going over it, but didn't see anything nefarious or different between the failure and success cases. Both output the relevant lines from my .rc (toward the end)
â zzxyz
Nov 9 '17 at 23:47
1
1
@cprn oh oops > needs to happen leftwards of 2>&1
â thrig
Nov 9 '17 at 23:54
@cprn oh oops > needs to happen leftwards of 2>&1
â thrig
Nov 9 '17 at 23:54
 |Â
show 1 more comment
up vote
0
down vote
I still don't know why it sometimes worked, but the following helped me:
http://zshwiki.org/home/zle/bindkeys
Hitting '<ctrl-v><up>'
(rather than "^[[A"
) as the key sequence fixed things. Fortunately it also worked in vim.
The <ctrl-v><up>
sequence is printable, but not directly typable: 0x1B 0x4F 0x42
Also, (as the article also says), there are friendly bindings for some of the simpler keys that in my system are defined in /etc/zsh/zshrc
.
So on my system, the following also works:
bindkey "$key[Up]" up-line-or-beginning-search
add a comment |Â
up vote
0
down vote
I still don't know why it sometimes worked, but the following helped me:
http://zshwiki.org/home/zle/bindkeys
Hitting '<ctrl-v><up>'
(rather than "^[[A"
) as the key sequence fixed things. Fortunately it also worked in vim.
The <ctrl-v><up>
sequence is printable, but not directly typable: 0x1B 0x4F 0x42
Also, (as the article also says), there are friendly bindings for some of the simpler keys that in my system are defined in /etc/zsh/zshrc
.
So on my system, the following also works:
bindkey "$key[Up]" up-line-or-beginning-search
add a comment |Â
up vote
0
down vote
up vote
0
down vote
I still don't know why it sometimes worked, but the following helped me:
http://zshwiki.org/home/zle/bindkeys
Hitting '<ctrl-v><up>'
(rather than "^[[A"
) as the key sequence fixed things. Fortunately it also worked in vim.
The <ctrl-v><up>
sequence is printable, but not directly typable: 0x1B 0x4F 0x42
Also, (as the article also says), there are friendly bindings for some of the simpler keys that in my system are defined in /etc/zsh/zshrc
.
So on my system, the following also works:
bindkey "$key[Up]" up-line-or-beginning-search
I still don't know why it sometimes worked, but the following helped me:
http://zshwiki.org/home/zle/bindkeys
Hitting '<ctrl-v><up>'
(rather than "^[[A"
) as the key sequence fixed things. Fortunately it also worked in vim.
The <ctrl-v><up>
sequence is printable, but not directly typable: 0x1B 0x4F 0x42
Also, (as the article also says), there are friendly bindings for some of the simpler keys that in my system are defined in /etc/zsh/zshrc
.
So on my system, the following also works:
bindkey "$key[Up]" up-line-or-beginning-search
edited Nov 17 '17 at 21:33
answered Nov 10 '17 at 2:13
zzxyz
1399
1399
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f403621%2fwhy-isnt-zsh-autocomplete-using-history-behaving-consistently-from-login-to-log%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
That's not relevant to the question, but why didn't you just
source .zshrc
instead?â dessert
Nov 9 '17 at 22:51
@dessert - I'd read that
source
isn't quite the same as a fresh shell in some cases and was trying to avoid the ambiguity (unsuccessfully, as it turns out)â zzxyz
Nov 9 '17 at 22:59
@dessert I would caution that âÂÂfixingâ the question is often better done in answers or comments; let the asker use terminology that makes sense to them. Corrections in answers and comments will then be seen by future readers who come here by way of similar wording.
â Jeff Schaller
Nov 9 '17 at 23:20
@zzxyz It's not really an answer but to add onto what dessert said: you could call
reset
beforesource .zshrc
.â cprn
Nov 9 '17 at 23:24
1
@JeffSchaller OK, but I just suggested this edit, OP himself approved it.
â dessert
Nov 9 '17 at 23:26