Background Job (&) - ignore '[1]+ Done'

AntiRix

New Member
Joined
Mar 13, 2019
Messages
10
Reaction score
2
Credits
0
Hi,

Whenever I run a background process with & at the end, when I do anything on the terminal, I get the usual '[1]+ Done' output. Is there any way to just run a command in the background and ignore/suppress this? I just want to fire and forget.
 


G'day @AntiRix and welcome to linux.org :)

Might help a little if you told us what Distro you are using, there are only hundreds :D

I'm moving this to Command Line, where you might getter a better response.

Cheers

Chris Turner
wizardfromoz
 
I think the best bet would be to turn off the shell-option for monitoring job-control.

You can see the shell-options that are set using the command:
Code:
set -o

if monitor is set to "on", you can turn it off by using the command:
Code:
shopt -u -o monitor
The -u flag means to unset an option.
The -o flag means that we're dealing with one of the options from the set of shell options in the "set -o" list.
And monitor is the name of the option we're unsetting.

When the monitor option is unset, you will still get the PID for the new job/process printed in the current terminal when the job is started. You just won't get the:
"[1]+ Done nameofscript" notification text popping up on screen when the job has finished.

So if that works satisfactorily for you and you want the monitor option to always be turned off, you can put that previous line into your .bashrc.

And to re-enable the monitor option:
Code:
shopt -s -o monitor
In this case the -s flag is used to SET the monitor option.

The monitor option can also be set using the set command. But this can be a little confusing because:
Code:
set +m
will disable the monitor option.
Code:
set -m
will enable the monitor option.
So + disables/unsets and - enables/sets an option... Which seems counter-intuitive!

But I'm certain I've used versions of bash where the set command uses + to set and - to unset.
Either way - using shopt is more intuitive, more consistent and less confusing!

Anyway - getting back on-topic - turning off the shells monitor mode is the option that I would recommend

But as always with UNIX, there is always more than one way to skin a cat.

An alternative, but personally not recommended method is to simply enclose the command that starts the script in the background, in brackets. This will start the job in a sub-shell.
e.g.
Code:
( somescript & )

That will not show ANY job information at all, because the job becomes the responsibility of the sub-shell, not the current shell. So regardless of whether the monitor option is set or not - you will see NO information about the PID of the background process, and no notification that the job has finished. Because only the sub-shell will be sent that information.

But you need to be careful doing this.
If this is a script that will run perpetually and you've started it in the background in a sub-shell. In order to halt it, you would need to use something like pstree or top to track down the PID for the script. And then you would manually have to use kill to send the SIGTERM signal to the appropriate PID.


Going on a slight tangent - another thing to take note of is, when running a script or process in the background - it may still periodically write text, or error messages/warnings to the current shell.

So regardless of whether or not the monitor mode is enabled, or whether or not you started it in a sub-shell. If you want to start a process in the background and suppress ALL output from the script - you will need to redirect all of it's output elsewhere.

So you could redirect all output from the script to a file:
Code:
somescript 2&> /path/to/somefile &

This would start a script in the background and redirect all output to a file at /path/to/somefile. Allowing you to monitor/record the output/status of the script.

Or you could suppress all textual output entirely:
Code:
somescript 2&> /dev/null &
That starts the script in the background and sends all of the scripts output to the bit bucket!

So WRT to limiting the job-related output from a background script/process - there are a few options.

Personally - I'd consider changing the "monitor" shell option to prevent the end of job notifications from popping up, rather than starting a background job in a sub-shell.
But if you want to suppress all other output from a background job - redirecting its output to a file, or the bit-bucket (/dev/null) is a must!
 
Thanks very much for your answer. As I don't need any information from the job at all, but rather just want to run the script and forget about it, I've chosen to use the subshell method which is working perfectly.
 

Members online


Latest posts

Top