Ah now that I analyze the behavior on a MacOS, I see the thing is this: If I am typing text in, and receive new text, the cursor continues typing. UNLESS I backspace to the beginning of the (current) line, and then it echos the previously typed text. Thanks for the tip! I will try that out. But, I did solve this at one point in the past, with a bash profile change, so I know that is possible. On 02.08.20 17:49, The Wanderer wrote: > On 2020-08-02 at 11:34, Esteban L wrote: > >> Hello, >> >> I use terminal window/bash quite a bit, and have a quirky behavior >> on Debian, at least not on Mac OS terminal window. I think it's just >> a default issue, that can be altered -- as I had the exact same >> problem years ago -- that I was able to resolve, which I again turns >> up. I forgot the solution, since it was so simple. >> >> The question is hard for me to formulate, so I will just describe >> everything, and maybe someone can help? >> >> What happens: >> >> I use terminal (in a game or even with ping for simplicity): >> >> I can type into the terminal. >> >> I can backspace - as expected. >> >> However, if i receive new data - my typed text is still in the >> buffer, but is not "echo'd" to a new line. This is more or less OK, >> UNLESS I need to backspace and clear some text. I just can't tell how >> far I have backspaced, since the line is not echoed. >> >> Maybe best description is: >> >> I am tying this senten >> >> <receive new input here from the terminal> >> >> ce, and it's fine...but i >> >> <receive new input> >> >> I backspace now, as I want to replace the above line "and it's fine" >> and what comes after it to change it to "it's not fine" >> >> >> So, best description is, if i backspace upon receiving new data, I >> cannot see the line that I was typing. > This is a manifestation of the longstanding scenario of "terminal output > steps all over the shell prompt", and related. > > What I usually do, in similar circumstances, is to press first the Up > arrow and then the Down arrow. > > This goes one level up into shell history, so that bash removes the > currently-displayed in-progress command and displays the > previously-entered one, and then one level back down, so that bash > removes the currently-displayed previously-entered command and displays > the one still in progress. > > Not necessarily the best solution, but it usually gets the job done, > assuming your environment supports this type of history functionality in > the first place. > >> Any Bash experts able to lend a hand? >> >> Last time I had this issue, I remember I had to go into .bashrc and >> add/change something. I just don't know what it was. > I have no idea what it could be either. By my understanding of the > nature of the problem and what leads it to occur, I don't see how any > bash configuration could possibly avoid it. > -- https://www.little-beak.com "Doing what we can."
Attachment:
signature.asc
Description: OpenPGP digital signature