in reply to Re: How to know if a perl script is put in the background
in thread How to know if a perl script is put in the background

BTW, I'm a bit surprised that your backgrounded script's stdout/stderr is going to the terminal. Normally, it wouldn't, if you start a script from the shell using & without redirecting those handles. The shell would stop the backgrounded script in case it's writing anything to stdout or stderr....
It's my experience that backgrounded jobs still write STDERR to the screen/terminal under every shell/OS combination. For example, 
tar cvf /dev/null /usr/local &

[download]
fills my OS X terminal, as it does on Solaris and OpenBSD.

Replies are listed 'Best First'.
Re^3: How to know if a perl script is put in the background [OT]
by almut (Canon) on Nov 18, 2008 at 18:00 UTC
    ... fills my OS X terminal, as it does on Solaris and OpenBSD.

    Not here... (Linux / bash with default settings) — But I suppose this discussion is getting off-topic with respect to the original question.

    Update: Here's the respective paragraph from bash's man page:

    JOB CONTROL
    (...) Only foreground processes are allowed to read from or write to the terminal. Background processes which attempt to read from (write to) the terminal are sent a SIGTTIN (SIGTTOU) signal by the terminal driver, which, unless caught, suspends the process.

[reply]
[d/l]

      So this really is controlled by stty, specifically the [-]tostop option. On my system (which doesn't stop background jobs that try to output), it's off ("-tostop"). I'm guessing that on your system it's on. Try: 

      stty -a

      [download]

      ...and see what it is.

[reply]
[d/l]
[select]

        ... that's exactly it — Thanks for clearing this up.

[reply]

In Section Seekers of Perl Wisdom