Re: screen, detached, stdout

[Ben Love]

* Nico Schlömer wrote on [2011-02-09 19:07:22 +0100]:
> Hi all,
> 
> I would like to start a series of jobs in the background and log their
> stdout in specific files. The idea is to use screen for this, and I
> went ahead and typed
> 
> $ screen -d -m /path/to/my/exec
> 
> which puts the job nicely in the background. Let's log stdout:
> 
> $ screen -d -m /path/to/my/exec | tee output.log
> 
> Ah, that doesn't work as the it tees the output of `screen` to the
> file. Hmm.. How about
> 
> $ screen -d -m `/path/to/my/exec | tee output.log`
> 
> Now, it directs the output alright, but the session isn't detached anymore.
> 
> I don't quite understand why this happens, so if you guys have a clue
> that'd be great. I'm also looking for a solution to the problem of
> course.

Case 1: Redirects the stdout of screen to tee.  The stdout of screen is
not what you think because its designed to be a terminal multiplexor.

Case 2: Executes the entire backticked expression in a subshell and
passes the stdout of that as the argument to screen.

You didn't try screen -d -m "/path/to/my/exec | tee output", but that
doesn't work either because the entire expression is passed to screen as
one argument, and then screen cannot find an executable with that name.

You might also try escaping the pipe from the current shell, like this:

$ screen -d -m /path/to/my/exec "|" tee output.log

But that doesn't work because the executable itself would get the pipe
as an argument.

This does work:

$ screen -d -m sh -c "/path/to/my/exec | tee output.log"

This works because you tell screen to spawn a shell, and then your argument is
simply the command for the shell.  The shell then correctly parses the
command and does what you intend.

Of course, the other responses about -L are probably simpler to use
anyway.

Ben

-- 
Ben Love
http://www.kylimar.com/

signature.asc
Description: Digital signature