wtm@bunker.UUCP (Bill McGarry) (02/21/86)
In article <1848> Marc Ries (ries@trwba) wants to run a background
job from his .profile. He does NOT want the PID to be printed but
still wants the standard output of the background job to go to the
terminal.
Well, there may be other ways to do this but one way would be to
have a separate shell script call the background job. For example,
call this shell script "run_back". This script would just contain:
myprog&
Then in your .profile, just run "run_back" (NOTE: Do NOT run this in
background).
Results?: "run_back" returns immediately. No PID # is printed, yet
"myprog" output will go to the terminal.
Bill McGarry
{decvax, ittatc, philabs}!bunker!wtmlowe@gondor.UUCP (Tom Lowe) (03/10/86)
In article <1093@bunker.UUCP> wtm@bunker.UUCP (Bill McGarry) writes: > >In article <1848> Marc Ries (ries@trwba) wants to run a background >job from his .profile. He does NOT want the PID to be printed but >still wants the standard output of the background job to go to the >terminal. > >Well, there may be other ways to do this but one way would be to >have a separate shell script call the background job. For example, >call this shell script "run_back". This script would just contain: > > myprog& > >Then in your .profile, just run "run_back" (NOTE: Do NOT run this in >background). > >Results?: "run_back" returns immediately. No PID # is printed, yet >"myprog" output will go to the terminal. > > Bill McGarry > {decvax, ittatc, philabs}!bunker!wtm Another methid I do believe will work is the following: (myprog >& /dev/tty & ) >& /dev/null the (myprog >& /dev/tty & ) will run the job in the background and send all output (including std error) to the current tty and the rest of the line will output what's left (i.e. the PID #) to /dev/null never to be seen again. -- Tom Lowe uucp: {allegra, ihnp4}!psuvax1!gondor!lowe Bitnet: LOWE@PSUVAXG.BITNET