On Tue, 2009-10-27 at 08:38 -0500, vitamin wrote:
> Martin Gregorie wrote:
> > On Mon, 2009-10-26 at 18:03 -0500, flyfisherman wrote:
> >
> > > "c:\program files\sierra\fear\fear.exe" &> log.txt
> > >
> > Here's the problem -----------------------^
> > The '&' shouldn't be there.
>
> Everything is fine there, if he is using bash (default in many/all distros).
>
So am I, bash 3.2.39. See below for its handling of this idiom.
> Martin Gregorie wrote:
> > wine "c:\program files\sierra\fear\fear.exe" 2>&1 >logfile.txt
>
> This _is_ wrong. stderr to stdout redirection should go after stdout to file redirection eg:
>
OK, interesting that "app 2>&1 | less" does what's expected but
redirection in place of the pipe symbol doesn't. I live and learn.
However, the "app & >x.txt " command definitely doesn't do what was
expected. In the interest of providing an SSCE I wrote a test program
that sends recognisable output to stdout and stderr:
================ se.c ================
#include <stdio.h>
int main(int argc, char **argv)
{
fprintf(stdout, "stdout\n");
fprintf(stderr, "stderr\n");
return 0;
}
======================================
When run as the WINE documentation suggested it gives this result:
$ se & >x.txt
stdout
stderr
[1] 16673
[1]+ Done se
$ cat x.txt
$
Which is not what is wanted since stdout is not redirected to x.txt.
x.txt is empty, which is exactly what I'd expect. Shell scripting
tutorials often use "> file" as a way to create an empty file to act as
a script control flag. OTOH this works as expected:
$ se >x.txt
stderr
$ cat x.txt
stdout
$
and so does this:
$ se >x.txt &
stderr
[1] 16695
[1]+ Done se > x.txt
$ cat x.txt
stdout
$
Martin
