Why isn't zsh autocomplete using history behaving consistently from login to login?

The name of the pictureThe name of the pictureThe name of the pictureClash 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 sshed 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)






share|improve this question






















  • 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 before source .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














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 sshed 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)






share|improve this question






















  • 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 before source .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












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 sshed 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)






share|improve this question














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 sshed 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)








share|improve this question













share|improve this question




share|improve this question








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 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 before source .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










  • @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 before source .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










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 ...






share|improve this answer






















  • What does -x? It's not in man zsh.
    – cprn
    Nov 9 '17 at 23:30






  • 1




    @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











  • 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

















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






share|improve this answer






















    Your Answer







    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "106"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    convertImagesToLinks: false,
    noModals: false,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );













     

    draft saved


    draft discarded


















    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






























    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 ...






    share|improve this answer






















    • What does -x? It's not in man zsh.
      – cprn
      Nov 9 '17 at 23:30






    • 1




      @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











    • 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














    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 ...






    share|improve this answer






















    • What does -x? It's not in man zsh.
      – cprn
      Nov 9 '17 at 23:30






    • 1




      @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











    • 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












    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 ...






    share|improve this answer














    % 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 ...







    share|improve this answer














    share|improve this answer



    share|improve this answer








    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 in man zsh.
      – cprn
      Nov 9 '17 at 23:30






    • 1




      @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











    • 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






    • 1




      @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











    • 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












    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






    share|improve this answer


























      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






      share|improve this answer
























        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






        share|improve this answer














        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







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Nov 17 '17 at 21:33

























        answered Nov 10 '17 at 2:13









        zzxyz

        1399




        1399



























             

            draft saved


            draft discarded















































             


            draft saved


            draft discarded














            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













































































            Popular posts from this blog

            How to check contact read email or not when send email to Individual?

            Displaying single band from multi-band raster using QGIS

            How many registers does an x86_64 CPU actually have?