My bash shell doesn't start a new line upon Return, and doesn't show typed command
In my interactive bash shell run in lxterminal's window, I don't know what I have messed up.
Typing Return key doesn't start a new line, but Ctrl-C will.
$ ^C
$ $ $ $ $ ^C
$ ^C
$ $ $ $ $ $ $
When I type a command, although hitting Return key will execute it, the typed command is not visible.
Before that happened, I was running some command sudo lsof ... | less
(or sudo netstat ... | less
), and there seemed no output, so I hit ctrl-c and/or q multiple times in an arbitrary order. When I finally got out of less
, that problem with bash happened.
Did I accidentally redirect the stdout of the shell somewhere else?
I don't want to close the shell, so is there some way to fix the problem? Thanks.
bash less
add a comment |
In my interactive bash shell run in lxterminal's window, I don't know what I have messed up.
Typing Return key doesn't start a new line, but Ctrl-C will.
$ ^C
$ $ $ $ $ ^C
$ ^C
$ $ $ $ $ $ $
When I type a command, although hitting Return key will execute it, the typed command is not visible.
Before that happened, I was running some command sudo lsof ... | less
(or sudo netstat ... | less
), and there seemed no output, so I hit ctrl-c and/or q multiple times in an arbitrary order. When I finally got out of less
, that problem with bash happened.
Did I accidentally redirect the stdout of the shell somewhere else?
I don't want to close the shell, so is there some way to fix the problem? Thanks.
bash less
add a comment |
In my interactive bash shell run in lxterminal's window, I don't know what I have messed up.
Typing Return key doesn't start a new line, but Ctrl-C will.
$ ^C
$ $ $ $ $ ^C
$ ^C
$ $ $ $ $ $ $
When I type a command, although hitting Return key will execute it, the typed command is not visible.
Before that happened, I was running some command sudo lsof ... | less
(or sudo netstat ... | less
), and there seemed no output, so I hit ctrl-c and/or q multiple times in an arbitrary order. When I finally got out of less
, that problem with bash happened.
Did I accidentally redirect the stdout of the shell somewhere else?
I don't want to close the shell, so is there some way to fix the problem? Thanks.
bash less
In my interactive bash shell run in lxterminal's window, I don't know what I have messed up.
Typing Return key doesn't start a new line, but Ctrl-C will.
$ ^C
$ $ $ $ $ ^C
$ ^C
$ $ $ $ $ $ $
When I type a command, although hitting Return key will execute it, the typed command is not visible.
Before that happened, I was running some command sudo lsof ... | less
(or sudo netstat ... | less
), and there seemed no output, so I hit ctrl-c and/or q multiple times in an arbitrary order. When I finally got out of less
, that problem with bash happened.
Did I accidentally redirect the stdout of the shell somewhere else?
I don't want to close the shell, so is there some way to fix the problem? Thanks.
bash less
bash less
asked yesterday
TimTim
26.3k74246455
26.3k74246455
add a comment |
add a comment |
3 Answers
3
active
oldest
votes
I think your terminal may be stuck in a “funny” mode. You probably can reset it with the /usr/bin/reset
command, that normally comes with the ncurses
library.
Thanks. Do you know what can cause the problems (whichreset
can solve)?
– Tim
yesterday
7
Commands likeless
use the terminal in a different way, that most commands. To do what they do, they send control codes, and escape sequences to the terminal to change its mode. The should but it back, when they are done, but if you killless
with no opportunity for it to run the reset code, then you end up where you are. Ctrl-C should send a sig int, this should be caught, and the reset code run, before exit. Sending sig kill, or bugs inless
could cause the problem.
– ctrl-alt-delor
yesterday
add a comment |
If reset
(proposed in another answer) does not work, try:
stty sane
maybe followed by
tput rs1
I have the following alias defined (guess I picked it up somewhere on stackoverflow):
alias fixtty='reset; stty sane; tput rs1; clear; echo -e "33c"'
New contributor
add a comment |
As other answers suggest, simplest fix is just to run reset
.
As to the cause though? This usually happens when you cat
(or otherwise output) a binary file or data to your terminal.
Text is just text, and is not treated specially by the terminal, but there are also some special characters which aren't text, and are used to do things like move the cursor, clear the screen, change colour, stop echoing output, etc.
When you output binary data (rather than text), the terminal will see these special control characters and try to interpret them as they come through. You may notice the screen clears, flashes, or jumps around - this is all due to these control characters being honoured. You can experiment by running head /dev/urandom
in a new terminal to see what I mean.
Most of the time, if your terminal is behaving weird in anyway, just running reset
will fix it, by simply echoing all the special characters necessary to set the terminal into the basic default mode - e.g. there is a stop echoing input
code and also a start echoing input
code. The binary data has randomly included the former, which is why you can't see what your typing, and reset
will include the latter (among others), which will fix it.
add a comment |
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',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
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
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f492809%2fmy-bash-shell-doesnt-start-a-new-line-upon-return-and-doesnt-show-typed-comma%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
I think your terminal may be stuck in a “funny” mode. You probably can reset it with the /usr/bin/reset
command, that normally comes with the ncurses
library.
Thanks. Do you know what can cause the problems (whichreset
can solve)?
– Tim
yesterday
7
Commands likeless
use the terminal in a different way, that most commands. To do what they do, they send control codes, and escape sequences to the terminal to change its mode. The should but it back, when they are done, but if you killless
with no opportunity for it to run the reset code, then you end up where you are. Ctrl-C should send a sig int, this should be caught, and the reset code run, before exit. Sending sig kill, or bugs inless
could cause the problem.
– ctrl-alt-delor
yesterday
add a comment |
I think your terminal may be stuck in a “funny” mode. You probably can reset it with the /usr/bin/reset
command, that normally comes with the ncurses
library.
Thanks. Do you know what can cause the problems (whichreset
can solve)?
– Tim
yesterday
7
Commands likeless
use the terminal in a different way, that most commands. To do what they do, they send control codes, and escape sequences to the terminal to change its mode. The should but it back, when they are done, but if you killless
with no opportunity for it to run the reset code, then you end up where you are. Ctrl-C should send a sig int, this should be caught, and the reset code run, before exit. Sending sig kill, or bugs inless
could cause the problem.
– ctrl-alt-delor
yesterday
add a comment |
I think your terminal may be stuck in a “funny” mode. You probably can reset it with the /usr/bin/reset
command, that normally comes with the ncurses
library.
I think your terminal may be stuck in a “funny” mode. You probably can reset it with the /usr/bin/reset
command, that normally comes with the ncurses
library.
answered yesterday
user2233709user2233709
803311
803311
Thanks. Do you know what can cause the problems (whichreset
can solve)?
– Tim
yesterday
7
Commands likeless
use the terminal in a different way, that most commands. To do what they do, they send control codes, and escape sequences to the terminal to change its mode. The should but it back, when they are done, but if you killless
with no opportunity for it to run the reset code, then you end up where you are. Ctrl-C should send a sig int, this should be caught, and the reset code run, before exit. Sending sig kill, or bugs inless
could cause the problem.
– ctrl-alt-delor
yesterday
add a comment |
Thanks. Do you know what can cause the problems (whichreset
can solve)?
– Tim
yesterday
7
Commands likeless
use the terminal in a different way, that most commands. To do what they do, they send control codes, and escape sequences to the terminal to change its mode. The should but it back, when they are done, but if you killless
with no opportunity for it to run the reset code, then you end up where you are. Ctrl-C should send a sig int, this should be caught, and the reset code run, before exit. Sending sig kill, or bugs inless
could cause the problem.
– ctrl-alt-delor
yesterday
Thanks. Do you know what can cause the problems (which
reset
can solve)?– Tim
yesterday
Thanks. Do you know what can cause the problems (which
reset
can solve)?– Tim
yesterday
7
7
Commands like
less
use the terminal in a different way, that most commands. To do what they do, they send control codes, and escape sequences to the terminal to change its mode. The should but it back, when they are done, but if you kill less
with no opportunity for it to run the reset code, then you end up where you are. Ctrl-C should send a sig int, this should be caught, and the reset code run, before exit. Sending sig kill, or bugs in less
could cause the problem.– ctrl-alt-delor
yesterday
Commands like
less
use the terminal in a different way, that most commands. To do what they do, they send control codes, and escape sequences to the terminal to change its mode. The should but it back, when they are done, but if you kill less
with no opportunity for it to run the reset code, then you end up where you are. Ctrl-C should send a sig int, this should be caught, and the reset code run, before exit. Sending sig kill, or bugs in less
could cause the problem.– ctrl-alt-delor
yesterday
add a comment |
If reset
(proposed in another answer) does not work, try:
stty sane
maybe followed by
tput rs1
I have the following alias defined (guess I picked it up somewhere on stackoverflow):
alias fixtty='reset; stty sane; tput rs1; clear; echo -e "33c"'
New contributor
add a comment |
If reset
(proposed in another answer) does not work, try:
stty sane
maybe followed by
tput rs1
I have the following alias defined (guess I picked it up somewhere on stackoverflow):
alias fixtty='reset; stty sane; tput rs1; clear; echo -e "33c"'
New contributor
add a comment |
If reset
(proposed in another answer) does not work, try:
stty sane
maybe followed by
tput rs1
I have the following alias defined (guess I picked it up somewhere on stackoverflow):
alias fixtty='reset; stty sane; tput rs1; clear; echo -e "33c"'
New contributor
If reset
(proposed in another answer) does not work, try:
stty sane
maybe followed by
tput rs1
I have the following alias defined (guess I picked it up somewhere on stackoverflow):
alias fixtty='reset; stty sane; tput rs1; clear; echo -e "33c"'
New contributor
New contributor
answered yesterday
RalfRalf
2806
2806
New contributor
New contributor
add a comment |
add a comment |
As other answers suggest, simplest fix is just to run reset
.
As to the cause though? This usually happens when you cat
(or otherwise output) a binary file or data to your terminal.
Text is just text, and is not treated specially by the terminal, but there are also some special characters which aren't text, and are used to do things like move the cursor, clear the screen, change colour, stop echoing output, etc.
When you output binary data (rather than text), the terminal will see these special control characters and try to interpret them as they come through. You may notice the screen clears, flashes, or jumps around - this is all due to these control characters being honoured. You can experiment by running head /dev/urandom
in a new terminal to see what I mean.
Most of the time, if your terminal is behaving weird in anyway, just running reset
will fix it, by simply echoing all the special characters necessary to set the terminal into the basic default mode - e.g. there is a stop echoing input
code and also a start echoing input
code. The binary data has randomly included the former, which is why you can't see what your typing, and reset
will include the latter (among others), which will fix it.
add a comment |
As other answers suggest, simplest fix is just to run reset
.
As to the cause though? This usually happens when you cat
(or otherwise output) a binary file or data to your terminal.
Text is just text, and is not treated specially by the terminal, but there are also some special characters which aren't text, and are used to do things like move the cursor, clear the screen, change colour, stop echoing output, etc.
When you output binary data (rather than text), the terminal will see these special control characters and try to interpret them as they come through. You may notice the screen clears, flashes, or jumps around - this is all due to these control characters being honoured. You can experiment by running head /dev/urandom
in a new terminal to see what I mean.
Most of the time, if your terminal is behaving weird in anyway, just running reset
will fix it, by simply echoing all the special characters necessary to set the terminal into the basic default mode - e.g. there is a stop echoing input
code and also a start echoing input
code. The binary data has randomly included the former, which is why you can't see what your typing, and reset
will include the latter (among others), which will fix it.
add a comment |
As other answers suggest, simplest fix is just to run reset
.
As to the cause though? This usually happens when you cat
(or otherwise output) a binary file or data to your terminal.
Text is just text, and is not treated specially by the terminal, but there are also some special characters which aren't text, and are used to do things like move the cursor, clear the screen, change colour, stop echoing output, etc.
When you output binary data (rather than text), the terminal will see these special control characters and try to interpret them as they come through. You may notice the screen clears, flashes, or jumps around - this is all due to these control characters being honoured. You can experiment by running head /dev/urandom
in a new terminal to see what I mean.
Most of the time, if your terminal is behaving weird in anyway, just running reset
will fix it, by simply echoing all the special characters necessary to set the terminal into the basic default mode - e.g. there is a stop echoing input
code and also a start echoing input
code. The binary data has randomly included the former, which is why you can't see what your typing, and reset
will include the latter (among others), which will fix it.
As other answers suggest, simplest fix is just to run reset
.
As to the cause though? This usually happens when you cat
(or otherwise output) a binary file or data to your terminal.
Text is just text, and is not treated specially by the terminal, but there are also some special characters which aren't text, and are used to do things like move the cursor, clear the screen, change colour, stop echoing output, etc.
When you output binary data (rather than text), the terminal will see these special control characters and try to interpret them as they come through. You may notice the screen clears, flashes, or jumps around - this is all due to these control characters being honoured. You can experiment by running head /dev/urandom
in a new terminal to see what I mean.
Most of the time, if your terminal is behaving weird in anyway, just running reset
will fix it, by simply echoing all the special characters necessary to set the terminal into the basic default mode - e.g. there is a stop echoing input
code and also a start echoing input
code. The binary data has randomly included the former, which is why you can't see what your typing, and reset
will include the latter (among others), which will fix it.
answered yesterday
GarethHumphriesAccGarethHumphriesAcc
1412
1412
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
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
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f492809%2fmy-bash-shell-doesnt-start-a-new-line-upon-return-and-doesnt-show-typed-comma%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
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
Required, but never shown
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
Required, but never shown
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
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown