title: Is there any method to detect whether STDIN has been redirected within VBscript?
body: <p>I'm trying to process/filter input within a VBscript, but <em>only</em> if the input has been piped into the script. I don't want the script processing user/keyboard input. I'd like to code this as something like this:</p>
  
  <pre class="lang-vb prettyprint-override"><code>stdin_is_tty = ...
  if not stdin_is_tty then
     ...
     input = WScript.StdIn.ReadAll
  end if
  </code></pre>
  
  <p>Otherwise, the script will hang, waiting on user input when it executes <code>WScript.StdIn.ReadAll</code> (or even earlier if I test the stream with <code>WScript.StdIn.AtEndOfStream</code>).</p>
  
  <p>In C#, I'd use:</p>
  
  <pre class="lang-cs prettyprint-override"><code>stdin_is_tty = not System.Console.IsInputRedirected // NET 4.5+
  </code></pre>
  
  <p>The <a href="https://stackoverflow.com/a/3453272/43774">accepted answer</a> for <a href="https://stackoverflow.com/questions/3453220/how-to-detect-if-console-in-stdin-has-been-redirected">Q: "How to detect if Console.In (stdin) has been redirected?"</a> shows how to build that result using Win32 calls via P/Invoke, for versions of NET earlier than NET 4.5. But I don't know of any way to translate that method into VBscript.</p>
  
  <p>I've constructed a clumsy, partial solution using <code>SendKeys</code> to send an end-of-stream sequence into the scripts' keyboard buffer. But the solution leaves keys in the buffer if STDIN <em>is</em> redirected, which I can't clean up unless I know that STDIN was redirected... so, same problem.</p>
  
  <p>I'd prefer to keep the script in one packaged piece, so I'd rather avoid a separate wrapping script or anything not available on a generic Windows 7+ installation.</p>
  
  <p>Any brilliant ideas or workarounds?</p>
  
  <p><strong>EDIT:</strong> added copy of initial solution</p>
  
  <p>I've added a copy of my improved initial solution here (admittedly, a "hack"), which now cleans up after itself but still has several negatives:</p>
  
  <pre class="lang-vb prettyprint-override"><code>input = ""
  stdin_is_tty = False
  test_string_length = 5 ' arbitrary N (coder determined to minimize collision with possible inputs)
  sendkey_string = ""
  test_string = ""
  for i = 1 to test_string_size
     sendkey_string = sendkey_string &amp; "{TAB}"
     test_string = test_string &amp; CHR(9)
  next
  sendkey_string = sendkey_string &amp; "{ENTER}"
  wsh.sendkeys sendkey_string ' send keyboard string signal to self
  set stdin = WScript.StdIn
  do while not stdin.AtEndOfStream
     input = input &amp; stdin.ReadLine
     if input = test_string then
         stdin_is_tty = True
     else
         input = input &amp; stdin.ReadAll
     end if
     exit do
  loop
  stdin.Close
  if not stdin_is_tty then
     set stdin = fso.OpenTextFile( "CON:", 1 )
     text = stdin.ReadLine
     stdin.Close
  end if
  </code></pre>
  
  <p>This solution suffers from the three problems:</p>
  
  <ol>
  <li><p>leaving a visible trace at the command line (though now, just a single blank line which is low visibility)</p></li>
  <li><p>possible collision of the test string (a set series of N [coder determined] TABs followed by a NEWLINE) with the first line of any redirected input causing a false positive redirection determination. Since the number of TABs can be modified, this possibility can be made arbitrarily low by the coder.</p></li>
  <li><p>a race condition that if another window receives focus before the <code>SendKeys</code> portion is executed, the wrong window will receive the code string, leading to a false negative redirection determination. My estimate is that the possibility of this circumstance occurring is very low.</p></li>
  </ol>