With BASH after “scrolling” up to a previous command… how to then move on to the next in this history?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
58
down vote

favorite
13












Apologies, this title is not the most elegant I've ever devised.



But I assume a lot of people will have wondered this, and my question may be a dupe... all I can say is I haven't found it.



When I say "scrolling" up, I mean using the "up arrow" key on the keyboard, which obviously scrolls you up through the history, starting at the most recent command.



So you find a command maybe 30 commands back... and you run it. And then you want to run the command which originally came after it... is there is a snappy way of doing this? Or how do those fluent in BASH do this?







share|improve this question
























    up vote
    58
    down vote

    favorite
    13












    Apologies, this title is not the most elegant I've ever devised.



    But I assume a lot of people will have wondered this, and my question may be a dupe... all I can say is I haven't found it.



    When I say "scrolling" up, I mean using the "up arrow" key on the keyboard, which obviously scrolls you up through the history, starting at the most recent command.



    So you find a command maybe 30 commands back... and you run it. And then you want to run the command which originally came after it... is there is a snappy way of doing this? Or how do those fluent in BASH do this?







    share|improve this question






















      up vote
      58
      down vote

      favorite
      13









      up vote
      58
      down vote

      favorite
      13






      13





      Apologies, this title is not the most elegant I've ever devised.



      But I assume a lot of people will have wondered this, and my question may be a dupe... all I can say is I haven't found it.



      When I say "scrolling" up, I mean using the "up arrow" key on the keyboard, which obviously scrolls you up through the history, starting at the most recent command.



      So you find a command maybe 30 commands back... and you run it. And then you want to run the command which originally came after it... is there is a snappy way of doing this? Or how do those fluent in BASH do this?







      share|improve this question












      Apologies, this title is not the most elegant I've ever devised.



      But I assume a lot of people will have wondered this, and my question may be a dupe... all I can say is I haven't found it.



      When I say "scrolling" up, I mean using the "up arrow" key on the keyboard, which obviously scrolls you up through the history, starting at the most recent command.



      So you find a command maybe 30 commands back... and you run it. And then you want to run the command which originally came after it... is there is a snappy way of doing this? Or how do those fluent in BASH do this?









      share|improve this question











      share|improve this question




      share|improve this question










      asked Jan 14 at 15:59









      mike rodent

      40538




      40538




















          3 Answers
          3






          active

          oldest

          votes

















          up vote
          96
          down vote



          accepted










          Running the command with Ctrl+o instead of Enter will run a command from history and then queue up the next one instead of returning to the front of the bash history.






          share|improve this answer


















          • 2




            I just tried this in my own bash running in an xterm on NetBSD, and it doesn't work! Are there settings that can influence this? I have no .inputrc file. C-o is not mentioned in the manual page for readline(3).
            – Rhialto
            Jan 16 at 10:24











          • @Rhialto Are you using vi line editing (enabled with set -o vi) or emacs? Because Ctrl-O won't work with the former as far as I can tell.
            – B Layer
            Feb 13 at 13:17











          • ...but this can be remedied with the command: bind "C-o":operate-and-get-next (or add everything after bind to ~/.inputrc)
            – B Layer
            Feb 14 at 15:34











          • I found out what my problem is: ^O is taken as the Flush Output character (not supported on Linux), and readline doesn't disable this while it is active. I supplied a simple patch but the bash and readline maintainer maintains that this is Not A Bug. I disagree. See lists.gnu.org/archive/html/bug-readline/2018-01/msg00004.html
            – Rhialto
            Feb 14 at 21:15

















          up vote
          18
          down vote













          Jon Reinhold's answer is great, but there's is a much more powerful
          solution that I'll suggest. I also have a comment about a gotcha in
          Jon's answer, but I don't have enough reputation to be able to comment
          directly, so @Jon Reinhold, if you read this, please address my
          comment to you below.



          Bash includes a command fc, which takes as parameters line numbers
          of the bash history list. It then opens your default editor with those
          lines as text. At that point, you can optionally edit the lines. Then,
          when you exit the editor, bash executes those lines!



          An example of an edit you might want to make is append to all but the
          last line something like "; read -p"next ...". That will cause bash to
          execute each line, and prompt you before continuing.



          Comment for Jon Reinhold: Great answer, but you should qualify it
          because if the user has set bash variable HISTCONTROL to include
          erasedups, then after performing C-o the user will be confused
          because instead of the expected next command in the history being
          displayed, the one after that will be displayed. This is because bash
          has deleted the original instance of the executed command, and thus
          all the commands afterwards have shifted up one line, ie. to one lower
          index number in the history list.






          share|improve this answer




















          • thanks, in attempting to find the answer by searching I had come across the "fc" command. To me this represents the next stage in a BASH neophyte's slow baby steps along the path of glory towards KNOWLEDGE. I wanted the first baby step.
            – mike rodent
            Jan 14 at 16:35






          • 3




            @mikerodent No. So it happens fc predates both Ctl-o and bash itself. (Contrary to this answer it is also less useful.)
            – kubanczyk
            Jan 14 at 23:08










          • The issue with erasedups is clearly a bash bug (there could have been provision for this situation). Good to know, though.
            – alexis
            Jan 15 at 11:32










          • @kubanczyk That's up to debate. If it's a complex, complicated command depending on what needs fixing it would be far quicker for me to use my editor of choice to update the command. It would also be easier.
            – Pryftan
            Jan 15 at 22:41

















          up vote
          14
          down vote













          Another way to accomplish your desired behavior would be to get familiar with the bash readline shortcuts (of which CTRL-o is one I believe) and bash history searching.



          History search



          CTRL-r takes you into bash command history search, where you can begin typing the command you are searching for and bash will autocomplete the command for you. The autocomplete functionality is really pretty good. When the command you want to run is on the input line, you can ENTER to run the command, or press CTRL-e to move the cursor to the end of the command line and exit history search mode.



          The cool thing with CTRL-e at this point is that the history buffer is set contextually to this command. The next and previous commands now are the ones ran just before and after the line that the history search located for you. You can press the up or down arrows and grab the next command.



          History search is very powerful and a great way to avoid using the up arrow to get way back to the command in the first place. A quick history search can save lots of time manually searching through the history and then you can proceed with CTRL-o like Jon pointed out above.



          Readline Short Cuts



          If you are looking to up your overall bash-fu, I would recommend giving the readline shortcuts for the arrow keys a shot. You might find that they are more convenient and allow you to increase your typing speed, but of course YMMV.
          Here are a few more:




          1. CTRL-n for the next command (down arrow equivalent)


          2. CTRL-p for the previous command (up arrow equivalent)


          3. CTRL-b back a character (left arrow equivalent)


          4. CTRL-f forward a character (right arrow equivalent)

          These readline shortcuts (along with CTRL-a beginning of line and CTRL-e end of line) will increase your speed and efficiency at the command line imo.






          share|improve this answer






















          • Thanks... I suspected of course that "Ctrl-o" was merely one component element of a hinterland of stuff, and you're right: repeatedly pressing keys feels so wrong now we've managed to escape from the Dark Ages (M$) into the Age of Enlightenment. Memo: must acquire thick tome on BASH (or electronic equivalent) and read from cover to cover...
            – mike rodent
            Jan 15 at 21:06






          • 2




            I don't know. I find using modifier keys to be slower than arrows or any other single key press. As for EOL/etc. I tend to use home/end keys (stty -a shows some pretty handy things too, of course).
            – Pryftan
            Jan 15 at 22:46










          • @Pryftan Fair enough, the last sentence is presented as an opinion (see 'imo'). I do believe that staying on the home row of the keyboard over the long haul is a good strategy for working in the terminal or any other typing intensive tasks. Some folks have keyboards where the arrow keys are closer to the other characters, in that case perhaps the readline shortcuts are not a compelling convenience. I'll edit the answer to make this last point more clearly an opinion statement.
            – datUser
            Jan 16 at 13:46










          • @datUser Tbh I missed the 'imo' (or if I didn't I neglected to consider it - entirely possible). What's true though is the reverse search is useful (have a +1) if it works for you. Of course fc is also something (as already noted) and so is using ! (etc.). Lots of ways to skin a cat in Unices. As for keyboards that's quite true also: I have a Unicomp keyboard (love it and brings back memories) but of course there is also other keyboards to consider not to mention Dvorak. In the end the more options you have the better you're off and the easier your work (or play) is :)
            – Pryftan
            Jan 16 at 18:35











          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%2f417052%2fwith-bash-after-scrolling-up-to-a-previous-command-how-to-then-move-on-to-t%23new-answer', 'question_page');

          );

          Post as a guest






























          3 Answers
          3






          active

          oldest

          votes








          3 Answers
          3






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes








          up vote
          96
          down vote



          accepted










          Running the command with Ctrl+o instead of Enter will run a command from history and then queue up the next one instead of returning to the front of the bash history.






          share|improve this answer


















          • 2




            I just tried this in my own bash running in an xterm on NetBSD, and it doesn't work! Are there settings that can influence this? I have no .inputrc file. C-o is not mentioned in the manual page for readline(3).
            – Rhialto
            Jan 16 at 10:24











          • @Rhialto Are you using vi line editing (enabled with set -o vi) or emacs? Because Ctrl-O won't work with the former as far as I can tell.
            – B Layer
            Feb 13 at 13:17











          • ...but this can be remedied with the command: bind "C-o":operate-and-get-next (or add everything after bind to ~/.inputrc)
            – B Layer
            Feb 14 at 15:34











          • I found out what my problem is: ^O is taken as the Flush Output character (not supported on Linux), and readline doesn't disable this while it is active. I supplied a simple patch but the bash and readline maintainer maintains that this is Not A Bug. I disagree. See lists.gnu.org/archive/html/bug-readline/2018-01/msg00004.html
            – Rhialto
            Feb 14 at 21:15














          up vote
          96
          down vote



          accepted










          Running the command with Ctrl+o instead of Enter will run a command from history and then queue up the next one instead of returning to the front of the bash history.






          share|improve this answer


















          • 2




            I just tried this in my own bash running in an xterm on NetBSD, and it doesn't work! Are there settings that can influence this? I have no .inputrc file. C-o is not mentioned in the manual page for readline(3).
            – Rhialto
            Jan 16 at 10:24











          • @Rhialto Are you using vi line editing (enabled with set -o vi) or emacs? Because Ctrl-O won't work with the former as far as I can tell.
            – B Layer
            Feb 13 at 13:17











          • ...but this can be remedied with the command: bind "C-o":operate-and-get-next (or add everything after bind to ~/.inputrc)
            – B Layer
            Feb 14 at 15:34











          • I found out what my problem is: ^O is taken as the Flush Output character (not supported on Linux), and readline doesn't disable this while it is active. I supplied a simple patch but the bash and readline maintainer maintains that this is Not A Bug. I disagree. See lists.gnu.org/archive/html/bug-readline/2018-01/msg00004.html
            – Rhialto
            Feb 14 at 21:15












          up vote
          96
          down vote



          accepted







          up vote
          96
          down vote



          accepted






          Running the command with Ctrl+o instead of Enter will run a command from history and then queue up the next one instead of returning to the front of the bash history.






          share|improve this answer














          Running the command with Ctrl+o instead of Enter will run a command from history and then queue up the next one instead of returning to the front of the bash history.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Jan 15 at 18:00









          Toby Speight

          4,9851928




          4,9851928










          answered Jan 14 at 16:02









          Jon Reinhold

          768412




          768412







          • 2




            I just tried this in my own bash running in an xterm on NetBSD, and it doesn't work! Are there settings that can influence this? I have no .inputrc file. C-o is not mentioned in the manual page for readline(3).
            – Rhialto
            Jan 16 at 10:24











          • @Rhialto Are you using vi line editing (enabled with set -o vi) or emacs? Because Ctrl-O won't work with the former as far as I can tell.
            – B Layer
            Feb 13 at 13:17











          • ...but this can be remedied with the command: bind "C-o":operate-and-get-next (or add everything after bind to ~/.inputrc)
            – B Layer
            Feb 14 at 15:34











          • I found out what my problem is: ^O is taken as the Flush Output character (not supported on Linux), and readline doesn't disable this while it is active. I supplied a simple patch but the bash and readline maintainer maintains that this is Not A Bug. I disagree. See lists.gnu.org/archive/html/bug-readline/2018-01/msg00004.html
            – Rhialto
            Feb 14 at 21:15












          • 2




            I just tried this in my own bash running in an xterm on NetBSD, and it doesn't work! Are there settings that can influence this? I have no .inputrc file. C-o is not mentioned in the manual page for readline(3).
            – Rhialto
            Jan 16 at 10:24











          • @Rhialto Are you using vi line editing (enabled with set -o vi) or emacs? Because Ctrl-O won't work with the former as far as I can tell.
            – B Layer
            Feb 13 at 13:17











          • ...but this can be remedied with the command: bind "C-o":operate-and-get-next (or add everything after bind to ~/.inputrc)
            – B Layer
            Feb 14 at 15:34











          • I found out what my problem is: ^O is taken as the Flush Output character (not supported on Linux), and readline doesn't disable this while it is active. I supplied a simple patch but the bash and readline maintainer maintains that this is Not A Bug. I disagree. See lists.gnu.org/archive/html/bug-readline/2018-01/msg00004.html
            – Rhialto
            Feb 14 at 21:15







          2




          2




          I just tried this in my own bash running in an xterm on NetBSD, and it doesn't work! Are there settings that can influence this? I have no .inputrc file. C-o is not mentioned in the manual page for readline(3).
          – Rhialto
          Jan 16 at 10:24





          I just tried this in my own bash running in an xterm on NetBSD, and it doesn't work! Are there settings that can influence this? I have no .inputrc file. C-o is not mentioned in the manual page for readline(3).
          – Rhialto
          Jan 16 at 10:24













          @Rhialto Are you using vi line editing (enabled with set -o vi) or emacs? Because Ctrl-O won't work with the former as far as I can tell.
          – B Layer
          Feb 13 at 13:17





          @Rhialto Are you using vi line editing (enabled with set -o vi) or emacs? Because Ctrl-O won't work with the former as far as I can tell.
          – B Layer
          Feb 13 at 13:17













          ...but this can be remedied with the command: bind "C-o":operate-and-get-next (or add everything after bind to ~/.inputrc)
          – B Layer
          Feb 14 at 15:34





          ...but this can be remedied with the command: bind "C-o":operate-and-get-next (or add everything after bind to ~/.inputrc)
          – B Layer
          Feb 14 at 15:34













          I found out what my problem is: ^O is taken as the Flush Output character (not supported on Linux), and readline doesn't disable this while it is active. I supplied a simple patch but the bash and readline maintainer maintains that this is Not A Bug. I disagree. See lists.gnu.org/archive/html/bug-readline/2018-01/msg00004.html
          – Rhialto
          Feb 14 at 21:15




          I found out what my problem is: ^O is taken as the Flush Output character (not supported on Linux), and readline doesn't disable this while it is active. I supplied a simple patch but the bash and readline maintainer maintains that this is Not A Bug. I disagree. See lists.gnu.org/archive/html/bug-readline/2018-01/msg00004.html
          – Rhialto
          Feb 14 at 21:15












          up vote
          18
          down vote













          Jon Reinhold's answer is great, but there's is a much more powerful
          solution that I'll suggest. I also have a comment about a gotcha in
          Jon's answer, but I don't have enough reputation to be able to comment
          directly, so @Jon Reinhold, if you read this, please address my
          comment to you below.



          Bash includes a command fc, which takes as parameters line numbers
          of the bash history list. It then opens your default editor with those
          lines as text. At that point, you can optionally edit the lines. Then,
          when you exit the editor, bash executes those lines!



          An example of an edit you might want to make is append to all but the
          last line something like "; read -p"next ...". That will cause bash to
          execute each line, and prompt you before continuing.



          Comment for Jon Reinhold: Great answer, but you should qualify it
          because if the user has set bash variable HISTCONTROL to include
          erasedups, then after performing C-o the user will be confused
          because instead of the expected next command in the history being
          displayed, the one after that will be displayed. This is because bash
          has deleted the original instance of the executed command, and thus
          all the commands afterwards have shifted up one line, ie. to one lower
          index number in the history list.






          share|improve this answer




















          • thanks, in attempting to find the answer by searching I had come across the "fc" command. To me this represents the next stage in a BASH neophyte's slow baby steps along the path of glory towards KNOWLEDGE. I wanted the first baby step.
            – mike rodent
            Jan 14 at 16:35






          • 3




            @mikerodent No. So it happens fc predates both Ctl-o and bash itself. (Contrary to this answer it is also less useful.)
            – kubanczyk
            Jan 14 at 23:08










          • The issue with erasedups is clearly a bash bug (there could have been provision for this situation). Good to know, though.
            – alexis
            Jan 15 at 11:32










          • @kubanczyk That's up to debate. If it's a complex, complicated command depending on what needs fixing it would be far quicker for me to use my editor of choice to update the command. It would also be easier.
            – Pryftan
            Jan 15 at 22:41














          up vote
          18
          down vote













          Jon Reinhold's answer is great, but there's is a much more powerful
          solution that I'll suggest. I also have a comment about a gotcha in
          Jon's answer, but I don't have enough reputation to be able to comment
          directly, so @Jon Reinhold, if you read this, please address my
          comment to you below.



          Bash includes a command fc, which takes as parameters line numbers
          of the bash history list. It then opens your default editor with those
          lines as text. At that point, you can optionally edit the lines. Then,
          when you exit the editor, bash executes those lines!



          An example of an edit you might want to make is append to all but the
          last line something like "; read -p"next ...". That will cause bash to
          execute each line, and prompt you before continuing.



          Comment for Jon Reinhold: Great answer, but you should qualify it
          because if the user has set bash variable HISTCONTROL to include
          erasedups, then after performing C-o the user will be confused
          because instead of the expected next command in the history being
          displayed, the one after that will be displayed. This is because bash
          has deleted the original instance of the executed command, and thus
          all the commands afterwards have shifted up one line, ie. to one lower
          index number in the history list.






          share|improve this answer




















          • thanks, in attempting to find the answer by searching I had come across the "fc" command. To me this represents the next stage in a BASH neophyte's slow baby steps along the path of glory towards KNOWLEDGE. I wanted the first baby step.
            – mike rodent
            Jan 14 at 16:35






          • 3




            @mikerodent No. So it happens fc predates both Ctl-o and bash itself. (Contrary to this answer it is also less useful.)
            – kubanczyk
            Jan 14 at 23:08










          • The issue with erasedups is clearly a bash bug (there could have been provision for this situation). Good to know, though.
            – alexis
            Jan 15 at 11:32










          • @kubanczyk That's up to debate. If it's a complex, complicated command depending on what needs fixing it would be far quicker for me to use my editor of choice to update the command. It would also be easier.
            – Pryftan
            Jan 15 at 22:41












          up vote
          18
          down vote










          up vote
          18
          down vote









          Jon Reinhold's answer is great, but there's is a much more powerful
          solution that I'll suggest. I also have a comment about a gotcha in
          Jon's answer, but I don't have enough reputation to be able to comment
          directly, so @Jon Reinhold, if you read this, please address my
          comment to you below.



          Bash includes a command fc, which takes as parameters line numbers
          of the bash history list. It then opens your default editor with those
          lines as text. At that point, you can optionally edit the lines. Then,
          when you exit the editor, bash executes those lines!



          An example of an edit you might want to make is append to all but the
          last line something like "; read -p"next ...". That will cause bash to
          execute each line, and prompt you before continuing.



          Comment for Jon Reinhold: Great answer, but you should qualify it
          because if the user has set bash variable HISTCONTROL to include
          erasedups, then after performing C-o the user will be confused
          because instead of the expected next command in the history being
          displayed, the one after that will be displayed. This is because bash
          has deleted the original instance of the executed command, and thus
          all the commands afterwards have shifted up one line, ie. to one lower
          index number in the history list.






          share|improve this answer












          Jon Reinhold's answer is great, but there's is a much more powerful
          solution that I'll suggest. I also have a comment about a gotcha in
          Jon's answer, but I don't have enough reputation to be able to comment
          directly, so @Jon Reinhold, if you read this, please address my
          comment to you below.



          Bash includes a command fc, which takes as parameters line numbers
          of the bash history list. It then opens your default editor with those
          lines as text. At that point, you can optionally edit the lines. Then,
          when you exit the editor, bash executes those lines!



          An example of an edit you might want to make is append to all but the
          last line something like "; read -p"next ...". That will cause bash to
          execute each line, and prompt you before continuing.



          Comment for Jon Reinhold: Great answer, but you should qualify it
          because if the user has set bash variable HISTCONTROL to include
          erasedups, then after performing C-o the user will be confused
          because instead of the expected next command in the history being
          displayed, the one after that will be displayed. This is because bash
          has deleted the original instance of the executed command, and thus
          all the commands afterwards have shifted up one line, ie. to one lower
          index number in the history list.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Jan 14 at 16:28









          user1404316

          2,314520




          2,314520











          • thanks, in attempting to find the answer by searching I had come across the "fc" command. To me this represents the next stage in a BASH neophyte's slow baby steps along the path of glory towards KNOWLEDGE. I wanted the first baby step.
            – mike rodent
            Jan 14 at 16:35






          • 3




            @mikerodent No. So it happens fc predates both Ctl-o and bash itself. (Contrary to this answer it is also less useful.)
            – kubanczyk
            Jan 14 at 23:08










          • The issue with erasedups is clearly a bash bug (there could have been provision for this situation). Good to know, though.
            – alexis
            Jan 15 at 11:32










          • @kubanczyk That's up to debate. If it's a complex, complicated command depending on what needs fixing it would be far quicker for me to use my editor of choice to update the command. It would also be easier.
            – Pryftan
            Jan 15 at 22:41
















          • thanks, in attempting to find the answer by searching I had come across the "fc" command. To me this represents the next stage in a BASH neophyte's slow baby steps along the path of glory towards KNOWLEDGE. I wanted the first baby step.
            – mike rodent
            Jan 14 at 16:35






          • 3




            @mikerodent No. So it happens fc predates both Ctl-o and bash itself. (Contrary to this answer it is also less useful.)
            – kubanczyk
            Jan 14 at 23:08










          • The issue with erasedups is clearly a bash bug (there could have been provision for this situation). Good to know, though.
            – alexis
            Jan 15 at 11:32










          • @kubanczyk That's up to debate. If it's a complex, complicated command depending on what needs fixing it would be far quicker for me to use my editor of choice to update the command. It would also be easier.
            – Pryftan
            Jan 15 at 22:41















          thanks, in attempting to find the answer by searching I had come across the "fc" command. To me this represents the next stage in a BASH neophyte's slow baby steps along the path of glory towards KNOWLEDGE. I wanted the first baby step.
          – mike rodent
          Jan 14 at 16:35




          thanks, in attempting to find the answer by searching I had come across the "fc" command. To me this represents the next stage in a BASH neophyte's slow baby steps along the path of glory towards KNOWLEDGE. I wanted the first baby step.
          – mike rodent
          Jan 14 at 16:35




          3




          3




          @mikerodent No. So it happens fc predates both Ctl-o and bash itself. (Contrary to this answer it is also less useful.)
          – kubanczyk
          Jan 14 at 23:08




          @mikerodent No. So it happens fc predates both Ctl-o and bash itself. (Contrary to this answer it is also less useful.)
          – kubanczyk
          Jan 14 at 23:08












          The issue with erasedups is clearly a bash bug (there could have been provision for this situation). Good to know, though.
          – alexis
          Jan 15 at 11:32




          The issue with erasedups is clearly a bash bug (there could have been provision for this situation). Good to know, though.
          – alexis
          Jan 15 at 11:32












          @kubanczyk That's up to debate. If it's a complex, complicated command depending on what needs fixing it would be far quicker for me to use my editor of choice to update the command. It would also be easier.
          – Pryftan
          Jan 15 at 22:41




          @kubanczyk That's up to debate. If it's a complex, complicated command depending on what needs fixing it would be far quicker for me to use my editor of choice to update the command. It would also be easier.
          – Pryftan
          Jan 15 at 22:41










          up vote
          14
          down vote













          Another way to accomplish your desired behavior would be to get familiar with the bash readline shortcuts (of which CTRL-o is one I believe) and bash history searching.



          History search



          CTRL-r takes you into bash command history search, where you can begin typing the command you are searching for and bash will autocomplete the command for you. The autocomplete functionality is really pretty good. When the command you want to run is on the input line, you can ENTER to run the command, or press CTRL-e to move the cursor to the end of the command line and exit history search mode.



          The cool thing with CTRL-e at this point is that the history buffer is set contextually to this command. The next and previous commands now are the ones ran just before and after the line that the history search located for you. You can press the up or down arrows and grab the next command.



          History search is very powerful and a great way to avoid using the up arrow to get way back to the command in the first place. A quick history search can save lots of time manually searching through the history and then you can proceed with CTRL-o like Jon pointed out above.



          Readline Short Cuts



          If you are looking to up your overall bash-fu, I would recommend giving the readline shortcuts for the arrow keys a shot. You might find that they are more convenient and allow you to increase your typing speed, but of course YMMV.
          Here are a few more:




          1. CTRL-n for the next command (down arrow equivalent)


          2. CTRL-p for the previous command (up arrow equivalent)


          3. CTRL-b back a character (left arrow equivalent)


          4. CTRL-f forward a character (right arrow equivalent)

          These readline shortcuts (along with CTRL-a beginning of line and CTRL-e end of line) will increase your speed and efficiency at the command line imo.






          share|improve this answer






















          • Thanks... I suspected of course that "Ctrl-o" was merely one component element of a hinterland of stuff, and you're right: repeatedly pressing keys feels so wrong now we've managed to escape from the Dark Ages (M$) into the Age of Enlightenment. Memo: must acquire thick tome on BASH (or electronic equivalent) and read from cover to cover...
            – mike rodent
            Jan 15 at 21:06






          • 2




            I don't know. I find using modifier keys to be slower than arrows or any other single key press. As for EOL/etc. I tend to use home/end keys (stty -a shows some pretty handy things too, of course).
            – Pryftan
            Jan 15 at 22:46










          • @Pryftan Fair enough, the last sentence is presented as an opinion (see 'imo'). I do believe that staying on the home row of the keyboard over the long haul is a good strategy for working in the terminal or any other typing intensive tasks. Some folks have keyboards where the arrow keys are closer to the other characters, in that case perhaps the readline shortcuts are not a compelling convenience. I'll edit the answer to make this last point more clearly an opinion statement.
            – datUser
            Jan 16 at 13:46










          • @datUser Tbh I missed the 'imo' (or if I didn't I neglected to consider it - entirely possible). What's true though is the reverse search is useful (have a +1) if it works for you. Of course fc is also something (as already noted) and so is using ! (etc.). Lots of ways to skin a cat in Unices. As for keyboards that's quite true also: I have a Unicomp keyboard (love it and brings back memories) but of course there is also other keyboards to consider not to mention Dvorak. In the end the more options you have the better you're off and the easier your work (or play) is :)
            – Pryftan
            Jan 16 at 18:35















          up vote
          14
          down vote













          Another way to accomplish your desired behavior would be to get familiar with the bash readline shortcuts (of which CTRL-o is one I believe) and bash history searching.



          History search



          CTRL-r takes you into bash command history search, where you can begin typing the command you are searching for and bash will autocomplete the command for you. The autocomplete functionality is really pretty good. When the command you want to run is on the input line, you can ENTER to run the command, or press CTRL-e to move the cursor to the end of the command line and exit history search mode.



          The cool thing with CTRL-e at this point is that the history buffer is set contextually to this command. The next and previous commands now are the ones ran just before and after the line that the history search located for you. You can press the up or down arrows and grab the next command.



          History search is very powerful and a great way to avoid using the up arrow to get way back to the command in the first place. A quick history search can save lots of time manually searching through the history and then you can proceed with CTRL-o like Jon pointed out above.



          Readline Short Cuts



          If you are looking to up your overall bash-fu, I would recommend giving the readline shortcuts for the arrow keys a shot. You might find that they are more convenient and allow you to increase your typing speed, but of course YMMV.
          Here are a few more:




          1. CTRL-n for the next command (down arrow equivalent)


          2. CTRL-p for the previous command (up arrow equivalent)


          3. CTRL-b back a character (left arrow equivalent)


          4. CTRL-f forward a character (right arrow equivalent)

          These readline shortcuts (along with CTRL-a beginning of line and CTRL-e end of line) will increase your speed and efficiency at the command line imo.






          share|improve this answer






















          • Thanks... I suspected of course that "Ctrl-o" was merely one component element of a hinterland of stuff, and you're right: repeatedly pressing keys feels so wrong now we've managed to escape from the Dark Ages (M$) into the Age of Enlightenment. Memo: must acquire thick tome on BASH (or electronic equivalent) and read from cover to cover...
            – mike rodent
            Jan 15 at 21:06






          • 2




            I don't know. I find using modifier keys to be slower than arrows or any other single key press. As for EOL/etc. I tend to use home/end keys (stty -a shows some pretty handy things too, of course).
            – Pryftan
            Jan 15 at 22:46










          • @Pryftan Fair enough, the last sentence is presented as an opinion (see 'imo'). I do believe that staying on the home row of the keyboard over the long haul is a good strategy for working in the terminal or any other typing intensive tasks. Some folks have keyboards where the arrow keys are closer to the other characters, in that case perhaps the readline shortcuts are not a compelling convenience. I'll edit the answer to make this last point more clearly an opinion statement.
            – datUser
            Jan 16 at 13:46










          • @datUser Tbh I missed the 'imo' (or if I didn't I neglected to consider it - entirely possible). What's true though is the reverse search is useful (have a +1) if it works for you. Of course fc is also something (as already noted) and so is using ! (etc.). Lots of ways to skin a cat in Unices. As for keyboards that's quite true also: I have a Unicomp keyboard (love it and brings back memories) but of course there is also other keyboards to consider not to mention Dvorak. In the end the more options you have the better you're off and the easier your work (or play) is :)
            – Pryftan
            Jan 16 at 18:35













          up vote
          14
          down vote










          up vote
          14
          down vote









          Another way to accomplish your desired behavior would be to get familiar with the bash readline shortcuts (of which CTRL-o is one I believe) and bash history searching.



          History search



          CTRL-r takes you into bash command history search, where you can begin typing the command you are searching for and bash will autocomplete the command for you. The autocomplete functionality is really pretty good. When the command you want to run is on the input line, you can ENTER to run the command, or press CTRL-e to move the cursor to the end of the command line and exit history search mode.



          The cool thing with CTRL-e at this point is that the history buffer is set contextually to this command. The next and previous commands now are the ones ran just before and after the line that the history search located for you. You can press the up or down arrows and grab the next command.



          History search is very powerful and a great way to avoid using the up arrow to get way back to the command in the first place. A quick history search can save lots of time manually searching through the history and then you can proceed with CTRL-o like Jon pointed out above.



          Readline Short Cuts



          If you are looking to up your overall bash-fu, I would recommend giving the readline shortcuts for the arrow keys a shot. You might find that they are more convenient and allow you to increase your typing speed, but of course YMMV.
          Here are a few more:




          1. CTRL-n for the next command (down arrow equivalent)


          2. CTRL-p for the previous command (up arrow equivalent)


          3. CTRL-b back a character (left arrow equivalent)


          4. CTRL-f forward a character (right arrow equivalent)

          These readline shortcuts (along with CTRL-a beginning of line and CTRL-e end of line) will increase your speed and efficiency at the command line imo.






          share|improve this answer














          Another way to accomplish your desired behavior would be to get familiar with the bash readline shortcuts (of which CTRL-o is one I believe) and bash history searching.



          History search



          CTRL-r takes you into bash command history search, where you can begin typing the command you are searching for and bash will autocomplete the command for you. The autocomplete functionality is really pretty good. When the command you want to run is on the input line, you can ENTER to run the command, or press CTRL-e to move the cursor to the end of the command line and exit history search mode.



          The cool thing with CTRL-e at this point is that the history buffer is set contextually to this command. The next and previous commands now are the ones ran just before and after the line that the history search located for you. You can press the up or down arrows and grab the next command.



          History search is very powerful and a great way to avoid using the up arrow to get way back to the command in the first place. A quick history search can save lots of time manually searching through the history and then you can proceed with CTRL-o like Jon pointed out above.



          Readline Short Cuts



          If you are looking to up your overall bash-fu, I would recommend giving the readline shortcuts for the arrow keys a shot. You might find that they are more convenient and allow you to increase your typing speed, but of course YMMV.
          Here are a few more:




          1. CTRL-n for the next command (down arrow equivalent)


          2. CTRL-p for the previous command (up arrow equivalent)


          3. CTRL-b back a character (left arrow equivalent)


          4. CTRL-f forward a character (right arrow equivalent)

          These readline shortcuts (along with CTRL-a beginning of line and CTRL-e end of line) will increase your speed and efficiency at the command line imo.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Jan 16 at 13:53

























          answered Jan 15 at 20:59









          datUser

          2,2811032




          2,2811032











          • Thanks... I suspected of course that "Ctrl-o" was merely one component element of a hinterland of stuff, and you're right: repeatedly pressing keys feels so wrong now we've managed to escape from the Dark Ages (M$) into the Age of Enlightenment. Memo: must acquire thick tome on BASH (or electronic equivalent) and read from cover to cover...
            – mike rodent
            Jan 15 at 21:06






          • 2




            I don't know. I find using modifier keys to be slower than arrows or any other single key press. As for EOL/etc. I tend to use home/end keys (stty -a shows some pretty handy things too, of course).
            – Pryftan
            Jan 15 at 22:46










          • @Pryftan Fair enough, the last sentence is presented as an opinion (see 'imo'). I do believe that staying on the home row of the keyboard over the long haul is a good strategy for working in the terminal or any other typing intensive tasks. Some folks have keyboards where the arrow keys are closer to the other characters, in that case perhaps the readline shortcuts are not a compelling convenience. I'll edit the answer to make this last point more clearly an opinion statement.
            – datUser
            Jan 16 at 13:46










          • @datUser Tbh I missed the 'imo' (or if I didn't I neglected to consider it - entirely possible). What's true though is the reverse search is useful (have a +1) if it works for you. Of course fc is also something (as already noted) and so is using ! (etc.). Lots of ways to skin a cat in Unices. As for keyboards that's quite true also: I have a Unicomp keyboard (love it and brings back memories) but of course there is also other keyboards to consider not to mention Dvorak. In the end the more options you have the better you're off and the easier your work (or play) is :)
            – Pryftan
            Jan 16 at 18:35

















          • Thanks... I suspected of course that "Ctrl-o" was merely one component element of a hinterland of stuff, and you're right: repeatedly pressing keys feels so wrong now we've managed to escape from the Dark Ages (M$) into the Age of Enlightenment. Memo: must acquire thick tome on BASH (or electronic equivalent) and read from cover to cover...
            – mike rodent
            Jan 15 at 21:06






          • 2




            I don't know. I find using modifier keys to be slower than arrows or any other single key press. As for EOL/etc. I tend to use home/end keys (stty -a shows some pretty handy things too, of course).
            – Pryftan
            Jan 15 at 22:46










          • @Pryftan Fair enough, the last sentence is presented as an opinion (see 'imo'). I do believe that staying on the home row of the keyboard over the long haul is a good strategy for working in the terminal or any other typing intensive tasks. Some folks have keyboards where the arrow keys are closer to the other characters, in that case perhaps the readline shortcuts are not a compelling convenience. I'll edit the answer to make this last point more clearly an opinion statement.
            – datUser
            Jan 16 at 13:46










          • @datUser Tbh I missed the 'imo' (or if I didn't I neglected to consider it - entirely possible). What's true though is the reverse search is useful (have a +1) if it works for you. Of course fc is also something (as already noted) and so is using ! (etc.). Lots of ways to skin a cat in Unices. As for keyboards that's quite true also: I have a Unicomp keyboard (love it and brings back memories) but of course there is also other keyboards to consider not to mention Dvorak. In the end the more options you have the better you're off and the easier your work (or play) is :)
            – Pryftan
            Jan 16 at 18:35
















          Thanks... I suspected of course that "Ctrl-o" was merely one component element of a hinterland of stuff, and you're right: repeatedly pressing keys feels so wrong now we've managed to escape from the Dark Ages (M$) into the Age of Enlightenment. Memo: must acquire thick tome on BASH (or electronic equivalent) and read from cover to cover...
          – mike rodent
          Jan 15 at 21:06




          Thanks... I suspected of course that "Ctrl-o" was merely one component element of a hinterland of stuff, and you're right: repeatedly pressing keys feels so wrong now we've managed to escape from the Dark Ages (M$) into the Age of Enlightenment. Memo: must acquire thick tome on BASH (or electronic equivalent) and read from cover to cover...
          – mike rodent
          Jan 15 at 21:06




          2




          2




          I don't know. I find using modifier keys to be slower than arrows or any other single key press. As for EOL/etc. I tend to use home/end keys (stty -a shows some pretty handy things too, of course).
          – Pryftan
          Jan 15 at 22:46




          I don't know. I find using modifier keys to be slower than arrows or any other single key press. As for EOL/etc. I tend to use home/end keys (stty -a shows some pretty handy things too, of course).
          – Pryftan
          Jan 15 at 22:46












          @Pryftan Fair enough, the last sentence is presented as an opinion (see 'imo'). I do believe that staying on the home row of the keyboard over the long haul is a good strategy for working in the terminal or any other typing intensive tasks. Some folks have keyboards where the arrow keys are closer to the other characters, in that case perhaps the readline shortcuts are not a compelling convenience. I'll edit the answer to make this last point more clearly an opinion statement.
          – datUser
          Jan 16 at 13:46




          @Pryftan Fair enough, the last sentence is presented as an opinion (see 'imo'). I do believe that staying on the home row of the keyboard over the long haul is a good strategy for working in the terminal or any other typing intensive tasks. Some folks have keyboards where the arrow keys are closer to the other characters, in that case perhaps the readline shortcuts are not a compelling convenience. I'll edit the answer to make this last point more clearly an opinion statement.
          – datUser
          Jan 16 at 13:46












          @datUser Tbh I missed the 'imo' (or if I didn't I neglected to consider it - entirely possible). What's true though is the reverse search is useful (have a +1) if it works for you. Of course fc is also something (as already noted) and so is using ! (etc.). Lots of ways to skin a cat in Unices. As for keyboards that's quite true also: I have a Unicomp keyboard (love it and brings back memories) but of course there is also other keyboards to consider not to mention Dvorak. In the end the more options you have the better you're off and the easier your work (or play) is :)
          – Pryftan
          Jan 16 at 18:35





          @datUser Tbh I missed the 'imo' (or if I didn't I neglected to consider it - entirely possible). What's true though is the reverse search is useful (have a +1) if it works for you. Of course fc is also something (as already noted) and so is using ! (etc.). Lots of ways to skin a cat in Unices. As for keyboards that's quite true also: I have a Unicomp keyboard (love it and brings back memories) but of course there is also other keyboards to consider not to mention Dvorak. In the end the more options you have the better you're off and the easier your work (or play) is :)
          – Pryftan
          Jan 16 at 18:35













           

          draft saved


          draft discarded


























           


          draft saved


          draft discarded














          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f417052%2fwith-bash-after-scrolling-up-to-a-previous-command-how-to-then-move-on-to-t%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?

          Bahrain

          Postfix configuration issue with fips on centos 7; mailgun relay