1

Current situation: When an application/script has been started as a background process from a terminal and is providing output to the console (i.e. to STDOUT, thus no output redirection), when I type something in the terminal, and the running process outputs something to the terminal as well at the same moment, the process' output gets "appended" to whatever I was typing at that moment and thus visually the input and output are garbled together.

Desired result: I wonder if it's possible to have the "so far typed" input jump on the next line whenever the background process displays its output on the terminal (i.e. have the input text always displayed on the last line automatically, separately from the ongoing output).

Basically I'm looking for a way to achieve the same results as the "logging synchronous" command allows in IOS on Cisco devices (better exemplified here) which, once enabled, takes whatever you typed so far and puts it on a new line (always the last one) whenever there is any "system-related" output displayed during your typing.

Additional stuff: I know that even though visually the input and output text are mixed together, if I continue typing my command all the way and press Enter it will execute fine, it's just rather hard to figure out exactly what you typed when the output catches you unawares.

I'm on Debian Jessie with Gnome so I'm using Bash with the default Gnome Terminal but the same behavior exhibits when using a virtual console (e.g after CTRL+ALT+F1).

I'm not sure if there is some very easy, well-known and obvious way to do it that I'm missing but I've been searching for the better part of last hour to no avail, so I apologize if this is a no-brainer.

Or is this feature (if it exists at all) dependent on the terminal application used?

Thanks for any input.

1

One option is to redirect the STDOUT and STDERR to a file when backgrounding the job.

ls &> job.txt &
[1] 13160
[1]+  Done                    ls &>job.txt

Then to check for running jobs

jobs
[1]+  Running                 yes &>/dev/null &

You can also foreground them and interrupt or peek into the job.txt to check on their status (assuming that they do not buffer output).

fg 1

When jobs are completed you should get notified in the terminal after your next command is completed (in bash this does not interrupt your command typing).

I assume there is a reason you are not doing this already. I am not sure if you can background with Crtl-z and get the i/o redirection though.

  • I thought of that already, but in these particular cases let's say the output is not important enough to keep in a file but still I'd like to see it as it gives constant info on certain operating parameters (e.g. a crypto-miner's output). Also since the app is long-term running and already has it's own logging function (for meaningful events), I'd like to avoid having some additional file bloat on the disk and having to set up logrotate for it just to keep it in check. But I agree in some cases this may be a useful workaround. – atux Aug 31 '17 at 7:36
  • 1
    Oh, then in this case use tmux or screen and just check in on the application output from time to time, or ignore it all together. Either way you will avoid the output mangling and still have auditability. – datUser Aug 31 '17 at 11:53
  • Yes indeed, I started looking into screen today for that as it will help with checking remotely on the output anyway. I'm surprised though that in about 40 years of *nix, no crafty dev sank its teeth into this little thing. :) Thanks though. – atux Aug 31 '17 at 20:02
1

There's no automatic "magic" way I'm aware of.

If your terminal is in cooked mode (as it is the case when running simple apps that are neither fullscreen nor have readline support or alike, such as cat for example), you can press the terminal discipline's "reprint" character which is Ctrl+R for me, see rprnt in stty's manual page and stty -a's output. This will jump to the next line and reprint the text you're typing.

If you're running fullscreen or readline-aware apps, they probably all have their own ways (usually Ctrl+R or Ctrl+L) of repainting the screen or the current line.

  • Well, I've read somewhere in some Bash manual about this, in the past, and then completely forgot it. Thanks! I guess it comes the closest to what I'm looking for. – atux Aug 31 '17 at 8:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.