Silently start task in background

task-spooler might help you.

As in freshmeat.net:

task spooler is a Unix batch system where the tasks spooled run one after the other. The amount of jobs to run at once can be set at any time. Each user in each system has his own job queue. The tasks are run in the correct context (that of enqueue) from any shell/process, and its output/results can be easily watched. It is very useful when you know that your commands depend on a lot of RAM, a lot of disk use, give a lot of output, or for whatever reason it's better not to run them all at the same time, while you want to keep your resources busy for maximum benfit. Its interface allows using it easily in scripts.

Task-spooler is available in Debian, Ubuntu and other distros.

It lets you have a queue of tasks to run, and access their outputs just at wish.

For example:

$ tsp sleep 5
0 
$ tsp sleep 5 
1
$ tsp
ID   State      Output               E-Level  Times(r/u/s)   Command [run=1/1]
2    running    /tmp/ts-out.ZWn6Le                           sleep 5
1    finished   /tmp/ts-out.Fhlcle   0        5.00/0.00/0.01 sleep 5

If you run a lot of jobs in background, it will definitely help you.

You can either run them sequentially or in a preset amount of slots. You can also establish dependencies among the tasks (run task1 only if task0 completed successfully).

Here's how to do it in both {ba,z}sh.

Using a function helps not needing to save and restore the state of zsh's monitor variable by use of setopt local_options.

# Run the command given by "$@" in the background
silent_background() {
  if [[ -n $ZSH_VERSION ]]; then  # zsh:  https://superuser.com/a/1285272/365890
    setopt local_options no_notify no_monitor
    "$@" &
  elif [[ -n $BASH_VERSION ]]; then  # bash: https://stackoverflow.com/a/27340076/5353461
    { 2>&3 "$@"& } 3>&2 2>/dev/null
  else  # Unknownness - just background it
    "$@" &
  fi
}

Using this as follows:

trap 'echo child done' CHLD
silent_background sleep 1

Will produce the expected child done message.

The redirection of the command output seems to be irrelevant because the notification is send by the shell when a job is started asynchronously. More precisely, it is a shell feature (fonctionality) related to job control.

Here, a quote that comes from the "Bash Reference Manual", chapter "Job Control", section one.

The shell associates a JOB with each pipeline. It keeps a table of currently executing jobs, which may be listed with the jobs command. When Bash starts a job asynchronously, it prints a line that looks like:

[1] 25647

indicating that this job is job number 1 and that the process ID of the last process in the pipeline associated with this job is 25647. All of the processes in a single pipeline are members of the same job. Bash uses the JOB abstraction as the basis for job control.

Note that a shell script does not display this notification.

$ cat test
#!/bin/bash

true & echo true
$ ./test
true

In facts

Zsh

The Zsh documentation provides similar indications about these notifications, see man 1 zshmisc, section "JOBS". These notifications are not displayed when job control is disabled.

MONITOR (-m, ksh: -m)

    Allow job control. Set by default in interactive shell.

zsh_prompt % setopt no_monitor
zsh_prompt % true & echo true
true
zsh_prompt %
zsh_prompt % 

Bash

It seems that Bash always displays e.g. [1] 25647. The "final notification" e.g. [1]+ Done true is not displayed when job control is disabled.

bash_prompt $ true & echo true
[1] 25647
true
bash_prompt $ 
[1]+  Done                    true

Job control disabled

bash_prompt $ set +m       # disable job control
bash_prompt $ true & echo true
[1] 25685
bash_prompt $
bash_prompt $

Conclusion

I do not know if disable job control to hide the notifications is a good thing?

Resources

• man 1 zshmisc, section JOBS.
• Zsh, MONITOR: man 1 zshoptions.
• Bash Reference Manual - Job Control
• Bash Reference Manual - The Set Builtin