title: bash/sh/busybox pass stdin to child process
body: <p>I want to pipe both script and data over stdin to a shell and its child process. Basically, I'm starting a shell and sending a string like <code>"exec wc -c;\n&lt;data&gt;"</code> to the shell over stdin.</p>
  
  <p>I'm looking to start a sub-process and pass data to said sub-process.
  Using <code>exec</code> I fully expect <code>wc -c</code> to replace my shell and count the number of bytes sent over stdin.</p>
  
  <p>Examples:</p>
  
  <pre><code>echo -ne 'exec wc -c;\nabc' | dash
  echo -ne 'exec wc -c;\nabc' | bash
  echo -ne 'exec wc -c;\nabc' | bash --posix
  echo -ne 'exec wc -c;\nabc' | busybox sh
  </code></pre>
  
  <p>It seems to work consistently with bash, but not with dash or <code>busybox sh</code>. They both seem to fail intermittently. If I sleep for 100ms before sending <code>&lt;data&gt;</code> over stdin, then it works. But sleeping is not a reliable fix.</p>
  
  <p>In practice I'm sending a non-trivial amount of data, so I don't want to encode it or somehow store it in memory. Any ideas?</p>
  
  <p>Note: I'm sure there are many use cases where one could work around this. But I'm looking to find out why this doesn't work consistently. And/or what shell magic I could do to make it work reliably, preferably across platforms :)</p>
  
  <p><strong>Update:</strong> to clarify I have a remote system where I run <code>sh</code> and expose stdin/stdout/stderr, I would like to prove that such a setup can do anything. By sending <code>"exec cat - &gt; /myfile;\n&lt;data&gt;"</code> one could imagine I could stream in <code>/myfile</code> so that it contains <code>&lt;data&gt;</code>. Again imagine <code>&lt;data&gt;</code> being large.</p>
  
  <p>Essentially, I'm looking to prove that a system can be controlled using just stdin for <code>sh</code>. Something else very simple instead of <code>sh</code> that is readily available across platforms as a static binary might also work.</p>
  
  <p>I'll admit this might be totally crazy and that I should employ a protocol like SSH or something, but then I would likely have to implement that.</p>