On Windows, always consider stdin to be a tty.

This means that `rg pat < file` won't do the expected thing and search
`fil`. Instead, it will recursively search the current directory for `pat`.
This isn't ideal, but is better than the previous behavior, which was to
wait for stdin when running `rg pat`, given the appearance of hanging
forever. The former is an important use case, but the latter is the
*central* use case of ripgrep, so we should make that work.

`rg` can still be used to search stdin on Windows, it just needs to be
done explicitly. e.g., `rg pat - < file` will search for `pat` in `file`.

Fixes #19

src/atty.rs

@@ -27,30 +27,35 @@ pub fn stdin_is_readable() -> bool {
     true
 }
 
+/// Returns true if there is a tty on stdin.
 #[cfg(unix)]
 pub fn on_stdin() -> bool {
     use libc;
     0 < unsafe { libc::isatty(libc::STDIN_FILENO) }
 }
 
+/// Returns true if there is a tty on stdout.
 #[cfg(unix)]
 pub fn on_stdout() -> bool {
     use libc;
     0 < unsafe { libc::isatty(libc::STDOUT_FILENO) }
 }
 
+/// Returns true if there is a tty on stdin.
 #[cfg(windows)]
 pub fn on_stdin() -> bool {
-    use kernel32;
+    // BUG: https://github.com/BurntSushi/ripgrep/issues/19
-    use winapi;
+    // It's not clear to me how to determine whether there is a tty on stdin.
-
+    // Checking GetConsoleMode(GetStdHandle(stdin)) != 0 appears to report
-    unsafe {
+    // that stdin is a pipe, even if it's not in a cygwin terminal, for
-        let fd = winapi::winbase::STD_INPUT_HANDLE;
+    // example.
-        let mut out = 0;
+    //
-        kernel32::GetConsoleMode(kernel32::GetStdHandle(fd), &mut out) != 0
+    // To fix this, we just assume there is always a tty on stdin. If Windows
-    }
+    // users need to search stdin, they'll have to pass -. Ug.
+    true
 }
 
+/// Returns true if there is a tty on stdout.
 #[cfg(windows)]
 pub fn on_stdout() -> bool {
     use kernel32;