title: GNU parallel stderr with --files or sensible --results tree
body: <p>I've recently discovered GNU parallel, and it is already incredibly useful, but I cannot figure out how to get all my output into any kind of usable structure.  Here are my issues:</p>
  
  <ul>
  <li>The commands I'm running take several hours or days and produce reams of output to both stdout and often stderr, so I want to redirect all of the output</li>
  <li>Sounds like --files should work, right?  But unless I'm crazy, I only get the stdout from those files. Is stderr just dumped with this option???</li>
  <li>OK, how about --results? This is maybe a bit better, but has two problems:
  
  <ol>
  <li>The commands are long: /path/to/command -a --blah /path/to/data /another/path {} . This makes a ridiculous directory name and the spaces make trying to do anything a pain (e.g. 'cat `find . -name stdout`'  won't work)</li>
  <li>stdout and stderr go to separate files, which is usually ok, but in this case error messages are sometimes produced in the  middle of other output and trying to piece things back together is a pain. </li>
  </ol></li>
  </ul>
  
  <p>So: is there any way <em>within parallel, i.e. without having to modify my command</em> to either get the stderr when using --files or force --results to use sensible directory names? </p>
  
  <p>EDIT:
  In response to comment, I've tried:</p>
  
  <pre><code>find controlFiles/ -name "*.txt" | parallel --files --tmpdir logs --tagstr {/.} -j15 --joblog logs/joblog --eta /path/to/command --opt --opt2 /path/to/data /path/to/output {} &gt; logs/logfiles.txt
  </code></pre>
  
  <p>and</p>
  
  <pre><code>find controlFiles/ -name "*.txt" | parallel --files --results logs --tagstr {/.} -j15 --joblog logs/joblog --eta /path/to/command --opt --opt2 /path/to/data /path/to/output {} &gt; logs/logfiles.txt
  </code></pre>
  
  <p>where the former loses stderr and the latter produces unusable directory names</p>
  
  <p>EDIT2:
  After a bunch more testing, it seems I somehow got things into a <em>really</em> weird state. The directory structure from --results is supposed to be named after the arguments, but somehow mine was using the entire command.  When I tried removing the existing logs directory and starting fresh with what I thought was the same command, I got the expected behavior.  Still not ideal, but I can certainly live with it. </p>