Cursor hanging after commands ending with $

[petoetje59]

When I end a command with a '&' its execution continues in the background after I logout.
There's a little annoyance I would like to get rid of with this.
Whenever I execute such a command, whether it from the prompt or from within a shell script, the cursor hangs alone instead of returning to the 'username@rpib pathname $ cursor' prompt, and I need to hit the return button before I can logout from the reappeared prompt.
How to get rid of this ?

[PeterO]

Rather than using vague phrases like "The cursor hangs in thin air" please tell us what actually happens because that means nothing to anyone but yourself....

PeterO

[petoetje59]

Rather than using vague phrases like "The cursor hangs in thin air" please tell us what actually happens because that means nothing to anyone but yourself....

PeterO

I rephrased it to make it clearer.

[petoetje59]

Maybe this makes it clearer.

Hanging cursor :


And as it should be, but only if I hit the return button :

[PeterO]

Pictures are good

The prompt has returned ... It is at the start of the second line in those pictures. The problem is that the application has written some text to stdout that has been printed and has moved the cursor away from the prompt text.

PeterO

[petoetje59]

The prompt has returned ... It is at the start of the second line in those pictures. The problem is that the application has written some text to stdout that has been printed and has moved the cursor away from the prompt text.

Has nothing to do with the application ; when I remove the trailing & it still writes to the stdout but returns to where it belongs without having to hit the return key, but when I then logout the application isn't running anymore obviously, making it useless.
The problem remains unsolved.

[Joe Schmoe]

There is no problem to be solved.

Try the following; hopefully, it will help you understand what is going on.

Code: Select all

pi@raspberrypi ~ $ (sleep 10;echo "Hello - I'm going to move your cursor.") &
[1] 354
pi@raspberrypi ~ $ Hello - I'm going to move your cursor.

[PeterO]

The prompt has returned ... It is at the start of the second line in those pictures. The problem is that the application has written some text to stdout that has been printed and has moved the cursor away from the prompt text.

Has nothing to do with the application ; when I remove the trailing & it still writes to the stdout but returns to where it belongs without having to hit the return key, but when I then logout the application isn't running anymore obviously, making it useless.
The problem remains unsolved.

The problem remain non-existent. You need to understand the consequences of putting a command into the background.

PeterO

[jamesh]

Perhaps redirect the apps output to NULL, you lose the output but the cursor will be in the correct place.

[petoetje59]

I thought of that, but this is no option as I have to know whether the attached device is running or not.
I'll get used to this Linux quirk.

[rpdom]

I thought of that, but this is no option as I have to know whether the attached device is running or not.
I'll get used to this Linux quirk.

I too fail to see a problem here. You type your command line (with an & on the end). The prompt returns. Then the command sends some output to the screen. You check it, type "exit" or press Ctrl-D. All done.

What is your issue with that?

I suppose you could send the output of the command to a file instead and cat that file to see if it started ok before logging out.

[Joe Schmoe]

I too fail to see a problem here.

This is one of those common cases where you're never going to understand what the OP is talking about [*] unless and until you completely understand, digest, and solve their actual underlying problem (which seems to have to do with some piece of hardware or something that apparently none of us have ever used). I suspect none of us really wants to get that far into it, not without first discussing consulting rates.

Note to mods: Please edit/change subject line title. It should end with "&", not "$".

[*] And I mean that literally. He might as well have posted in Swahili.

[jamesh]

Er, what?

I thought the OP was pretty clear after the next couple of posts with further explanation. This 'issue' is 'just how it is'. In Linux and I think other OS as well when you have stuff running in the background.

[Joe Schmoe]

Believe me, James, we're on the same page.

But you have to understand that the problem is *not* something about the cursor. That just indicates that he doesn't understand how background processes work in Unix. That's an omission easily cured. And I think we can all assume that that omission has been cured. But note that the OP is still not happy; that should tell you something.

The problem is that there is something fundamentally wrong with the way he is approaching his real problem. I.e., when one sets out to solve a problem using Unix, the objective is to figure out how to model your abstract problem with the Unix way of doing things. Once you become adept at this, it becomes easy to solve problems with Unix. But it is a hurdle that must be overcome, and one that each of us has overcome (or have yet to overcome).

[jbowler]

It's a bug, but it is present in every command line base interface I've used except one (Apollo Aegis); it's nothing to do with Linux.

The problem is that the input line is not independent of the output produced by any of the commands ("applications") run from the CLI (Command Line Interface). Some systems attempt partial fixes by buffering the output and attempting to redisplay the command line input, but only Aegis has a complete fix (it separated the input from the output, problem solved

Pity, best OS I ever used, of course it's dead now.

Meanwhile, unless you happen to have the best operating system ever written, if you run commands that output while you are trying to input just close your eyes; it works, I've done it.

John Bowler

[jojopi]

It is not a bug, but it is more a feature of historical serial text terminals than of Unix. The cursor naturally "hangs" wherever it is left. It would be (almost) technically possible for the kernel, or latterly readline, to re-output your prompt and current input buffer each time another process has written to the terminal. But that would be slow and potentially waste a lot of paper on your teletypewriter.

(Traditionally you can press Ctrl+R to have the kernel reprint your current line. With readline the closest equivalent is Ctrl+L, which also clears the screen.)

I have never used AEGIS. Did it manage to keep the shell input pad separate even when you logged in remotely with a text terminal?

You could implement a shell that reads its input in a dedicated part of the screen on Unix using curses and a pseudo-tty, but it will require a smart terminal. Or you could just use screen, which allows you to run the background job in a separate window or pane.

[jbowler]

It is not a bug, but it is more a feature of historical serial text terminals than of Unix.

The design of the UI is pretty clear; the shell outputs a prompt to show it is waiting for input and the terminal is set to echo characters so the user knows what she has typed. The default behavior of output from background jobs to /dev/tty breaks this UI, so it is a bug (a UI bug).

The cursor naturally "hangs" wherever it is left. It would be (almost) technically possible for the kernel, or latterly readline, to re-output your prompt and current input buffer each time another process has written to the terminal.

Try this example, which shows what happens when a background job *reads* from the terminal as opposed to writing:

$ read foo&

A naïve reader of the discussion would assume that the background read would consume the next line of input, but what actually happens is that the kernel detects a read from /dev/tty by a process with process group *not* the process group of the controlling terminal and doesn't allow it to happen. It ends up delivering SIGSTOP to the background process and SIGCHLD to the owning process, the shell. So:

$ (sleep 2; read foo) &
[1] 2396
$ ls

(don't hit return after the 'ls'). Now wait; notice that nothing happens. Specifically the shell does *not* output:

[1]+ Stopped ( sleep 2; read foo )

It only outputs it after the 'return' key is pressed and after the ls output has been produced. What is happening here is that the *shell* delays outputting the message for the SIGCHLD until immediate before it displays the prompt.

This can be done for output too. Take a look at the definitions of SIGTTIN and SIGTTOU (POSIX 1003.1 "Terminal Access Control" section 7.1.1.4). Note the default for SIGTTOU is the same as SIGTTIN and the shell does *not* change this. Now try this:

$ stty --all

Note the setting of '-tostop', so:

$ stty tostop
$ (sleep 1; echo -n foo) &

Problem fixed. I admit I hadn't realized that the fix was as easy as this; I thought Linux had done something bad, but really it is just that bash doesn't default to "stty tostop".

Entirely separately:

(Traditionally you can press Ctrl+R to have the kernel reprint your current line. With readline the closest equivalent is Ctrl+L, which also clears the screen.)

I guess that's another bug; rprnt is still set to ^R but for some reason (readline?) rprnt (whatever it is set to) results in "(reverse-is-search)`': I'm not familiar with what that is meant to do but it doesn't seem very useful (unlike a real reprint of the line, something I did many times when I actually used a teletype.)

I have never used AEGIS. Did it manage to keep the shell input pad separate even when you logged in remotely with a text terminal?

You could implement a shell that reads its input in a dedicated part of the screen on Unix using curses and a pseudo-tty, but it will require a smart terminal. Or you could just use screen, which allows you to run the background job in a separate window or pane.

That's basically what Aegis did. I don't know if it even supported rlogin (or an Aegis equivalent) from a separate box, and it was a single user machine; I've never seen one with a terminal connected. The operating system gave processes four standard streams - normal IO and error IO. I can't remember where the error streams were connected but the input pad allowed you to construct input and the lines were moved to the output pad when the shell consumed them. One of the nice things about that is no need to type blind when entering command lines for the future in the presence of a command spewing large amounts of output.

John Bowler

[jojopi]

The design of the UI is pretty clear; the shell outputs a prompt to show it is waiting for input and the terminal is set to echo characters so the user knows what she has typed. The default behavior of output from background jobs to /dev/tty breaks this UI, so it is a bug (a UI bug).

To keep the prompt and input together in all circumstances would either require an intelligent terminal (as with Apollo bitmap display) or the disallowing of output from background jobs. You appear to support the latter. That is not fixing a bug, it is removing a feature. You were allowed to run such jobs, but never forced to.

I do not even agree that tostop would be a better default than -tostop. It is very annoying to have a process stop just because it wanted to output a warning. Advanced users will change the setting, which is fine, but you would have hidden the feature so that new users may never realise it is available.

The idea that user interfaces must favour beginners over regular users promotes inefficiency.

(Traditionally you can press Ctrl+R to have the kernel reprint your current line. With readline the closest equivalent is Ctrl+L, which also clears the screen.)

I guess that's another bug; rprnt is still set to ^R but for some reason (readline?) rprnt (whatever it is set to) results in "(reverse-is-search)`': I'm not familiar with what that is meant to do but it doesn't seem very useful (unlike a real reprint of the line, something I did many times when I actually used a teletype.)

I agree that the difference is unfortunate, but readline uses non-canonical input and its default keystrokes are modelled after Emacs. C-r searches incrementally backwards through the shell history. That is very useful when you want to issue a command similar to one you typed previously.

[RSvedman]

the Reverse I -search is a result of bash capturing the ^R before readline gets it. In /bin/sh it works as old unix would. bash does many ugly things with terminal handling, It is barely at all useable on a really limited terminal, like my Tektronix 4006 (which is basically a glass TTY with fancy vectors). with bin/sh and the right stty magic it becomes very much like pdp11 unix I only wish linux hadn't thrown out xcase and prterase from the tty driver when we went POSIX 15 years ago...