Methods to do this:

This is not the most efficient way to go about doing this, but it is a working method. Here is a supposed file structure:

backgroundRun.sh|tmp||_ outFile.txt

Here is how backgroundRun.sh would look:

backgroundRun.sh:

#backgroundRun.shmyCommand > tmp/outFile.txt 2>&1 &

Code Output:

./backgroundRun.shuser@domain~$

How It Works:

The basic concept is that all the output from myCommand(Look at backgroundRun.sh) is stored in tmp/outFile.txt, while running in the background.

P.S: outFile.txt will be an empty file (placeholder).

This is an efficient method. The problem with this one is that the output will get echoed onto the screen(If you have any). Just a simple command like this:

(myCommand &) #Hit enter:user@domain~$

How It Works:This code is about simplicity; All it does is the the command(in the background) in a subshell.

This is another efficient method. Here, you only need one file: backgroundRun.sh. Here is the code:

backgroundRun.sh:

myCommand & > /dev/null 2>&1

Code Output:

./backgroundRun.shuser@domain~$

How It Works:

It runs the command, outputting it to /dev/null. If that doesn't work it gives an error(2>&1).

P.S: This code will only work on *nix/POSIX systems, as /dev/null not present in other OS(s)

Not quite the whole solution, but more lines than a comment would allow...

The following worked to reduce the number of blank lines (tested with bash on Raspbian/Debian, just with vi). The key step is to start a nested bash in interactive mode, but hiding the stderr output:

bash -i 2>/dev/null

This will suppress the job control messages in a moment, but it also hides the interactive shell, so you need to type confidently, e.g. :

vi firstfile

Then when you background vi (e.g. CtrlZ ), the usual [1]+ Stopped vi firstfile message is suppressed as predicted. This is the total output so far:

~ $ bash -i 2>/dev/null

When fg is typed (again typing blind), this returns you to the vi session. However the next time you background vi, this reveals a further line of output confirming what was foregrounded earlier:

~ $ bash -i 2>/dev/nullvi firstfile

It is an improvement on most of the undesired lines, but each subsequent fg will tip out one more line of feedback. This can be 'worked around' though by typing this instead:

fg>a

- a is a just dummy file, with a short name to save typing fg>/dev/null.

This was enough to stop the job control output completely. A couple of shell scripts would help, but it feels like it could be further refined ... I look forward to seeing more answers.

If you use VIM, why should you suspend vim? All you need is a sequence:

% vim:! youShellCommands:e youFilename.... over and over again

This solves the problem more elegantly and without disabling diagnostic messages.

OR

In bash, enter the following function:

function ff() { fg 2> /dev/null 1>&2 ; }

and use ff instead of fg.From now on the session will look like this:

% vi[1] + Stopped vi% ff% ff% ff

Do not turn off diagnostic messages globally for the entire bash because then work in the console would be extremely difficult. How would you know if the commands performed correctly or failed.

EDIT:A small note. The SIGTSTP kernel is responsible for sending the process into the background. Usually run CTRL + Z (or sometimes CTRL + Y) It has the number 20. You can call it programmatically eg by kill -20 PIDNumberTo get rid of feedback, you would have to overwrite the SIGTSTP signal service. Worth it? If Yes:in C write it like this:

#include <stdio.h> #include <signal.h> void signalHandler(int sig_num) {     // here is a new code for handling the signal    // signal(SIGTSTP, ...etc.     } signal(SIGTSTP, signalHandler);