os: FileMode Device flag not set for Windows character device #23123
Comments
bradfitz
changed the title
bradfitz
added
NeedsInvestigation
|
/cc @alexbrainman |
|
How does that workaround affect Windows users that use Cygwin? |
|
@zosmac I agree we should always set os.ModeDevice when os.ModeCharDevice is set. I will send a fix.
I don't know, I don't use Cygwin myself. But if Cygwin creates real Windows console, it should affect it in a similar way it affects cmd.exe. Alex |
|
Change https://golang.org/cl/84435 mentions this issue: |
|
On Cygwin, the "terminal" device is identified as a pipe. So it appears that for Cygwin one cannot test for a character device. I suspect that Cygwin spawns the child command with pipes connecting back to the shell process and routing to the terminal. Here are some examples of output:
For Windows:
stderr mode is 2001B6 (ModeNamedPipe)
runtime.GOOS windows
For Cygwin:
stderr mode is 20001B6 (ModeCharDevice)
runtime.GOOS windows
9024 9452 9024 10576 pty0 1052140 17:56:27 /usr/bin/bash
10132 9024 10132 7780 pty0 1052140 20:04:06 /cygdrive/u/bin/testserver
ls -l /proc/9024/fd
total 0
lrwxrwxrwx 1 zosmac Domain Users 0 Dec 18 20:18 0 -> /dev/pty0
lrwxrwxrwx 1 zosmac Domain Users 0 Dec 18 20:18 1 -> /dev/pty0
lrwxrwxrwx 1 zosmac Domain Users 0 Dec 18 20:18 2 -> /dev/pty0
lrwxrwxrwx 1 zosmac Domain Users 0 Dec 18 20:18 31 -> /dev/pty0
ls -l /proc/10132/fd
total 0
(nothing is listed)
So for Cygwin, a test to determine if a file descriptor is associated with a terminal will need to be done differently.
On Dec 15, 2017, at 6:13 PM, Alex Brainman <notifications@github.com> wrote:
@zosmac <https://github.com/zosmac> I agree we should always set os.ModeDevice when os.ModeCharDevice is set. I will send a fix.
How does that workaround affect Windows users that use Cygwin?
I don't know, I don't use Cygwin myself. But if Cygwin creates real Windows console, it should affect it in a similar way it affects cmd.exe.
Alex
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#23123 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEihQmN1hWNc17EhupN9qigV6DoLY4_Fks5tAv0bgaJpZM4RBAuO>.
|
Thanks for explaining.
Go does not support Cygwin as development environment. So I do not expect this test to work on Cygwin. Can you, please, try https://golang.org/cl/84435 . Does it fixes you problem? Thank you. Alex |
|
I have rebuilt my go compiler with this fix, rebuilt my applications to use the new behavior of the Mode setting for a character device on Windows, and successfully tested them on Windows in the DOS and Powershell terminals. As noted above, this fix will not address behavior in the Cygwin bash terminal due to the way it spawns processes and propagates the descriptors. I am investigating the Windows Console API for handling the Cygwin case, but this would certainly be overkill to attempt to handle in the Go runtime for this issue. Thank you! |
|
Found this comment in a stackexchange thread: |
In Cygwin, file descriptors are windows named pipes. The |
Sounds good, thank you for checking. We will have to wait for the change to be approved and submitted. Alex |
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version)?go version go1.9.2 darwin/amd64
Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (
go env)?Build on Macos High Sierra
Run on Windows 2012 R2
What did you do?
Based on this definition and comment in the os.FileMode's file mode bits:
I use this test to determine if stderr points to a terminal:
info, _ := os.Stderr.Stat()
mode := info.Mode()
isTerminal := mode&os.ModeDevice == os.ModeDevice && mode&os.ModeCharDevice == os.ModeCharDevice
On windows, only ModeCharDevice is set. I propose either that
for compatibility func (file *File)Stat() set ModeDevice when syscall.FILE_TYPE_CHAR is set
the different behavior be documented, e.g.
ModeCharDevice // c: Character device (on Unix, only when ModeDevice is set)
If possible, provide a recipe for reproducing the error.
What did you expect to see?
That bool isTerminal is true
What did you see instead?
isTerminal is false
Is a workaround available?
The text was updated successfully, but these errors were encountered: