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

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

Get Terminal to Echo line in buffer on backspace

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

Contents

  Get Terminal to Echo line in buffer on backspace Thomas Anderson <thomas.anderson@little-beak.com> - 2021-08-30 14:40 +0200
    Re: Get Terminal to Echo line in buffer on backspace Nicolas George <george@nsup.org> - 2021-08-30 14:50 +0200
    Re: Get Terminal to Echo line in buffer on backspace Greg Wooledge <greg@wooledge.org> - 2021-08-30 14:50 +0200
      Re: Get Terminal to Echo line in buffer on backspace Thomas Anderson <thomas.anderson@little-beak.com> - 2021-08-30 15:00 +0200
        Re: Get Terminal to Echo line in buffer on backspace Greg Wooledge <greg@wooledge.org> - 2021-08-30 15:20 +0200
          Re: Get Terminal to Echo line in buffer on backspace songbird <songbird@anthive.com> - 2021-08-31 04:00 +0200
        Re: Get Terminal to Echo line in buffer on backspace Nicolas George <george@nsup.org> - 2021-08-30 17:10 +0200
      Re: Get Terminal to Echo line in buffer on backspace Nicolas George <george@nsup.org> - 2021-08-30 17:10 +0200
        Re: Get Terminal to Echo line in buffer on backspace Greg Wooledge <greg@wooledge.org> - 2021-08-30 17:40 +0200
          Re: Get Terminal to Echo line in buffer on backspace David Wright <deblis@lionunicorn.co.uk> - 2021-08-31 16:10 +0200
            Re: Get Terminal to Echo line in buffer on backspace Nicolas George <george@nsup.org> - 2021-08-31 16:20 +0200
              Re: Get Terminal to Echo line in buffer on backspace David Wright <deblis@lionunicorn.co.uk> - 2021-08-31 16:50 +0200
            Re: Get Terminal to Echo line in buffer on backspace Greg Wooledge <greg@wooledge.org> - 2021-08-31 16:50 +0200
              Re: Get Terminal to Echo line in buffer on backspace David Wright <deblis@lionunicorn.co.uk> - 2021-09-01 16:10 +0200
          Re: Get Terminal to Echo line in buffer on backspace Thomas Anderson <thomas.anderson@little-beak.com> - 2021-09-02 05:50 +0200
            Re: Get Terminal to Echo line in buffer on backspace Greg Wooledge <greg@wooledge.org> - 2021-09-02 15:40 +0200

#239455 — Get Terminal to Echo line in buffer on backspace

Hello Debian Users,


Maybe someone can help a brother out.


I would really like to be able to use terminal in such a way that when I
backspace, it will echo the line I am currently typing

1. say if I am receiving data into the terminal window, and

2. I have *not* pressed carriage return.

My issue is: if I am typing to terminal, while receiving data, and I
backspace -- I just don't know how far I have backspaced, I have to guess.

I think years ago, someone helped me add a line to my user bash settings.


If someone is familiar with how Mac's terminal emulator works, I would
like it to be like that.


Thanks to anyone that can help me out.

Neo

[toc] | [next] | [standalone]

#239456

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

Thomas Anderson (12021-08-30):
> I would really like to be able to use terminal in such a way that when I
> backspace, it will echo the line I am currently typing
> 
> 1. say if I am receiving data into the terminal window, and
> 
> 2. I have *not* pressed carriage return.
> 
> My issue is: if I am typing to terminal, while receiving data, and I
> backspace -- I just don't know how far I have backspaced, I have to guess.

If you are really talking about the terminal echo and line edition, then
the rprnt entry of the terminal line settings, as can be observed with
"stty -a", is what you are looking for. It is usually ^R.

I just checked:

$ { sleep 5; echo bar } & cat
[1] 263571
I type this before the 5 seconds.bar
[1]  + done       { sleep 5; echo bar; }
^R
I type this before the 5 seconds. And I can continue.

> I think years ago, someone helped me add a line to my user bash settings.

... but bash does not use the terminal line edition, it uses its own
line editor.

> If someone is familiar with how Mac's terminal emulator works, I would
> like it to be like that.

And I have no idea if Apple has done something non-standard here.
Knowing Apple, if they could break something standard, they did.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#239457

On Mon, Aug 30, 2021 at 12:26:32PM +0200, Thomas Anderson wrote:
> My issue is: if I am typing to terminal, while receiving data, and I
> backspace -- I just don't know how far I have backspaced, I have to guess.

What you want to do is redraw the current command.  The easiest way to
do this is to press Ctrl-L.  (Or if you're in vi mode, ESC Ctrl-L, and
then you'll need to go back to command mode.)

This clears the whole screen, though.  So if there's information you
need to preserve, take that into account.

Of course, another approach would be to stop doing whatever you're doing
that causes you to "receive data" while you're typing in an interactive
shell.  This might be a workflow issue of some kind.  Maybe you're
running some sort of background job that spews noise.  Maybe you simply
need to redirect that background job's output to a file.  Or maybe you
want to run the noisy background job as a foreground job in a separate
terminal (or a separate "tab", or a separate "virtual terminal" within
screen or tmux, etc.).

[toc] | [prev] | [next] | [standalone]

#239458

It's hard for me to describe, so here is an example of I am looking to
emulate (this is from a mac).

https://cloud.little-beak.com/s/KxpjEHJ5RTEYZmS

On debian, I have tried many different terminal emulators, and all the
visible options to get this type

of behavior, but have failed. =(

On 30/08/2021 14:41, Greg Wooledge wrote:
> On Mon, Aug 30, 2021 at 12:26:32PM +0200, Thomas Anderson wrote:
>> My issue is: if I am typing to terminal, while receiving data, and I
>> backspace -- I just don't know how far I have backspaced, I have to guess.
> What you want to do is redraw the current command.  The easiest way to
> do this is to press Ctrl-L.  (Or if you're in vi mode, ESC Ctrl-L, and
> then you'll need to go back to command mode.)
>
> This clears the whole screen, though.  So if there's information you
> need to preserve, take that into account.
>
> Of course, another approach would be to stop doing whatever you're doing
> that causes you to "receive data" while you're typing in an interactive
> shell.  This might be a workflow issue of some kind.  Maybe you're
> running some sort of background job that spews noise.  Maybe you simply
> need to redirect that background job's output to a file.  Or maybe you
> want to run the noisy background job as a foreground job in a separate
> terminal (or a separate "tab", or a separate "virtual terminal" within
> screen or tmux, etc.).
>

[toc] | [prev] | [next] | [standalone]

#239459

> On 30/08/2021 14:41, Greg Wooledge wrote:
> > What you want to do is redraw the current command.  The easiest way to
> > do this is to press Ctrl-L.  (Or if you're in vi mode, ESC Ctrl-L, and
> > then you'll need to go back to command mode.)

(I mis-spoke slightly.  I meant "exit from command mode".  But this user
probably isn't in vi mode so it probably doesn't matter.)

On Mon, Aug 30, 2021 at 02:57:42PM +0200, Thomas Anderson wrote:
> It's hard for me to describe, so here is an example of I am looking to
> emulate (this is from a mac).
> 
> https://cloud.little-beak.com/s/KxpjEHJ5RTEYZmS
> 
> On debian, I have tried many different terminal emulators, and all the
> visible options to get this type
> 
> of behavior, but have failed. =(

What you're asking for sounds like "every time I backspace, I want
the shell to erase the current prompt and command and redraw them
from scratch, just in case there's some line noise on my terminal".
This is wasteful, and is not an available mode in bash.  I can't speak
for other shells.

You simply aren't going to get that behavior.  So I'm telling you how
you can work around the problem, or fix your *underlying problem*.

When "line noise" scribbles on your interactive shell prompt and makes
it too difficult to see what you're typing, you can either redraw the
screen (Ctrl-L), or power through, knowing what's there even if you
cannot see it, having faith in knowing what your fingers have done.
(For most of us, redrawing will be preferable.)

If the "line noise" is actually output from some job that *you* launched,
then you may wish to reconsider your work habits which are leading to
the undesired situation.  Run this background job in a different way,
which doesn't interfere with your ongoing work.

If you're getting *genuine* line noise (from an analog modem connection),
then you have my sympathy.  I haven't used an analog modem in many years.
But for modem use, there's a *really good reason* you don't redraw the
user's entire shell prompt & command on a frequent basis -- it's SLOW!
The amount of time it would take to redraw the prompt & command over a
slow (and noisy) analog modem line would be significant, and would annoy
you.  A lot.

[toc] | [prev] | [next] | [standalone]

#239500

Greg Wooledge wrote:
...
> You simply aren't going to get that behavior.  So I'm telling you how
> you can work around the problem, or fix your *underlying problem*.

  i agree, if you have something sending information to a console
or terminal, you can just open up another terminal or tab and then
use that instead.

  the other approach would be to redirect the output of the programs
that are causing problems to a file or /dev/null


  songbird

[toc] | [prev] | [next] | [standalone]

#239465

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

Thomas Anderson (12021-08-30):
> It's hard for me to describe, so here is an example of I am looking to
> emulate (this is from a mac).
> 
> https://cloud.little-beak.com/s/KxpjEHJ5RTEYZmS

Are you typing the ^R that appear on the screen?

What is the shell you are using? Does it have a line editor?

> On debian, I have tried many different terminal emulators, and all the
> visible options to get this type
> 
> of behavior, but have failed. =(

If you are using a shell with a line editor, the behavior comes from the
line editor, not from the terminal emulator. You really need to have a
clear idea of what you are doing.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#239464

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

Greg Wooledge (12021-08-30):
> What you want to do is redraw the current command.  The easiest way to
> do this is to press Ctrl-L.  (Or if you're in vi mode, ESC Ctrl-L, and
> then you'll need to go back to command mode.)
> 
> This clears the whole screen, though.  So if there's information you
> need to preserve, take that into account.

With Zsh, there is the "redisplay" zle command, it does exactly that:
redraw the prompt and command without clearing the screen.

I do not know if readline, used by bash, has the same feature available.

As I said, without a line editor (dash for example), it is a feature of
the terminal, usually invoked with ^R.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#239466

On Mon, Aug 30, 2021 at 05:05:49PM +0200, Nicolas George wrote:
> With Zsh, there is the "redisplay" zle command, it does exactly that:
> redraw the prompt and command without clearing the screen.
> 
> I do not know if readline, used by bash, has the same feature available.

Interesting.  I've never looked into this stuff before.

There is a "redraw-current-line" action in readline, but bash doesn't
bind any keys to it by default, neither in emacs nor vi mode.

But before I could even test that, I came across this section in the
man page:

       clear-screen (C-l)
              Clear the screen, then redraw the current line, leaving the cur‐
              rent  line  at the top of the screen.  With an argument, refresh
              the current line without clearing the screen.

That bit about "With an argument" is totally new information for me.
I'm a vi mode user, so I tried it as indicated: I typed some random
stuff, and then I pressed ESC 0 Ctrl-L.  It didn't work (it cleared the
whole screen).  So maybe an argument of 0 doesn't count... oh, right.
That's because 0 is a movement command ("jump to first column").  Next I
tried with a non-zero argument: ESC 1 Ctrl-L.  That worked.  It redrew
the current prompt and command line, without clearing the screen.

I also tested in emacs mode, but I'm not as proficient there.  Again,
ESC 1 Ctrl-L seems to work.  And so does Alt-1 Ctrl-L, in my terminal
(but Alt-1 may not work in all terminals, so be warned).

For extra fun: Alt-0 Ctrl-L also works in emacs mode.  Apparently emacs
can handle an argument of 0, because 0 isn't a movement command in
emacs the way it is in vi.

So, there's that.  And that will do what the OP wants, albeit not
"automatically" the way they seemed to want.  They actually have to
press the keys.

I'll let others play around with binding redraw-current-line to some
unused key combo.  I'm betting it does the same thing, once bound.

[toc] | [prev] | [next] | [standalone]

#239518

On Mon 30 Aug 2021 at 11:39:14 (-0400), Greg Wooledge wrote:
> On Mon, Aug 30, 2021 at 05:05:49PM +0200, Nicolas George wrote:
> > With Zsh, there is the "redisplay" zle command, it does exactly that:
> > redraw the prompt and command without clearing the screen.
> > 
> > I do not know if readline, used by bash, has the same feature available.
> 
> Interesting.  I've never looked into this stuff before.
> 
> There is a "redraw-current-line" action in readline, but bash doesn't
> bind any keys to it by default, neither in emacs nor vi mode.
> 
> But before I could even test that, I came across this section in the
> man page:
> 
>        clear-screen (C-l)
>               Clear the screen, then redraw the current line, leaving the cur‐
>               rent  line  at the top of the screen.  With an argument, refresh
>               the current line without clearing the screen.
> 
> That bit about "With an argument" is totally new information for me.
> I'm a vi mode user, so I tried it as indicated: I typed some random
> stuff, and then I pressed ESC 0 Ctrl-L.  It didn't work (it cleared the
> whole screen).  So maybe an argument of 0 doesn't count... oh, right.
> That's because 0 is a movement command ("jump to first column").  Next I
> tried with a non-zero argument: ESC 1 Ctrl-L.  That worked.  It redrew
> the current prompt and command line, without clearing the screen.
> 
> I also tested in emacs mode, but I'm not as proficient there.  Again,
> ESC 1 Ctrl-L seems to work.  And so does Alt-1 Ctrl-L, in my terminal
> (but Alt-1 may not work in all terminals, so be warned).
> 
> For extra fun: Alt-0 Ctrl-L also works in emacs mode.  Apparently emacs
> can handle an argument of 0, because 0 isn't a movement command in
> emacs the way it is in vi.
> 
> So, there's that.  And that will do what the OP wants, albeit not
> "automatically" the way they seemed to want.  They actually have to
> press the keys.
> 
> I'll let others play around with binding redraw-current-line to some
> unused key combo.  I'm betting it does the same thing, once bound.

Bound or unbound, I couldn't make ESC 1 Ctrl-L do anything useful
while output is in progress (like a clean display of the typeahead
so far typed). I couldn't see a way to force echoing the line at
that time.

I bound ESC 1 Ctrl-L to Alt-SPACE in ~/.inputrc¹ and the main
effect (during output) was that Alt-SPACE reflected a Space
(whereas ESC 1 Ctrl-L reflected the expected ^[1^L.)

The only useful effect of that binding that I've seen is not when
typing ahead, but at the normal command line: the Alt-SPACE would
redraw the prompt and commandline without ceremony, whereas typing
the characters ESC 1 Ctrl-L produces a dialogue as it does its work,
printing (arg: 1) at the beginning of the line, then overwriting it.

Typing ahead into (normally infinite) output, like ping, is of
limited use anyway, because AIUI stopping the output with ^C
throws away the typeahead buffer anyway.

Six decades or so ago, when teletypes ran at lamentable speeds,
typeahead was fairly essential for power users. I remember that
the Phoenix/MVS system at Cambridge had a facility where typing
a space would suspend printing output at the end of a line
(like a perfectly timed XOFF), whereupon you could type a command
line undisturbed for up to 60 secs, until you either sent it or
aborted it (which would resume printing output).

But as songbird suggested, when you have multiple channels of
communication, facilities such as these become unnecessary.

¹ Normally, I have Alt-SPACE bound to " ", so that accidentally
  catching the Alt key when typing Space is ignored.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#239521

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

David Wright (12021-08-31):
> The only useful effect of that binding that I've seen is not when
> typing ahead, but at the normal command line

Of course. When typing ahead, your shell's line editor is not in action,
and therefore its bindings will have no effect immediately. They will
have an effect when the interactive shell resumes and received the
keystrokes.

Before that, you are running with the tty's line editor, and therefore
its bindings are the one in action. See the output of stty -a.

The behavior of ttys is one of the trickiest part of Unix's user
interface, and we are directly dealing with it here. Be sure you
understand what is going on and who is doing what task; otherwise you
will be utterly confused.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#239527

On Tue 31 Aug 2021 at 16:13:52 (+0200), Nicolas George wrote:
> David Wright (12021-08-31):
> > The only useful effect of that binding that I've seen is not when
> > typing ahead, but at the normal command line
> 
> Of course. When typing ahead, your shell's line editor is not in action,
> and therefore its bindings will have no effect immediately. They will
> have an effect when the interactive shell resumes and received the
> keystrokes.
> 
> Before that, you are running with the tty's line editor, and therefore
> its bindings are the one in action. See the output of stty -a.
> 
> The behavior of ttys is one of the trickiest part of Unix's user
> interface, and we are directly dealing with it here. Be sure you
> understand what is going on and who is doing what task; otherwise you
> will be utterly confused.

That seems reasonable. So in summary, ESC 1 ^L gives a clean refresh
of the command line when you're at a shell prompt, and ^R prints the
contents of your typeahead buffer when you're not.

I think that's what the OP /really/ wants. I can see no point in tying
the ^R refresh to the Backspace key: if you rubout four characters,
why would you want four refreshes?

Perhaps, in some way, the OP hasn't got rprnt = ^R listed in their
$ stty -a   output, but that's beyond my knowledge.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#239525

On Tue, Aug 31, 2021 at 09:07:49AM -0500, David Wright wrote:
> Bound or unbound, I couldn't make ESC 1 Ctrl-L do anything useful
> while output is in progress (like a clean display of the typeahead
> so far typed). I couldn't see a way to force echoing the line at
> that time.

??

> Six decades or so ago, when teletypes ran at lamentable speeds,
> typeahead was fairly essential for power users. I remember that
> the Phoenix/MVS system at Cambridge had a facility where typing
> a space would suspend printing output at the end of a line
> (like a perfectly timed XOFF), whereupon you could type a command
> line undisturbed for up to 60 secs, until you either sent it or
> aborted it (which would resume printing output).

So... you're talking about something *completely* different from the
OP's requirement.

The OP, as far as I've been able to determine, has a *background* job
that's writing characters to the terminal while they're typing into
an interactive shell's prompt.  The shell is not running a foreground
command.  There is no "type ahead" involved.

You're talking about running a *foreground* command, and then trying to
type another command while this one is still running.  It's a totally
different scenario.

The Ctrl-L stuff (in all its variations) is intended only for the OP's
scenario.  They're typing at a shell prompt, and a bit of "noise"
is thrown onto the screen, disrupting them.  It's a one-time event, and
they'd just like to wipe away the noise so they can see what they're
typing (and specifically so that backspace is handled "correctly").

It won't help in your scenario, at all.

[toc] | [prev] | [next] | [standalone]

#239558

On Tue 31 Aug 2021 at 10:40:06 (-0400), Greg Wooledge wrote:
> On Tue, Aug 31, 2021 at 09:07:49AM -0500, David Wright wrote:
> > Bound or unbound, I couldn't make ESC 1 Ctrl-L do anything useful
> > while output is in progress (like a clean display of the typeahead
> > so far typed). I couldn't see a way to force echoing the line at
> > that time.
> 
> ??
> 
> So... you're talking about something *completely* different from the
> OP's requirement.

Yes, as Nicolas pointed out, I was conflating two different things.

> The OP, as far as I've been able to determine, has a *background* job
> that's writing characters to the terminal while they're typing into
> an interactive shell's prompt.  The shell is not running a foreground
> command.  There is no "type ahead" involved.
> 
> You're talking about running a *foreground* command, and then trying to
> type another command while this one is still running.  It's a totally
> different scenario.

Yes, I now see that. But as the movie looked very like a foreground
job (ping), I tried that out too. Just typing the ^R has an effect
very like what is seen there, and you can type ahead and rubout at
will, producing a neat, corrected command line. I can't recall my
having used ^R in that way before.

> The Ctrl-L stuff (in all its variations) is intended only for the OP's
> scenario.  They're typing at a shell prompt, and a bit of "noise"
> is thrown onto the screen, disrupting them.  It's a one-time event, and
> they'd just like to wipe away the noise so they can see what they're
> typing (and specifically so that backspace is handled "correctly").
> 
> It won't help in your scenario, at all.

No, I discovered that; just like you, I'd never looked into this stuff.
I'm afraid I just treat some of the posts here as brainteasers, giving
motivation for a bit of poking around.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#239581

Thanks for the insightful replies.

I think I am getting closer to a solution.

Wouldn't it be possible to bind the "redraw-current-line" to the delete 
(ASCII DEL), i.e. Alt 127??

And, just add that to my user's bash file?

I am thinking out loud, not sure this would work.

Also, yes. Zsh, I will look into use that.

On 8/30/21 5:39 PM, Greg Wooledge wrote:
> On Mon, Aug 30, 2021 at 05:05:49PM +0200, Nicolas George wrote:
>> With Zsh, there is the "redisplay" zle command, it does exactly that:
>> redraw the prompt and command without clearing the screen.
>>
>> I do not know if readline, used by bash, has the same feature available.
> Interesting.  I've never looked into this stuff before.
>
> There is a "redraw-current-line" action in readline, but bash doesn't
> bind any keys to it by default, neither in emacs nor vi mode.
>
> But before I could even test that, I came across this section in the
> man page:
>
>         clear-screen (C-l)
>                Clear the screen, then redraw the current line, leaving the cur‐
>                rent  line  at the top of the screen.  With an argument, refresh
>                the current line without clearing the screen.
>
> That bit about "With an argument" is totally new information for me.
> I'm a vi mode user, so I tried it as indicated: I typed some random
> stuff, and then I pressed ESC 0 Ctrl-L.  It didn't work (it cleared the
> whole screen).  So maybe an argument of 0 doesn't count... oh, right.
> That's because 0 is a movement command ("jump to first column").  Next I
> tried with a non-zero argument: ESC 1 Ctrl-L.  That worked.  It redrew
> the current prompt and command line, without clearing the screen.
>
> I also tested in emacs mode, but I'm not as proficient there.  Again,
> ESC 1 Ctrl-L seems to work.  And so does Alt-1 Ctrl-L, in my terminal
> (but Alt-1 may not work in all terminals, so be warned).
>
> For extra fun: Alt-0 Ctrl-L also works in emacs mode.  Apparently emacs
> can handle an argument of 0, because 0 isn't a movement command in
> emacs the way it is in vi.
>
> So, there's that.  And that will do what the OP wants, albeit not
> "automatically" the way they seemed to want.  They actually have to
> press the keys.
>
> I'll let others play around with binding redraw-current-line to some
> unused key combo.  I'm betting it does the same thing, once bound.
>

[toc] | [prev] | [next] | [standalone]

#239584

On Thu, Sep 02, 2021 at 05:44:33AM +0200, Thomas Anderson wrote:
> Thanks for the insightful replies.
> 
> I think I am getting closer to a solution.
> 
> Wouldn't it be possible to bind the "redraw-current-line" to the delete
> (ASCII DEL), i.e. Alt 127??
> 
> And, just add that to my user's bash file?

It would go in ~/.inputrc by preference.  But you *could* wrap it in "bind"
and put it in ~/.bashrc instead, if for some reason you wanted it to be
more complicated, or to be done only in bash and not in other programs
which use readline.

> I am thinking out loud, not sure this would work.

Me either.  Try It And See.

[toc] | [prev] | [standalone]

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

csiph-web