【发布时间】：2019-05-25 02:47:41
【问题描述】：
我维护一个生成二进制数据的命令行实用程序。数据可以在请求时重定向到stdout。
这在 stdout 被重定向到管道或文件时有效，
但当stdout 是控制台时，情况会更糟，因为它会使控制台产生垃圾。
为了保护用户免受此类错误的影响，程序必须检测stdout是否是控制台，并在是时退出。
现在，这已经不是什么新鲜事了，快速浏览一下 Internet 就会发现多种解决方案。主要缺点是没有“通用”方法，Visual Studio 需要自己的风格。
我用于 Visual 的控制台检测器有一个缺陷：它没有检测到 stdout 是一个控制台当该控制台由 mingw 提供时，我相信这意味着是mintty。
这里是相关的代码部分：
#if defined(WIN32) || defined(_WIN32)
# include <io.h> /* _isatty */
# include <windows.h> /* DeviceIoControl, HANDLE, FSCTL_SET_SPARSE */
# include <stdio.h> /* FILE */
static __inline int IS_CONSOLE(FILE* stdStream) {
DWORD dummy;
return _isatty(_fileno(stdStream)) &&
GetConsoleMode((HANDLE)_get_osfhandle(_fileno(stdStream)), &dummy);
}
#endif
请注意，控制台检测器可以与内置的 Windows 控制台 (conhost.exe) 配合使用。当二进制文件由mingw64 编译时，它也可以正常工作。所以问题主要是“用Visual编译+控制台是mintty”。
我一直在寻找一些潜在的备份解决方案，并发现了多种用于 Visual 的控制台检测器变体，它们使用不同的逻辑。但是它们都不会将mintty 识别为控制台，它们都失败了。
我想知道mintty 是否有问题，但我预计如果是这样，更多的应用程序会受到影响。然而，通过互联网搜索此类问题的投诉相对较少，并且没有解决方案。
- 这是一个已知问题吗？
- 有已知的解决方案吗？
【问题讨论】：
-
_isatty查找字符文件，其中包括控制台、COM 端口和 NUL。检测控制台需要额外的调用，例如GetConsoleMode，因此代码中的_isatty调用是多余的。也就是说，如果句柄没有读取访问权限，GetConsoleMode将失败（例如，“con”只能打开用于读取或写入访问，但不能同时打开，而“conin$”和“conout$”可以打开读写访问），所以这并不完全可靠。
标签： c windows visual-studio console mintty