With BASH after âscrollingâ up to a previous command⦠how to then move on to the next in this history?
Clash Royale CLAN TAG#URR8PPP
up vote
58
down vote
favorite
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?
bash command-history
add a comment |Â
up vote
58
down vote
favorite
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?
bash command-history
add a comment |Â
up vote
58
down vote
favorite
up vote
58
down vote
favorite
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?
bash command-history
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?
bash command-history
asked Jan 14 at 15:59
mike rodent
40538
40538
add a comment |Â
add a comment |Â
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.
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 usingvi
line editing (enabled withset -o vi
) oremacs
? BecauseCtrl-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 afterbind
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
add a comment |Â
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 includeerasedups
, 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.
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 happensfc
predates bothCtl-o
andbash
itself. (Contrary to this answer it is also less useful.)
â kubanczyk
Jan 14 at 23:08
The issue witherasedups
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
add a comment |Â
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:
CTRL-n for the next command (down arrow equivalent)
CTRL-p for the previous command (up arrow equivalent)
CTRL-b back a character (left arrow equivalent)
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.
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
add a comment |Â
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.
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 usingvi
line editing (enabled withset -o vi
) oremacs
? BecauseCtrl-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 afterbind
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
add a comment |Â
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.
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 usingvi
line editing (enabled withset -o vi
) oremacs
? BecauseCtrl-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 afterbind
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
add a comment |Â
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.
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.
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 usingvi
line editing (enabled withset -o vi
) oremacs
? BecauseCtrl-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 afterbind
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
add a comment |Â
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 usingvi
line editing (enabled withset -o vi
) oremacs
? BecauseCtrl-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 afterbind
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
add a comment |Â
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 includeerasedups
, 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.
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 happensfc
predates bothCtl-o
andbash
itself. (Contrary to this answer it is also less useful.)
â kubanczyk
Jan 14 at 23:08
The issue witherasedups
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
add a comment |Â
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 includeerasedups
, 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.
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 happensfc
predates bothCtl-o
andbash
itself. (Contrary to this answer it is also less useful.)
â kubanczyk
Jan 14 at 23:08
The issue witherasedups
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
add a comment |Â
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 includeerasedups
, 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.
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 includeerasedups
, 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.
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 happensfc
predates bothCtl-o
andbash
itself. (Contrary to this answer it is also less useful.)
â kubanczyk
Jan 14 at 23:08
The issue witherasedups
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
add a comment |Â
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 happensfc
predates bothCtl-o
andbash
itself. (Contrary to this answer it is also less useful.)
â kubanczyk
Jan 14 at 23:08
The issue witherasedups
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
add a comment |Â
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:
CTRL-n for the next command (down arrow equivalent)
CTRL-p for the previous command (up arrow equivalent)
CTRL-b back a character (left arrow equivalent)
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.
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
add a comment |Â
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:
CTRL-n for the next command (down arrow equivalent)
CTRL-p for the previous command (up arrow equivalent)
CTRL-b back a character (left arrow equivalent)
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.
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
add a comment |Â
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:
CTRL-n for the next command (down arrow equivalent)
CTRL-p for the previous command (up arrow equivalent)
CTRL-b back a character (left arrow equivalent)
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.
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:
CTRL-n for the next command (down arrow equivalent)
CTRL-p for the previous command (up arrow equivalent)
CTRL-b back a character (left arrow equivalent)
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.
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
add a comment |Â
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
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%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
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