Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site gondor.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!petrus!bellcore!decvax!ittatc!dcdwest!sdcsvax!sdcrdcf!burdvax!psuvax1!gondor!lowe
From: lowe@gondor.UUCP (Tom Lowe)
Newsgroups: net.unix-wizards
Subject: Re: Eliminating PID # from background jobs
Message-ID: <2023@gondor.UUCP>
Date: Sun, 9-Mar-86 19:55:20 EST
Article-I.D.: gondor.2023
Posted: Sun Mar  9 19:55:20 1986
Date-Received: Wed, 12-Mar-86 03:45:20 EST
References: <1093@bunker.UUCP>
Reply-To: lowe@gondor.UUCP (Tom Lowe)
Organization: Pennsylvania State Univ.
Lines: 36

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