cli: tweak how "is one file" predicate works

In effect, we switch from `path.is_file()` to `!path.is_dir()`. In cases
where process substitution is used, for example, the path can actually
have type "fifo" instead of "file." Even if it's a fifo, we want to
treat it as-if it were a file. The real key here is that we basically
always want to consider a lone argument as a file so long as we know it
isn't a directory. Because a directory is the only thing that will
causes us to (potentially) search more than one thing.

Fixes #2736

crates/cli/src/lib.rs

@@ -182,6 +182,7 @@ pub fn is_readable_stdin() -> bool {
         let file = File::from(fd);
         let Ok(md) = file.metadata() else { return false };
         let ft = md.file_type();
+        dbg!(&ft);
         ft.is_file() || ft.is_fifo() || ft.is_socket()
     }
 

crates/core/flags/hiargs.rs

@@ -1080,9 +1080,18 @@ impl Paths {
             }
             paths.push(path);
         }
+        log::debug!("number of paths given to search: {}", paths.len());
         if !paths.is_empty() {
             let is_one_file = paths.len() == 1
-                && (paths[0] == Path::new("-") || paths[0].is_file());
+                // Note that we specifically use `!paths[0].is_dir()` here
+                // instead of `paths[0].is_file()`. Namely, the latter can
+                // return `false` even when the path is something resembling
+                // a file. So instead, we just consider the path a file as
+                // long as we know it isn't a directory.
+                //
+                // See: https://github.com/BurntSushi/ripgrep/issues/2736
+                && (paths[0] == Path::new("-") || !paths[0].is_dir());
+            log::debug!("is_one_file? {is_one_file:?}");
             return Ok(Paths { paths, has_implicit_path: false, is_one_file });
         }
         // N.B. is_readable_stdin is a heuristic! Part of the issue is that a