Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #225742 > unrolled thread

Re: Bash question hard to formulate

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Bash question hard to formulate The Wanderer <wanderer@fastmail.fm> - 2020-08-02 18:00 +0200
    Re: Bash question hard to formulate Esteban L <esteban@little-beak.com> - 2020-08-02 18:10 +0200

#225742 — Re: Bash question hard to formulate

[Multipart message — attachments visible in raw view] — view raw

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.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [next] | [standalone]

#225744

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web