Skip to content

TSCBasic: use the "portable" names for terminalType #108

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Aug 12, 2020

Conversation

compnerd
Copy link
Member

This adds the Windows path which uses the _isatty and _fileno for
the conversion. This is likely still insufficiently to properly detect
the stream. _isatty is okay in the short term, but it is better to
use GetFileType on the HANDLE associated with the file descriptor.
This requires better auditing to ensure that the handle is convertible
to the underlying Windows handle.

This adds the Windows path which uses the `_isatty` and `_fileno` for
the conversion.  This is likely still insufficiently to properly detect
the stream.  `_isatty` is okay in the short term, but it is better to
use `GetFileType` on the `HANDLE` associated with the file descriptor.
This requires better auditing to ensure that the handle is convertible
to the underlying Windows handle.
@compnerd
Copy link
Member Author

CC: @tomerd @neonichu @abertelrud

@compnerd
Copy link
Member Author

@swift-ci please test

@@ -109,11 +109,15 @@ public final class TerminalController {

/// Computes the terminal type of the stream.
public static func terminalType(_ stream: LocalFileOutputByteStream) -> TerminalType {
#if os(Windows)
return _isatty(_fileno(stream.filePointer)) == 0 ? .file : .tty
#else
if ProcessEnv.vars["TERM"] == "dumb" {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this not needed on windows?

Copy link
Member Author

@compnerd compnerd Aug 10, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is not needed on Windows - there is no terminal emulator environment variable on Windows. You cannot query whether the current emulator is a dumb terminal or not because there never was the concept of a dumb terminal for Windows. It is a purely graphical environment, and so the only terminal emulator that is available is guaranteed to not be a dumb terminal. That said, using that as an approximation of whether the terminal emulator supports extended ASCII codes or not is not really viable on Windows. You do not have a way to query that and the best you can do is assume that the terminal emulator understands the extended VT220 ANSI escape codes (which it does if it is Windows Terminal) and let the terminal display the sequence if it does not (e.g. it is the old ConHost.exe process hosting the Windows console).

@neonichu neonichu merged commit a3e5bb8 into swiftlang:master Aug 12, 2020
@compnerd compnerd deleted the windows-terminal branch August 12, 2020 18:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants