2010-04-13 17:30:11 -06:00
|
|
|
// Copyright 2009 The Go Authors. All rights reserved.
|
|
|
|
// Use of this source code is governed by a BSD-style
|
|
|
|
// license that can be found in the LICENSE file.
|
|
|
|
|
|
|
|
package os
|
|
|
|
|
|
|
|
import (
|
2015-02-26 13:10:11 -07:00
|
|
|
"internal/syscall/windows"
|
2011-11-01 19:49:08 -06:00
|
|
|
"io"
|
2010-04-13 17:30:11 -06:00
|
|
|
"runtime"
|
2011-07-01 08:18:07 -06:00
|
|
|
"sync"
|
2010-04-13 17:30:11 -06:00
|
|
|
"syscall"
|
2011-11-15 10:48:22 -07:00
|
|
|
"unicode/utf16"
|
2012-09-11 20:04:45 -06:00
|
|
|
"unicode/utf8"
|
2013-01-06 18:48:32 -07:00
|
|
|
"unsafe"
|
2010-04-13 17:30:11 -06:00
|
|
|
)
|
|
|
|
|
allow copy of struct containing unexported fields
An experiment: allow structs to be copied even if they
contain unexported fields. This gives packages the
ability to return opaque values in their APIs, like reflect
does for reflect.Value but without the kludgy hacks reflect
resorts to.
In general, we trust programmers not to do silly things
like *x = *y on a package's struct pointers, just as we trust
programmers not to do unicode.Letter = unicode.Digit,
but packages that want a harder guarantee can introduce
an extra level of indirection, like in the changes to os.File
in this CL or by using an interface type.
All in one CL so that it can be rolled back more easily if
we decide this is a bad idea.
Originally discussed in March 2011.
https://groups.google.com/group/golang-dev/t/3f5d30938c7c45ef
R=golang-dev, adg, dvyukov, r, bradfitz, jan.mercl, gri
CC=golang-dev
https://golang.org/cl/5372095
2011-11-15 10:20:59 -07:00
|
|
|
// file is the real representation of *File.
|
|
|
|
// The extra level of indirection ensures that no clients of os
|
|
|
|
// can overwrite this data, which could cause the finalizer
|
|
|
|
// to close the wrong file descriptor.
|
|
|
|
type file struct {
|
2011-07-01 08:18:07 -06:00
|
|
|
fd syscall.Handle
|
|
|
|
name string
|
|
|
|
dirinfo *dirInfo // nil unless directory being read
|
|
|
|
l sync.Mutex // used to implement windows pread/pwrite
|
2012-09-11 20:04:45 -06:00
|
|
|
|
|
|
|
// only for console io
|
os: fix handling of Windows Unicode console input and ^Z
Go 1.5 worked with Unicode console input but not ^Z.
Go 1.6 did not work with Unicode console input but did handle one ^Z case.
Go 1.7 did not work with Unicode console input but did handle one ^Z case.
The intent of this CL is for Go 1.8 to work with Unicode console input
and also handle all ^Z cases.
Here's a simple test program for reading from the console.
It prints a "> " prompt, calls read, prints what it gets, and repeats.
package main
import (
"fmt"
"os"
)
func main() {
p := make([]byte, 100)
fmt.Printf("> ")
for {
n, err := os.Stdin.Read(p)
fmt.Printf("[%d %q %v]\n> ", n, p[:n], err)
}
}
On Unix, typing a ^D produces a break in the input stream.
If the ^D is at the beginning of a line, then the 0 bytes returned
appear as an io.EOF:
$ go run /tmp/x.go
> hello
[6 "hello\n" <nil>]
> hello^D[5 "hello" <nil>]
> ^D[0 "" EOF]
> ^D[0 "" EOF]
> hello^Dworld
[5 "hello" <nil>]
> [6 "world\n" <nil>]
>
On Windows, the EOF character is ^Z, not ^D, and there has
been a long-standing problem that in Go programs, ^Z on Windows
does not behave in the expected way, namely like ^D on Unix.
Instead, the ^Z come through as literal ^Z characters:
C:\>c:\go1.5.4\bin\go run x.go
> ^Z
[3 "\x1a\r\n" <nil>]
> hello^Zworld
[13 "hello\x1aworld\r\n" <nil>]
>
CL 4310 attempted to fix this bug, then known as #6303,
by changing the use of ReadConsole to ReadFile.
This CL was released as part of Go 1.6 and did fix the case
of a ^Z by itself, but not as part of a larger input:
C:\>c:\go1.6.3\bin\go run x.go
> ^Z
[0 "" EOF]
> hello^Zworld
[13 "hello\x1aworld\r\n" <nil>]
>
So the fix was incomplete.
Worse, the fix broke Unicode console input.
ReadFile does not handle Unicode console input correctly.
To handle Unicode correctly, programs must use ReadConsole.
Early versions of Go used ReadFile to read the console,
leading to incorrect Unicode handling, which was filed as #4760
and fixed in CL 7312053, which switched to ReadConsole
and was released as part of Go 1.1 and still worked as of Go 1.5:
C:\>c:\go1.5.4\bin\go run x.go
> hello
[7 "hello\r\n" <nil>]
> hello world™
[16 "hello world™\r\n" <nil>]
>
But in Go 1.6:
C:\>c:\go1.6.3\bin\go run x.go
> hello
[7 "hello\r\n" <nil>]
> hello world™
[0 "" EOF]
>
That is, changing back to ReadFile in Go 1.6 reintroduced #4760,
which has been refiled as #17097. (We have no automated test
for this because we don't know how to simulate console input
in a test: it appears that one must actually type at a keyboard
to use the real APIs. This CL at least adds a comment warning
not to reintroduce ReadFile again.)
CL 29493 attempted to fix #17097, but it was not a complete fix:
the hello world™ example above still fails, as does Shift-JIS input,
which was filed as #17939.
CL 29493 also broke ^Z handling, which was filed as #17427.
This CL attempts the never before successfully performed trick
of simultaneously fixing Unicode console input and ^Z handling.
It changes the console input to use ReadConsole again,
as in Go 1.5, which seemed to work for all known Unicode input.
Then it adds explicit handling of ^Z in the input stream.
(In the case where standard input is a redirected file, ^Z processing
should not happen, and it does not, because this code path is only
invoked when standard input is the console.)
With this CL:
C:\>go run x.go
> hello
[7 "hello\r\n" <nil>]
> hello world™
[16 "hello world™\r\n" <nil>]
> ^Z
[0 "" EOF]
> [2 "\r\n" <nil>]
> hello^Zworld
[5 "hello" <nil>]
> [0 "" EOF]
> [7 "world\r\n" <nil>]
This almost matches Unix:
$ go run /tmp/x.go
> hello
[6 "hello\n" <nil>]
> hello world™
[15 "hello world™\n" <nil>]
> ^D
[0 "" EOF]
> [1 "\n" <nil>]
> hello^Dworld
[5 "hello" <nil>]
> [6 "world\n" <nil>]
>
The difference is in the handling of hello^Dworld / hello^Zworld.
On Unix, hello^Dworld terminates the read of hello but does not
result in a zero-length read between reading hello and world.
This is dictated by the tty driver, not any special Go code.
On Windows, in this CL, hello^Zworld inserts a zero length read
result between hello and world, which is treated as an interior EOF.
This is implemented by the Go code in this CL, but it matches the
handling of ^Z on the console in other programs:
C:\>copy con x.txt
hello^Zworld
1 file(s) copied.
C:\>type x.txt
hello
C:\>
A natural question is how to test all this. As noted above, we don't
know how to write automated tests using the actual Windows console.
CL 29493 introduced the idea of substituting a different syscall.ReadFile
implementation for testing; this CL continues that idea but substituting
for syscall.ReadConsole instead. To avoid the regression of putting
ReadFile back, this CL adds a comment warning against that.
Fixes #17427.
Fixes #17939.
Change-Id: Ibaabd0ceb2d7af501d44ac66d53f64aba3944142
Reviewed-on: https://go-review.googlesource.com/33451
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Quentin Smith <quentin@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-11-22 11:31:16 -07:00
|
|
|
isConsole bool
|
|
|
|
lastbits []byte // first few bytes of the last incomplete rune in last write
|
|
|
|
readuint16 []uint16 // buffer to hold uint16s obtained with ReadConsole
|
|
|
|
readbyte []byte // buffer to hold decoding of readuint16 from utf16 to utf8
|
|
|
|
readbyteOffset int // readbyte[readOffset:] is yet to be consumed with file.Read
|
2011-07-01 08:18:07 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
// Fd returns the Windows handle referencing the open file.
|
2014-11-06 07:36:51 -07:00
|
|
|
// The handle is valid only until f.Close is called or f is garbage collected.
|
2012-02-09 20:16:15 -07:00
|
|
|
func (file *File) Fd() uintptr {
|
2011-07-01 08:18:07 -06:00
|
|
|
if file == nil {
|
2012-02-09 20:16:15 -07:00
|
|
|
return uintptr(syscall.InvalidHandle)
|
2011-07-01 08:18:07 -06:00
|
|
|
}
|
2012-02-09 20:16:15 -07:00
|
|
|
return uintptr(file.fd)
|
2011-07-01 08:18:07 -06:00
|
|
|
}
|
|
|
|
|
2013-01-06 18:48:32 -07:00
|
|
|
// newFile returns a new File with the given file handle and name.
|
|
|
|
// Unlike NewFile, it does not check that h is syscall.InvalidHandle.
|
|
|
|
func newFile(h syscall.Handle, name string) *File {
|
2012-02-09 20:16:15 -07:00
|
|
|
f := &File{&file{fd: h, name: name}}
|
allow copy of struct containing unexported fields
An experiment: allow structs to be copied even if they
contain unexported fields. This gives packages the
ability to return opaque values in their APIs, like reflect
does for reflect.Value but without the kludgy hacks reflect
resorts to.
In general, we trust programmers not to do silly things
like *x = *y on a package's struct pointers, just as we trust
programmers not to do unicode.Letter = unicode.Digit,
but packages that want a harder guarantee can introduce
an extra level of indirection, like in the changes to os.File
in this CL or by using an interface type.
All in one CL so that it can be rolled back more easily if
we decide this is a bad idea.
Originally discussed in March 2011.
https://groups.google.com/group/golang-dev/t/3f5d30938c7c45ef
R=golang-dev, adg, dvyukov, r, bradfitz, jan.mercl, gri
CC=golang-dev
https://golang.org/cl/5372095
2011-11-15 10:20:59 -07:00
|
|
|
runtime.SetFinalizer(f.file, (*file).close)
|
2011-07-01 08:18:07 -06:00
|
|
|
return f
|
|
|
|
}
|
|
|
|
|
2016-09-20 19:19:36 -06:00
|
|
|
// newConsoleFile creates new File that will be used as console.
|
|
|
|
func newConsoleFile(h syscall.Handle, name string) *File {
|
|
|
|
f := newFile(h, name)
|
|
|
|
f.isConsole = true
|
|
|
|
return f
|
|
|
|
}
|
|
|
|
|
2013-01-06 18:48:32 -07:00
|
|
|
// NewFile returns a new File with the given file descriptor and name.
|
|
|
|
func NewFile(fd uintptr, name string) *File {
|
|
|
|
h := syscall.Handle(fd)
|
|
|
|
if h == syscall.InvalidHandle {
|
|
|
|
return nil
|
|
|
|
}
|
2016-09-20 19:19:36 -06:00
|
|
|
var m uint32
|
|
|
|
if syscall.GetConsoleMode(h, &m) == nil {
|
|
|
|
return newConsoleFile(h, name)
|
|
|
|
}
|
2013-01-06 18:48:32 -07:00
|
|
|
return newFile(h, name)
|
|
|
|
}
|
|
|
|
|
2010-04-13 17:30:11 -06:00
|
|
|
// Auxiliary information if the File describes a directory
|
|
|
|
type dirInfo struct {
|
2012-06-08 11:54:48 -06:00
|
|
|
data syscall.Win32finddata
|
2011-09-05 17:59:08 -06:00
|
|
|
needdata bool
|
2012-02-26 18:29:33 -07:00
|
|
|
path string
|
2013-01-06 18:48:32 -07:00
|
|
|
isempty bool // set if FindFirstFile returns ERROR_FILE_NOT_FOUND
|
2010-04-13 17:30:11 -06:00
|
|
|
}
|
|
|
|
|
2012-07-27 06:21:33 -06:00
|
|
|
func epipecheck(file *File, e error) {
|
|
|
|
}
|
|
|
|
|
2010-08-03 14:03:50 -06:00
|
|
|
const DevNull = "NUL"
|
|
|
|
|
2012-01-10 21:26:11 -07:00
|
|
|
func (f *file) isdir() bool { return f != nil && f.dirinfo != nil }
|
2010-04-13 17:30:11 -06:00
|
|
|
|
2012-01-19 16:45:18 -07:00
|
|
|
func openFile(name string, flag int, perm FileMode) (file *File, err error) {
|
2016-10-28 11:01:51 -06:00
|
|
|
r, e := syscall.Open(fixLongPath(name), flag|syscall.O_CLOEXEC, syscallMode(perm))
|
2011-11-13 20:44:52 -07:00
|
|
|
if e != nil {
|
2013-01-06 18:48:32 -07:00
|
|
|
return nil, e
|
2010-04-13 17:30:11 -06:00
|
|
|
}
|
2012-02-10 14:47:19 -07:00
|
|
|
return NewFile(uintptr(r), name), nil
|
2010-04-13 17:30:11 -06:00
|
|
|
}
|
|
|
|
|
2011-11-01 19:49:08 -06:00
|
|
|
func openDir(name string) (file *File, err error) {
|
2015-12-29 18:13:21 -07:00
|
|
|
var mask string
|
2016-10-28 11:01:51 -06:00
|
|
|
|
|
|
|
path := fixLongPath(name)
|
|
|
|
|
|
|
|
if len(path) == 2 && path[1] == ':' || (len(path) > 0 && path[len(path)-1] == '\\') { // it is a drive letter, like C:
|
|
|
|
mask = path + `*`
|
2015-12-29 18:13:21 -07:00
|
|
|
} else {
|
2016-10-28 11:01:51 -06:00
|
|
|
mask = path + `\*`
|
2015-12-29 18:13:21 -07:00
|
|
|
}
|
|
|
|
maskp, e := syscall.UTF16PtrFromString(mask)
|
syscall: return EINVAL when string arguments have NUL characters
Since NUL usually terminates strings in underlying syscalls, allowing
it when converting string arguments is a security risk, especially
when dealing with filenames. For example, a program might reason that
filename like "/root/..\x00/" is a subdirectory or "/root/" and allow
access to it, while underlying syscall will treat "\x00" as an end of
that string and the actual filename will be "/root/..", which might
be unexpected. Returning EINVAL when string arguments have NUL in
them makes sure this attack vector is unusable.
R=golang-dev, r, bradfitz, fullung, rsc, minux.ma
CC=golang-dev
https://golang.org/cl/6458050
2012-08-05 15:24:32 -06:00
|
|
|
if e != nil {
|
2013-01-06 18:48:32 -07:00
|
|
|
return nil, e
|
syscall: return EINVAL when string arguments have NUL characters
Since NUL usually terminates strings in underlying syscalls, allowing
it when converting string arguments is a security risk, especially
when dealing with filenames. For example, a program might reason that
filename like "/root/..\x00/" is a subdirectory or "/root/" and allow
access to it, while underlying syscall will treat "\x00" as an end of
that string and the actual filename will be "/root/..", which might
be unexpected. Returning EINVAL when string arguments have NUL in
them makes sure this attack vector is unusable.
R=golang-dev, r, bradfitz, fullung, rsc, minux.ma
CC=golang-dev
https://golang.org/cl/6458050
2012-08-05 15:24:32 -06:00
|
|
|
}
|
2010-04-13 17:30:11 -06:00
|
|
|
d := new(dirInfo)
|
syscall: return EINVAL when string arguments have NUL characters
Since NUL usually terminates strings in underlying syscalls, allowing
it when converting string arguments is a security risk, especially
when dealing with filenames. For example, a program might reason that
filename like "/root/..\x00/" is a subdirectory or "/root/" and allow
access to it, while underlying syscall will treat "\x00" as an end of
that string and the actual filename will be "/root/..", which might
be unexpected. Returning EINVAL when string arguments have NUL in
them makes sure this attack vector is unusable.
R=golang-dev, r, bradfitz, fullung, rsc, minux.ma
CC=golang-dev
https://golang.org/cl/6458050
2012-08-05 15:24:32 -06:00
|
|
|
r, e := syscall.FindFirstFile(maskp, &d.data)
|
2011-11-13 20:44:52 -07:00
|
|
|
if e != nil {
|
2013-01-06 18:48:32 -07:00
|
|
|
// FindFirstFile returns ERROR_FILE_NOT_FOUND when
|
|
|
|
// no matching files can be found. Then, if directory
|
|
|
|
// exists, we should proceed.
|
|
|
|
if e != syscall.ERROR_FILE_NOT_FOUND {
|
|
|
|
return nil, e
|
|
|
|
}
|
|
|
|
var fa syscall.Win32FileAttributeData
|
2016-10-28 11:01:51 -06:00
|
|
|
pathp, e := syscall.UTF16PtrFromString(path)
|
2013-01-06 18:48:32 -07:00
|
|
|
if e != nil {
|
|
|
|
return nil, e
|
|
|
|
}
|
2016-10-28 11:01:51 -06:00
|
|
|
e = syscall.GetFileAttributesEx(pathp, syscall.GetFileExInfoStandard, (*byte)(unsafe.Pointer(&fa)))
|
2013-01-06 18:48:32 -07:00
|
|
|
if e != nil {
|
|
|
|
return nil, e
|
|
|
|
}
|
|
|
|
if fa.FileAttributes&syscall.FILE_ATTRIBUTE_DIRECTORY == 0 {
|
|
|
|
return nil, e
|
|
|
|
}
|
|
|
|
d.isempty = true
|
2010-04-13 17:30:11 -06:00
|
|
|
}
|
2016-10-28 11:01:51 -06:00
|
|
|
d.path = path
|
2012-02-26 18:29:33 -07:00
|
|
|
if !isAbs(d.path) {
|
2014-08-18 22:59:56 -06:00
|
|
|
d.path, e = syscall.FullPath(d.path)
|
|
|
|
if e != nil {
|
|
|
|
return nil, e
|
|
|
|
}
|
2012-02-26 18:29:33 -07:00
|
|
|
}
|
2013-01-06 18:48:32 -07:00
|
|
|
f := newFile(r, name)
|
2010-04-13 17:30:11 -06:00
|
|
|
f.dirinfo = d
|
|
|
|
return f, nil
|
|
|
|
}
|
|
|
|
|
2011-04-05 00:42:14 -06:00
|
|
|
// OpenFile is the generalized open call; most users will use Open
|
2016-03-01 16:21:55 -07:00
|
|
|
// or Create instead. It opens the named file with specified flag
|
|
|
|
// (O_RDONLY etc.) and perm, (0666 etc.) if applicable. If successful,
|
2011-04-05 00:42:14 -06:00
|
|
|
// methods on the returned File can be used for I/O.
|
2012-02-08 22:55:36 -07:00
|
|
|
// If there is an error, it will be of type *PathError.
|
2015-07-17 09:26:29 -06:00
|
|
|
func OpenFile(name string, flag int, perm FileMode) (*File, error) {
|
2011-11-25 17:01:49 -07:00
|
|
|
if name == "" {
|
|
|
|
return nil, &PathError{"open", name, syscall.ENOENT}
|
|
|
|
}
|
2014-03-04 18:19:56 -07:00
|
|
|
r, errf := openFile(name, flag, perm)
|
|
|
|
if errf == nil {
|
|
|
|
return r, nil
|
|
|
|
}
|
|
|
|
r, errd := openDir(name)
|
|
|
|
if errd == nil {
|
2010-10-04 00:31:49 -06:00
|
|
|
if flag&O_WRONLY != 0 || flag&O_RDWR != 0 {
|
|
|
|
r.Close()
|
2012-02-16 16:04:29 -07:00
|
|
|
return nil, &PathError{"open", name, syscall.EISDIR}
|
2010-10-04 00:31:49 -06:00
|
|
|
}
|
2010-04-13 17:30:11 -06:00
|
|
|
return r, nil
|
|
|
|
}
|
2014-03-04 18:19:56 -07:00
|
|
|
return nil, &PathError{"open", name, errf}
|
2010-04-13 17:30:11 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
// Close closes the File, rendering it unusable for I/O.
|
2011-11-01 19:49:08 -06:00
|
|
|
// It returns an error, if any.
|
|
|
|
func (file *File) Close() error {
|
2013-08-19 22:45:46 -06:00
|
|
|
if file == nil {
|
2013-08-19 22:33:03 -06:00
|
|
|
return ErrInvalid
|
|
|
|
}
|
allow copy of struct containing unexported fields
An experiment: allow structs to be copied even if they
contain unexported fields. This gives packages the
ability to return opaque values in their APIs, like reflect
does for reflect.Value but without the kludgy hacks reflect
resorts to.
In general, we trust programmers not to do silly things
like *x = *y on a package's struct pointers, just as we trust
programmers not to do unicode.Letter = unicode.Digit,
but packages that want a harder guarantee can introduce
an extra level of indirection, like in the changes to os.File
in this CL or by using an interface type.
All in one CL so that it can be rolled back more easily if
we decide this is a bad idea.
Originally discussed in March 2011.
https://groups.google.com/group/golang-dev/t/3f5d30938c7c45ef
R=golang-dev, adg, dvyukov, r, bradfitz, jan.mercl, gri
CC=golang-dev
https://golang.org/cl/5372095
2011-11-15 10:20:59 -07:00
|
|
|
return file.file.close()
|
|
|
|
}
|
|
|
|
|
|
|
|
func (file *file) close() error {
|
2013-01-06 18:48:32 -07:00
|
|
|
if file == nil {
|
|
|
|
return syscall.EINVAL
|
|
|
|
}
|
|
|
|
if file.isdir() && file.dirinfo.isempty {
|
|
|
|
// "special" empty directories
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
if file.fd == syscall.InvalidHandle {
|
2012-02-16 16:04:29 -07:00
|
|
|
return syscall.EINVAL
|
2010-04-13 17:30:11 -06:00
|
|
|
}
|
2011-11-13 20:44:52 -07:00
|
|
|
var e error
|
2010-04-13 17:30:11 -06:00
|
|
|
if file.isdir() {
|
2016-04-14 20:09:36 -06:00
|
|
|
e = syscall.FindClose(file.fd)
|
2010-04-13 17:30:11 -06:00
|
|
|
} else {
|
2016-04-14 20:09:36 -06:00
|
|
|
e = syscall.CloseHandle(file.fd)
|
2010-04-13 17:30:11 -06:00
|
|
|
}
|
2011-11-01 19:49:08 -06:00
|
|
|
var err error
|
2011-11-13 20:44:52 -07:00
|
|
|
if e != nil {
|
|
|
|
err = &PathError{"close", file.name, e}
|
2010-04-13 17:30:11 -06:00
|
|
|
}
|
2016-10-06 22:46:56 -06:00
|
|
|
file.fd = badFd // so it can't be closed again
|
2010-04-13 17:30:11 -06:00
|
|
|
|
|
|
|
// no need for a finalizer anymore
|
|
|
|
runtime.SetFinalizer(file, nil)
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
os: fix handling of Windows Unicode console input and ^Z
Go 1.5 worked with Unicode console input but not ^Z.
Go 1.6 did not work with Unicode console input but did handle one ^Z case.
Go 1.7 did not work with Unicode console input but did handle one ^Z case.
The intent of this CL is for Go 1.8 to work with Unicode console input
and also handle all ^Z cases.
Here's a simple test program for reading from the console.
It prints a "> " prompt, calls read, prints what it gets, and repeats.
package main
import (
"fmt"
"os"
)
func main() {
p := make([]byte, 100)
fmt.Printf("> ")
for {
n, err := os.Stdin.Read(p)
fmt.Printf("[%d %q %v]\n> ", n, p[:n], err)
}
}
On Unix, typing a ^D produces a break in the input stream.
If the ^D is at the beginning of a line, then the 0 bytes returned
appear as an io.EOF:
$ go run /tmp/x.go
> hello
[6 "hello\n" <nil>]
> hello^D[5 "hello" <nil>]
> ^D[0 "" EOF]
> ^D[0 "" EOF]
> hello^Dworld
[5 "hello" <nil>]
> [6 "world\n" <nil>]
>
On Windows, the EOF character is ^Z, not ^D, and there has
been a long-standing problem that in Go programs, ^Z on Windows
does not behave in the expected way, namely like ^D on Unix.
Instead, the ^Z come through as literal ^Z characters:
C:\>c:\go1.5.4\bin\go run x.go
> ^Z
[3 "\x1a\r\n" <nil>]
> hello^Zworld
[13 "hello\x1aworld\r\n" <nil>]
>
CL 4310 attempted to fix this bug, then known as #6303,
by changing the use of ReadConsole to ReadFile.
This CL was released as part of Go 1.6 and did fix the case
of a ^Z by itself, but not as part of a larger input:
C:\>c:\go1.6.3\bin\go run x.go
> ^Z
[0 "" EOF]
> hello^Zworld
[13 "hello\x1aworld\r\n" <nil>]
>
So the fix was incomplete.
Worse, the fix broke Unicode console input.
ReadFile does not handle Unicode console input correctly.
To handle Unicode correctly, programs must use ReadConsole.
Early versions of Go used ReadFile to read the console,
leading to incorrect Unicode handling, which was filed as #4760
and fixed in CL 7312053, which switched to ReadConsole
and was released as part of Go 1.1 and still worked as of Go 1.5:
C:\>c:\go1.5.4\bin\go run x.go
> hello
[7 "hello\r\n" <nil>]
> hello world™
[16 "hello world™\r\n" <nil>]
>
But in Go 1.6:
C:\>c:\go1.6.3\bin\go run x.go
> hello
[7 "hello\r\n" <nil>]
> hello world™
[0 "" EOF]
>
That is, changing back to ReadFile in Go 1.6 reintroduced #4760,
which has been refiled as #17097. (We have no automated test
for this because we don't know how to simulate console input
in a test: it appears that one must actually type at a keyboard
to use the real APIs. This CL at least adds a comment warning
not to reintroduce ReadFile again.)
CL 29493 attempted to fix #17097, but it was not a complete fix:
the hello world™ example above still fails, as does Shift-JIS input,
which was filed as #17939.
CL 29493 also broke ^Z handling, which was filed as #17427.
This CL attempts the never before successfully performed trick
of simultaneously fixing Unicode console input and ^Z handling.
It changes the console input to use ReadConsole again,
as in Go 1.5, which seemed to work for all known Unicode input.
Then it adds explicit handling of ^Z in the input stream.
(In the case where standard input is a redirected file, ^Z processing
should not happen, and it does not, because this code path is only
invoked when standard input is the console.)
With this CL:
C:\>go run x.go
> hello
[7 "hello\r\n" <nil>]
> hello world™
[16 "hello world™\r\n" <nil>]
> ^Z
[0 "" EOF]
> [2 "\r\n" <nil>]
> hello^Zworld
[5 "hello" <nil>]
> [0 "" EOF]
> [7 "world\r\n" <nil>]
This almost matches Unix:
$ go run /tmp/x.go
> hello
[6 "hello\n" <nil>]
> hello world™
[15 "hello world™\n" <nil>]
> ^D
[0 "" EOF]
> [1 "\n" <nil>]
> hello^Dworld
[5 "hello" <nil>]
> [6 "world\n" <nil>]
>
The difference is in the handling of hello^Dworld / hello^Zworld.
On Unix, hello^Dworld terminates the read of hello but does not
result in a zero-length read between reading hello and world.
This is dictated by the tty driver, not any special Go code.
On Windows, in this CL, hello^Zworld inserts a zero length read
result between hello and world, which is treated as an interior EOF.
This is implemented by the Go code in this CL, but it matches the
handling of ^Z on the console in other programs:
C:\>copy con x.txt
hello^Zworld
1 file(s) copied.
C:\>type x.txt
hello
C:\>
A natural question is how to test all this. As noted above, we don't
know how to write automated tests using the actual Windows console.
CL 29493 introduced the idea of substituting a different syscall.ReadFile
implementation for testing; this CL continues that idea but substituting
for syscall.ReadConsole instead. To avoid the regression of putting
ReadFile back, this CL adds a comment warning against that.
Fixes #17427.
Fixes #17939.
Change-Id: Ibaabd0ceb2d7af501d44ac66d53f64aba3944142
Reviewed-on: https://go-review.googlesource.com/33451
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Quentin Smith <quentin@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-11-22 11:31:16 -07:00
|
|
|
var readConsole = syscall.ReadConsole // changed for testing
|
2016-09-20 19:19:36 -06:00
|
|
|
|
os: fix handling of Windows Unicode console input and ^Z
Go 1.5 worked with Unicode console input but not ^Z.
Go 1.6 did not work with Unicode console input but did handle one ^Z case.
Go 1.7 did not work with Unicode console input but did handle one ^Z case.
The intent of this CL is for Go 1.8 to work with Unicode console input
and also handle all ^Z cases.
Here's a simple test program for reading from the console.
It prints a "> " prompt, calls read, prints what it gets, and repeats.
package main
import (
"fmt"
"os"
)
func main() {
p := make([]byte, 100)
fmt.Printf("> ")
for {
n, err := os.Stdin.Read(p)
fmt.Printf("[%d %q %v]\n> ", n, p[:n], err)
}
}
On Unix, typing a ^D produces a break in the input stream.
If the ^D is at the beginning of a line, then the 0 bytes returned
appear as an io.EOF:
$ go run /tmp/x.go
> hello
[6 "hello\n" <nil>]
> hello^D[5 "hello" <nil>]
> ^D[0 "" EOF]
> ^D[0 "" EOF]
> hello^Dworld
[5 "hello" <nil>]
> [6 "world\n" <nil>]
>
On Windows, the EOF character is ^Z, not ^D, and there has
been a long-standing problem that in Go programs, ^Z on Windows
does not behave in the expected way, namely like ^D on Unix.
Instead, the ^Z come through as literal ^Z characters:
C:\>c:\go1.5.4\bin\go run x.go
> ^Z
[3 "\x1a\r\n" <nil>]
> hello^Zworld
[13 "hello\x1aworld\r\n" <nil>]
>
CL 4310 attempted to fix this bug, then known as #6303,
by changing the use of ReadConsole to ReadFile.
This CL was released as part of Go 1.6 and did fix the case
of a ^Z by itself, but not as part of a larger input:
C:\>c:\go1.6.3\bin\go run x.go
> ^Z
[0 "" EOF]
> hello^Zworld
[13 "hello\x1aworld\r\n" <nil>]
>
So the fix was incomplete.
Worse, the fix broke Unicode console input.
ReadFile does not handle Unicode console input correctly.
To handle Unicode correctly, programs must use ReadConsole.
Early versions of Go used ReadFile to read the console,
leading to incorrect Unicode handling, which was filed as #4760
and fixed in CL 7312053, which switched to ReadConsole
and was released as part of Go 1.1 and still worked as of Go 1.5:
C:\>c:\go1.5.4\bin\go run x.go
> hello
[7 "hello\r\n" <nil>]
> hello world™
[16 "hello world™\r\n" <nil>]
>
But in Go 1.6:
C:\>c:\go1.6.3\bin\go run x.go
> hello
[7 "hello\r\n" <nil>]
> hello world™
[0 "" EOF]
>
That is, changing back to ReadFile in Go 1.6 reintroduced #4760,
which has been refiled as #17097. (We have no automated test
for this because we don't know how to simulate console input
in a test: it appears that one must actually type at a keyboard
to use the real APIs. This CL at least adds a comment warning
not to reintroduce ReadFile again.)
CL 29493 attempted to fix #17097, but it was not a complete fix:
the hello world™ example above still fails, as does Shift-JIS input,
which was filed as #17939.
CL 29493 also broke ^Z handling, which was filed as #17427.
This CL attempts the never before successfully performed trick
of simultaneously fixing Unicode console input and ^Z handling.
It changes the console input to use ReadConsole again,
as in Go 1.5, which seemed to work for all known Unicode input.
Then it adds explicit handling of ^Z in the input stream.
(In the case where standard input is a redirected file, ^Z processing
should not happen, and it does not, because this code path is only
invoked when standard input is the console.)
With this CL:
C:\>go run x.go
> hello
[7 "hello\r\n" <nil>]
> hello world™
[16 "hello world™\r\n" <nil>]
> ^Z
[0 "" EOF]
> [2 "\r\n" <nil>]
> hello^Zworld
[5 "hello" <nil>]
> [0 "" EOF]
> [7 "world\r\n" <nil>]
This almost matches Unix:
$ go run /tmp/x.go
> hello
[6 "hello\n" <nil>]
> hello world™
[15 "hello world™\n" <nil>]
> ^D
[0 "" EOF]
> [1 "\n" <nil>]
> hello^Dworld
[5 "hello" <nil>]
> [6 "world\n" <nil>]
>
The difference is in the handling of hello^Dworld / hello^Zworld.
On Unix, hello^Dworld terminates the read of hello but does not
result in a zero-length read between reading hello and world.
This is dictated by the tty driver, not any special Go code.
On Windows, in this CL, hello^Zworld inserts a zero length read
result between hello and world, which is treated as an interior EOF.
This is implemented by the Go code in this CL, but it matches the
handling of ^Z on the console in other programs:
C:\>copy con x.txt
hello^Zworld
1 file(s) copied.
C:\>type x.txt
hello
C:\>
A natural question is how to test all this. As noted above, we don't
know how to write automated tests using the actual Windows console.
CL 29493 introduced the idea of substituting a different syscall.ReadFile
implementation for testing; this CL continues that idea but substituting
for syscall.ReadConsole instead. To avoid the regression of putting
ReadFile back, this CL adds a comment warning against that.
Fixes #17427.
Fixes #17939.
Change-Id: Ibaabd0ceb2d7af501d44ac66d53f64aba3944142
Reviewed-on: https://go-review.googlesource.com/33451
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Quentin Smith <quentin@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-11-22 11:31:16 -07:00
|
|
|
// readConsole reads utf16 characters from console File,
|
|
|
|
// encodes them into utf8 and stores them in buffer b.
|
|
|
|
// It returns the number of utf8 bytes read and an error, if any.
|
|
|
|
func (f *File) readConsole(b []byte) (n int, err error) {
|
|
|
|
if len(b) == 0 {
|
|
|
|
return 0, nil
|
|
|
|
}
|
2016-09-20 19:19:36 -06:00
|
|
|
|
os: fix handling of Windows Unicode console input and ^Z
Go 1.5 worked with Unicode console input but not ^Z.
Go 1.6 did not work with Unicode console input but did handle one ^Z case.
Go 1.7 did not work with Unicode console input but did handle one ^Z case.
The intent of this CL is for Go 1.8 to work with Unicode console input
and also handle all ^Z cases.
Here's a simple test program for reading from the console.
It prints a "> " prompt, calls read, prints what it gets, and repeats.
package main
import (
"fmt"
"os"
)
func main() {
p := make([]byte, 100)
fmt.Printf("> ")
for {
n, err := os.Stdin.Read(p)
fmt.Printf("[%d %q %v]\n> ", n, p[:n], err)
}
}
On Unix, typing a ^D produces a break in the input stream.
If the ^D is at the beginning of a line, then the 0 bytes returned
appear as an io.EOF:
$ go run /tmp/x.go
> hello
[6 "hello\n" <nil>]
> hello^D[5 "hello" <nil>]
> ^D[0 "" EOF]
> ^D[0 "" EOF]
> hello^Dworld
[5 "hello" <nil>]
> [6 "world\n" <nil>]
>
On Windows, the EOF character is ^Z, not ^D, and there has
been a long-standing problem that in Go programs, ^Z on Windows
does not behave in the expected way, namely like ^D on Unix.
Instead, the ^Z come through as literal ^Z characters:
C:\>c:\go1.5.4\bin\go run x.go
> ^Z
[3 "\x1a\r\n" <nil>]
> hello^Zworld
[13 "hello\x1aworld\r\n" <nil>]
>
CL 4310 attempted to fix this bug, then known as #6303,
by changing the use of ReadConsole to ReadFile.
This CL was released as part of Go 1.6 and did fix the case
of a ^Z by itself, but not as part of a larger input:
C:\>c:\go1.6.3\bin\go run x.go
> ^Z
[0 "" EOF]
> hello^Zworld
[13 "hello\x1aworld\r\n" <nil>]
>
So the fix was incomplete.
Worse, the fix broke Unicode console input.
ReadFile does not handle Unicode console input correctly.
To handle Unicode correctly, programs must use ReadConsole.
Early versions of Go used ReadFile to read the console,
leading to incorrect Unicode handling, which was filed as #4760
and fixed in CL 7312053, which switched to ReadConsole
and was released as part of Go 1.1 and still worked as of Go 1.5:
C:\>c:\go1.5.4\bin\go run x.go
> hello
[7 "hello\r\n" <nil>]
> hello world™
[16 "hello world™\r\n" <nil>]
>
But in Go 1.6:
C:\>c:\go1.6.3\bin\go run x.go
> hello
[7 "hello\r\n" <nil>]
> hello world™
[0 "" EOF]
>
That is, changing back to ReadFile in Go 1.6 reintroduced #4760,
which has been refiled as #17097. (We have no automated test
for this because we don't know how to simulate console input
in a test: it appears that one must actually type at a keyboard
to use the real APIs. This CL at least adds a comment warning
not to reintroduce ReadFile again.)
CL 29493 attempted to fix #17097, but it was not a complete fix:
the hello world™ example above still fails, as does Shift-JIS input,
which was filed as #17939.
CL 29493 also broke ^Z handling, which was filed as #17427.
This CL attempts the never before successfully performed trick
of simultaneously fixing Unicode console input and ^Z handling.
It changes the console input to use ReadConsole again,
as in Go 1.5, which seemed to work for all known Unicode input.
Then it adds explicit handling of ^Z in the input stream.
(In the case where standard input is a redirected file, ^Z processing
should not happen, and it does not, because this code path is only
invoked when standard input is the console.)
With this CL:
C:\>go run x.go
> hello
[7 "hello\r\n" <nil>]
> hello world™
[16 "hello world™\r\n" <nil>]
> ^Z
[0 "" EOF]
> [2 "\r\n" <nil>]
> hello^Zworld
[5 "hello" <nil>]
> [0 "" EOF]
> [7 "world\r\n" <nil>]
This almost matches Unix:
$ go run /tmp/x.go
> hello
[6 "hello\n" <nil>]
> hello world™
[15 "hello world™\n" <nil>]
> ^D
[0 "" EOF]
> [1 "\n" <nil>]
> hello^Dworld
[5 "hello" <nil>]
> [6 "world\n" <nil>]
>
The difference is in the handling of hello^Dworld / hello^Zworld.
On Unix, hello^Dworld terminates the read of hello but does not
result in a zero-length read between reading hello and world.
This is dictated by the tty driver, not any special Go code.
On Windows, in this CL, hello^Zworld inserts a zero length read
result between hello and world, which is treated as an interior EOF.
This is implemented by the Go code in this CL, but it matches the
handling of ^Z on the console in other programs:
C:\>copy con x.txt
hello^Zworld
1 file(s) copied.
C:\>type x.txt
hello
C:\>
A natural question is how to test all this. As noted above, we don't
know how to write automated tests using the actual Windows console.
CL 29493 introduced the idea of substituting a different syscall.ReadFile
implementation for testing; this CL continues that idea but substituting
for syscall.ReadConsole instead. To avoid the regression of putting
ReadFile back, this CL adds a comment warning against that.
Fixes #17427.
Fixes #17939.
Change-Id: Ibaabd0ceb2d7af501d44ac66d53f64aba3944142
Reviewed-on: https://go-review.googlesource.com/33451
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Quentin Smith <quentin@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-11-22 11:31:16 -07:00
|
|
|
if f.readuint16 == nil {
|
|
|
|
// Note: syscall.ReadConsole fails for very large buffers.
|
|
|
|
// The limit is somewhere around (but not exactly) 16384.
|
|
|
|
// Stay well below.
|
|
|
|
f.readuint16 = make([]uint16, 0, 10000)
|
|
|
|
f.readbyte = make([]byte, 0, 4*cap(f.readuint16))
|
|
|
|
}
|
2016-09-20 19:19:36 -06:00
|
|
|
|
os: fix handling of Windows Unicode console input and ^Z
Go 1.5 worked with Unicode console input but not ^Z.
Go 1.6 did not work with Unicode console input but did handle one ^Z case.
Go 1.7 did not work with Unicode console input but did handle one ^Z case.
The intent of this CL is for Go 1.8 to work with Unicode console input
and also handle all ^Z cases.
Here's a simple test program for reading from the console.
It prints a "> " prompt, calls read, prints what it gets, and repeats.
package main
import (
"fmt"
"os"
)
func main() {
p := make([]byte, 100)
fmt.Printf("> ")
for {
n, err := os.Stdin.Read(p)
fmt.Printf("[%d %q %v]\n> ", n, p[:n], err)
}
}
On Unix, typing a ^D produces a break in the input stream.
If the ^D is at the beginning of a line, then the 0 bytes returned
appear as an io.EOF:
$ go run /tmp/x.go
> hello
[6 "hello\n" <nil>]
> hello^D[5 "hello" <nil>]
> ^D[0 "" EOF]
> ^D[0 "" EOF]
> hello^Dworld
[5 "hello" <nil>]
> [6 "world\n" <nil>]
>
On Windows, the EOF character is ^Z, not ^D, and there has
been a long-standing problem that in Go programs, ^Z on Windows
does not behave in the expected way, namely like ^D on Unix.
Instead, the ^Z come through as literal ^Z characters:
C:\>c:\go1.5.4\bin\go run x.go
> ^Z
[3 "\x1a\r\n" <nil>]
> hello^Zworld
[13 "hello\x1aworld\r\n" <nil>]
>
CL 4310 attempted to fix this bug, then known as #6303,
by changing the use of ReadConsole to ReadFile.
This CL was released as part of Go 1.6 and did fix the case
of a ^Z by itself, but not as part of a larger input:
C:\>c:\go1.6.3\bin\go run x.go
> ^Z
[0 "" EOF]
> hello^Zworld
[13 "hello\x1aworld\r\n" <nil>]
>
So the fix was incomplete.
Worse, the fix broke Unicode console input.
ReadFile does not handle Unicode console input correctly.
To handle Unicode correctly, programs must use ReadConsole.
Early versions of Go used ReadFile to read the console,
leading to incorrect Unicode handling, which was filed as #4760
and fixed in CL 7312053, which switched to ReadConsole
and was released as part of Go 1.1 and still worked as of Go 1.5:
C:\>c:\go1.5.4\bin\go run x.go
> hello
[7 "hello\r\n" <nil>]
> hello world™
[16 "hello world™\r\n" <nil>]
>
But in Go 1.6:
C:\>c:\go1.6.3\bin\go run x.go
> hello
[7 "hello\r\n" <nil>]
> hello world™
[0 "" EOF]
>
That is, changing back to ReadFile in Go 1.6 reintroduced #4760,
which has been refiled as #17097. (We have no automated test
for this because we don't know how to simulate console input
in a test: it appears that one must actually type at a keyboard
to use the real APIs. This CL at least adds a comment warning
not to reintroduce ReadFile again.)
CL 29493 attempted to fix #17097, but it was not a complete fix:
the hello world™ example above still fails, as does Shift-JIS input,
which was filed as #17939.
CL 29493 also broke ^Z handling, which was filed as #17427.
This CL attempts the never before successfully performed trick
of simultaneously fixing Unicode console input and ^Z handling.
It changes the console input to use ReadConsole again,
as in Go 1.5, which seemed to work for all known Unicode input.
Then it adds explicit handling of ^Z in the input stream.
(In the case where standard input is a redirected file, ^Z processing
should not happen, and it does not, because this code path is only
invoked when standard input is the console.)
With this CL:
C:\>go run x.go
> hello
[7 "hello\r\n" <nil>]
> hello world™
[16 "hello world™\r\n" <nil>]
> ^Z
[0 "" EOF]
> [2 "\r\n" <nil>]
> hello^Zworld
[5 "hello" <nil>]
> [0 "" EOF]
> [7 "world\r\n" <nil>]
This almost matches Unix:
$ go run /tmp/x.go
> hello
[6 "hello\n" <nil>]
> hello world™
[15 "hello world™\n" <nil>]
> ^D
[0 "" EOF]
> [1 "\n" <nil>]
> hello^Dworld
[5 "hello" <nil>]
> [6 "world\n" <nil>]
>
The difference is in the handling of hello^Dworld / hello^Zworld.
On Unix, hello^Dworld terminates the read of hello but does not
result in a zero-length read between reading hello and world.
This is dictated by the tty driver, not any special Go code.
On Windows, in this CL, hello^Zworld inserts a zero length read
result between hello and world, which is treated as an interior EOF.
This is implemented by the Go code in this CL, but it matches the
handling of ^Z on the console in other programs:
C:\>copy con x.txt
hello^Zworld
1 file(s) copied.
C:\>type x.txt
hello
C:\>
A natural question is how to test all this. As noted above, we don't
know how to write automated tests using the actual Windows console.
CL 29493 introduced the idea of substituting a different syscall.ReadFile
implementation for testing; this CL continues that idea but substituting
for syscall.ReadConsole instead. To avoid the regression of putting
ReadFile back, this CL adds a comment warning against that.
Fixes #17427.
Fixes #17939.
Change-Id: Ibaabd0ceb2d7af501d44ac66d53f64aba3944142
Reviewed-on: https://go-review.googlesource.com/33451
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Quentin Smith <quentin@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-11-22 11:31:16 -07:00
|
|
|
for f.readbyteOffset >= len(f.readbyte) {
|
|
|
|
n := cap(f.readuint16) - len(f.readuint16)
|
|
|
|
if n > len(b) {
|
|
|
|
n = len(b)
|
2016-09-20 19:19:36 -06:00
|
|
|
}
|
os: fix handling of Windows Unicode console input and ^Z
Go 1.5 worked with Unicode console input but not ^Z.
Go 1.6 did not work with Unicode console input but did handle one ^Z case.
Go 1.7 did not work with Unicode console input but did handle one ^Z case.
The intent of this CL is for Go 1.8 to work with Unicode console input
and also handle all ^Z cases.
Here's a simple test program for reading from the console.
It prints a "> " prompt, calls read, prints what it gets, and repeats.
package main
import (
"fmt"
"os"
)
func main() {
p := make([]byte, 100)
fmt.Printf("> ")
for {
n, err := os.Stdin.Read(p)
fmt.Printf("[%d %q %v]\n> ", n, p[:n], err)
}
}
On Unix, typing a ^D produces a break in the input stream.
If the ^D is at the beginning of a line, then the 0 bytes returned
appear as an io.EOF:
$ go run /tmp/x.go
> hello
[6 "hello\n" <nil>]
> hello^D[5 "hello" <nil>]
> ^D[0 "" EOF]
> ^D[0 "" EOF]
> hello^Dworld
[5 "hello" <nil>]
> [6 "world\n" <nil>]
>
On Windows, the EOF character is ^Z, not ^D, and there has
been a long-standing problem that in Go programs, ^Z on Windows
does not behave in the expected way, namely like ^D on Unix.
Instead, the ^Z come through as literal ^Z characters:
C:\>c:\go1.5.4\bin\go run x.go
> ^Z
[3 "\x1a\r\n" <nil>]
> hello^Zworld
[13 "hello\x1aworld\r\n" <nil>]
>
CL 4310 attempted to fix this bug, then known as #6303,
by changing the use of ReadConsole to ReadFile.
This CL was released as part of Go 1.6 and did fix the case
of a ^Z by itself, but not as part of a larger input:
C:\>c:\go1.6.3\bin\go run x.go
> ^Z
[0 "" EOF]
> hello^Zworld
[13 "hello\x1aworld\r\n" <nil>]
>
So the fix was incomplete.
Worse, the fix broke Unicode console input.
ReadFile does not handle Unicode console input correctly.
To handle Unicode correctly, programs must use ReadConsole.
Early versions of Go used ReadFile to read the console,
leading to incorrect Unicode handling, which was filed as #4760
and fixed in CL 7312053, which switched to ReadConsole
and was released as part of Go 1.1 and still worked as of Go 1.5:
C:\>c:\go1.5.4\bin\go run x.go
> hello
[7 "hello\r\n" <nil>]
> hello world™
[16 "hello world™\r\n" <nil>]
>
But in Go 1.6:
C:\>c:\go1.6.3\bin\go run x.go
> hello
[7 "hello\r\n" <nil>]
> hello world™
[0 "" EOF]
>
That is, changing back to ReadFile in Go 1.6 reintroduced #4760,
which has been refiled as #17097. (We have no automated test
for this because we don't know how to simulate console input
in a test: it appears that one must actually type at a keyboard
to use the real APIs. This CL at least adds a comment warning
not to reintroduce ReadFile again.)
CL 29493 attempted to fix #17097, but it was not a complete fix:
the hello world™ example above still fails, as does Shift-JIS input,
which was filed as #17939.
CL 29493 also broke ^Z handling, which was filed as #17427.
This CL attempts the never before successfully performed trick
of simultaneously fixing Unicode console input and ^Z handling.
It changes the console input to use ReadConsole again,
as in Go 1.5, which seemed to work for all known Unicode input.
Then it adds explicit handling of ^Z in the input stream.
(In the case where standard input is a redirected file, ^Z processing
should not happen, and it does not, because this code path is only
invoked when standard input is the console.)
With this CL:
C:\>go run x.go
> hello
[7 "hello\r\n" <nil>]
> hello world™
[16 "hello world™\r\n" <nil>]
> ^Z
[0 "" EOF]
> [2 "\r\n" <nil>]
> hello^Zworld
[5 "hello" <nil>]
> [0 "" EOF]
> [7 "world\r\n" <nil>]
This almost matches Unix:
$ go run /tmp/x.go
> hello
[6 "hello\n" <nil>]
> hello world™
[15 "hello world™\n" <nil>]
> ^D
[0 "" EOF]
> [1 "\n" <nil>]
> hello^Dworld
[5 "hello" <nil>]
> [6 "world\n" <nil>]
>
The difference is in the handling of hello^Dworld / hello^Zworld.
On Unix, hello^Dworld terminates the read of hello but does not
result in a zero-length read between reading hello and world.
This is dictated by the tty driver, not any special Go code.
On Windows, in this CL, hello^Zworld inserts a zero length read
result between hello and world, which is treated as an interior EOF.
This is implemented by the Go code in this CL, but it matches the
handling of ^Z on the console in other programs:
C:\>copy con x.txt
hello^Zworld
1 file(s) copied.
C:\>type x.txt
hello
C:\>
A natural question is how to test all this. As noted above, we don't
know how to write automated tests using the actual Windows console.
CL 29493 introduced the idea of substituting a different syscall.ReadFile
implementation for testing; this CL continues that idea but substituting
for syscall.ReadConsole instead. To avoid the regression of putting
ReadFile back, this CL adds a comment warning against that.
Fixes #17427.
Fixes #17939.
Change-Id: Ibaabd0ceb2d7af501d44ac66d53f64aba3944142
Reviewed-on: https://go-review.googlesource.com/33451
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Quentin Smith <quentin@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-11-22 11:31:16 -07:00
|
|
|
var nw uint32
|
|
|
|
err := readConsole(f.fd, &f.readuint16[:len(f.readuint16)+1][len(f.readuint16)], uint32(n), &nw, nil)
|
2016-09-20 19:19:36 -06:00
|
|
|
if err != nil {
|
|
|
|
return 0, err
|
|
|
|
}
|
os: fix handling of Windows Unicode console input and ^Z
Go 1.5 worked with Unicode console input but not ^Z.
Go 1.6 did not work with Unicode console input but did handle one ^Z case.
Go 1.7 did not work with Unicode console input but did handle one ^Z case.
The intent of this CL is for Go 1.8 to work with Unicode console input
and also handle all ^Z cases.
Here's a simple test program for reading from the console.
It prints a "> " prompt, calls read, prints what it gets, and repeats.
package main
import (
"fmt"
"os"
)
func main() {
p := make([]byte, 100)
fmt.Printf("> ")
for {
n, err := os.Stdin.Read(p)
fmt.Printf("[%d %q %v]\n> ", n, p[:n], err)
}
}
On Unix, typing a ^D produces a break in the input stream.
If the ^D is at the beginning of a line, then the 0 bytes returned
appear as an io.EOF:
$ go run /tmp/x.go
> hello
[6 "hello\n" <nil>]
> hello^D[5 "hello" <nil>]
> ^D[0 "" EOF]
> ^D[0 "" EOF]
> hello^Dworld
[5 "hello" <nil>]
> [6 "world\n" <nil>]
>
On Windows, the EOF character is ^Z, not ^D, and there has
been a long-standing problem that in Go programs, ^Z on Windows
does not behave in the expected way, namely like ^D on Unix.
Instead, the ^Z come through as literal ^Z characters:
C:\>c:\go1.5.4\bin\go run x.go
> ^Z
[3 "\x1a\r\n" <nil>]
> hello^Zworld
[13 "hello\x1aworld\r\n" <nil>]
>
CL 4310 attempted to fix this bug, then known as #6303,
by changing the use of ReadConsole to ReadFile.
This CL was released as part of Go 1.6 and did fix the case
of a ^Z by itself, but not as part of a larger input:
C:\>c:\go1.6.3\bin\go run x.go
> ^Z
[0 "" EOF]
> hello^Zworld
[13 "hello\x1aworld\r\n" <nil>]
>
So the fix was incomplete.
Worse, the fix broke Unicode console input.
ReadFile does not handle Unicode console input correctly.
To handle Unicode correctly, programs must use ReadConsole.
Early versions of Go used ReadFile to read the console,
leading to incorrect Unicode handling, which was filed as #4760
and fixed in CL 7312053, which switched to ReadConsole
and was released as part of Go 1.1 and still worked as of Go 1.5:
C:\>c:\go1.5.4\bin\go run x.go
> hello
[7 "hello\r\n" <nil>]
> hello world™
[16 "hello world™\r\n" <nil>]
>
But in Go 1.6:
C:\>c:\go1.6.3\bin\go run x.go
> hello
[7 "hello\r\n" <nil>]
> hello world™
[0 "" EOF]
>
That is, changing back to ReadFile in Go 1.6 reintroduced #4760,
which has been refiled as #17097. (We have no automated test
for this because we don't know how to simulate console input
in a test: it appears that one must actually type at a keyboard
to use the real APIs. This CL at least adds a comment warning
not to reintroduce ReadFile again.)
CL 29493 attempted to fix #17097, but it was not a complete fix:
the hello world™ example above still fails, as does Shift-JIS input,
which was filed as #17939.
CL 29493 also broke ^Z handling, which was filed as #17427.
This CL attempts the never before successfully performed trick
of simultaneously fixing Unicode console input and ^Z handling.
It changes the console input to use ReadConsole again,
as in Go 1.5, which seemed to work for all known Unicode input.
Then it adds explicit handling of ^Z in the input stream.
(In the case where standard input is a redirected file, ^Z processing
should not happen, and it does not, because this code path is only
invoked when standard input is the console.)
With this CL:
C:\>go run x.go
> hello
[7 "hello\r\n" <nil>]
> hello world™
[16 "hello world™\r\n" <nil>]
> ^Z
[0 "" EOF]
> [2 "\r\n" <nil>]
> hello^Zworld
[5 "hello" <nil>]
> [0 "" EOF]
> [7 "world\r\n" <nil>]
This almost matches Unix:
$ go run /tmp/x.go
> hello
[6 "hello\n" <nil>]
> hello world™
[15 "hello world™\n" <nil>]
> ^D
[0 "" EOF]
> [1 "\n" <nil>]
> hello^Dworld
[5 "hello" <nil>]
> [6 "world\n" <nil>]
>
The difference is in the handling of hello^Dworld / hello^Zworld.
On Unix, hello^Dworld terminates the read of hello but does not
result in a zero-length read between reading hello and world.
This is dictated by the tty driver, not any special Go code.
On Windows, in this CL, hello^Zworld inserts a zero length read
result between hello and world, which is treated as an interior EOF.
This is implemented by the Go code in this CL, but it matches the
handling of ^Z on the console in other programs:
C:\>copy con x.txt
hello^Zworld
1 file(s) copied.
C:\>type x.txt
hello
C:\>
A natural question is how to test all this. As noted above, we don't
know how to write automated tests using the actual Windows console.
CL 29493 introduced the idea of substituting a different syscall.ReadFile
implementation for testing; this CL continues that idea but substituting
for syscall.ReadConsole instead. To avoid the regression of putting
ReadFile back, this CL adds a comment warning against that.
Fixes #17427.
Fixes #17939.
Change-Id: Ibaabd0ceb2d7af501d44ac66d53f64aba3944142
Reviewed-on: https://go-review.googlesource.com/33451
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Quentin Smith <quentin@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-11-22 11:31:16 -07:00
|
|
|
uint16s := f.readuint16[:len(f.readuint16)+int(nw)]
|
|
|
|
f.readuint16 = f.readuint16[:0]
|
|
|
|
buf := f.readbyte[:0]
|
|
|
|
for i := 0; i < len(uint16s); i++ {
|
|
|
|
r := rune(uint16s[i])
|
|
|
|
if utf16.IsSurrogate(r) {
|
|
|
|
if i+1 == len(uint16s) {
|
|
|
|
if nw > 0 {
|
|
|
|
// Save half surrogate pair for next time.
|
|
|
|
f.readuint16 = f.readuint16[:1]
|
|
|
|
f.readuint16[0] = uint16(r)
|
|
|
|
break
|
|
|
|
}
|
|
|
|
r = utf8.RuneError
|
|
|
|
} else {
|
|
|
|
r = utf16.DecodeRune(r, rune(uint16s[i+1]))
|
|
|
|
if r != utf8.RuneError {
|
|
|
|
i++
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
n := utf8.EncodeRune(buf[len(buf):cap(buf)], r)
|
|
|
|
buf = buf[:len(buf)+n]
|
2016-09-20 19:19:36 -06:00
|
|
|
}
|
os: fix handling of Windows Unicode console input and ^Z
Go 1.5 worked with Unicode console input but not ^Z.
Go 1.6 did not work with Unicode console input but did handle one ^Z case.
Go 1.7 did not work with Unicode console input but did handle one ^Z case.
The intent of this CL is for Go 1.8 to work with Unicode console input
and also handle all ^Z cases.
Here's a simple test program for reading from the console.
It prints a "> " prompt, calls read, prints what it gets, and repeats.
package main
import (
"fmt"
"os"
)
func main() {
p := make([]byte, 100)
fmt.Printf("> ")
for {
n, err := os.Stdin.Read(p)
fmt.Printf("[%d %q %v]\n> ", n, p[:n], err)
}
}
On Unix, typing a ^D produces a break in the input stream.
If the ^D is at the beginning of a line, then the 0 bytes returned
appear as an io.EOF:
$ go run /tmp/x.go
> hello
[6 "hello\n" <nil>]
> hello^D[5 "hello" <nil>]
> ^D[0 "" EOF]
> ^D[0 "" EOF]
> hello^Dworld
[5 "hello" <nil>]
> [6 "world\n" <nil>]
>
On Windows, the EOF character is ^Z, not ^D, and there has
been a long-standing problem that in Go programs, ^Z on Windows
does not behave in the expected way, namely like ^D on Unix.
Instead, the ^Z come through as literal ^Z characters:
C:\>c:\go1.5.4\bin\go run x.go
> ^Z
[3 "\x1a\r\n" <nil>]
> hello^Zworld
[13 "hello\x1aworld\r\n" <nil>]
>
CL 4310 attempted to fix this bug, then known as #6303,
by changing the use of ReadConsole to ReadFile.
This CL was released as part of Go 1.6 and did fix the case
of a ^Z by itself, but not as part of a larger input:
C:\>c:\go1.6.3\bin\go run x.go
> ^Z
[0 "" EOF]
> hello^Zworld
[13 "hello\x1aworld\r\n" <nil>]
>
So the fix was incomplete.
Worse, the fix broke Unicode console input.
ReadFile does not handle Unicode console input correctly.
To handle Unicode correctly, programs must use ReadConsole.
Early versions of Go used ReadFile to read the console,
leading to incorrect Unicode handling, which was filed as #4760
and fixed in CL 7312053, which switched to ReadConsole
and was released as part of Go 1.1 and still worked as of Go 1.5:
C:\>c:\go1.5.4\bin\go run x.go
> hello
[7 "hello\r\n" <nil>]
> hello world™
[16 "hello world™\r\n" <nil>]
>
But in Go 1.6:
C:\>c:\go1.6.3\bin\go run x.go
> hello
[7 "hello\r\n" <nil>]
> hello world™
[0 "" EOF]
>
That is, changing back to ReadFile in Go 1.6 reintroduced #4760,
which has been refiled as #17097. (We have no automated test
for this because we don't know how to simulate console input
in a test: it appears that one must actually type at a keyboard
to use the real APIs. This CL at least adds a comment warning
not to reintroduce ReadFile again.)
CL 29493 attempted to fix #17097, but it was not a complete fix:
the hello world™ example above still fails, as does Shift-JIS input,
which was filed as #17939.
CL 29493 also broke ^Z handling, which was filed as #17427.
This CL attempts the never before successfully performed trick
of simultaneously fixing Unicode console input and ^Z handling.
It changes the console input to use ReadConsole again,
as in Go 1.5, which seemed to work for all known Unicode input.
Then it adds explicit handling of ^Z in the input stream.
(In the case where standard input is a redirected file, ^Z processing
should not happen, and it does not, because this code path is only
invoked when standard input is the console.)
With this CL:
C:\>go run x.go
> hello
[7 "hello\r\n" <nil>]
> hello world™
[16 "hello world™\r\n" <nil>]
> ^Z
[0 "" EOF]
> [2 "\r\n" <nil>]
> hello^Zworld
[5 "hello" <nil>]
> [0 "" EOF]
> [7 "world\r\n" <nil>]
This almost matches Unix:
$ go run /tmp/x.go
> hello
[6 "hello\n" <nil>]
> hello world™
[15 "hello world™\n" <nil>]
> ^D
[0 "" EOF]
> [1 "\n" <nil>]
> hello^Dworld
[5 "hello" <nil>]
> [6 "world\n" <nil>]
>
The difference is in the handling of hello^Dworld / hello^Zworld.
On Unix, hello^Dworld terminates the read of hello but does not
result in a zero-length read between reading hello and world.
This is dictated by the tty driver, not any special Go code.
On Windows, in this CL, hello^Zworld inserts a zero length read
result between hello and world, which is treated as an interior EOF.
This is implemented by the Go code in this CL, but it matches the
handling of ^Z on the console in other programs:
C:\>copy con x.txt
hello^Zworld
1 file(s) copied.
C:\>type x.txt
hello
C:\>
A natural question is how to test all this. As noted above, we don't
know how to write automated tests using the actual Windows console.
CL 29493 introduced the idea of substituting a different syscall.ReadFile
implementation for testing; this CL continues that idea but substituting
for syscall.ReadConsole instead. To avoid the regression of putting
ReadFile back, this CL adds a comment warning against that.
Fixes #17427.
Fixes #17939.
Change-Id: Ibaabd0ceb2d7af501d44ac66d53f64aba3944142
Reviewed-on: https://go-review.googlesource.com/33451
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Quentin Smith <quentin@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-11-22 11:31:16 -07:00
|
|
|
f.readbyte = buf
|
|
|
|
f.readbyteOffset = 0
|
|
|
|
if nw == 0 {
|
|
|
|
break
|
2016-09-20 19:19:36 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
os: fix handling of Windows Unicode console input and ^Z
Go 1.5 worked with Unicode console input but not ^Z.
Go 1.6 did not work with Unicode console input but did handle one ^Z case.
Go 1.7 did not work with Unicode console input but did handle one ^Z case.
The intent of this CL is for Go 1.8 to work with Unicode console input
and also handle all ^Z cases.
Here's a simple test program for reading from the console.
It prints a "> " prompt, calls read, prints what it gets, and repeats.
package main
import (
"fmt"
"os"
)
func main() {
p := make([]byte, 100)
fmt.Printf("> ")
for {
n, err := os.Stdin.Read(p)
fmt.Printf("[%d %q %v]\n> ", n, p[:n], err)
}
}
On Unix, typing a ^D produces a break in the input stream.
If the ^D is at the beginning of a line, then the 0 bytes returned
appear as an io.EOF:
$ go run /tmp/x.go
> hello
[6 "hello\n" <nil>]
> hello^D[5 "hello" <nil>]
> ^D[0 "" EOF]
> ^D[0 "" EOF]
> hello^Dworld
[5 "hello" <nil>]
> [6 "world\n" <nil>]
>
On Windows, the EOF character is ^Z, not ^D, and there has
been a long-standing problem that in Go programs, ^Z on Windows
does not behave in the expected way, namely like ^D on Unix.
Instead, the ^Z come through as literal ^Z characters:
C:\>c:\go1.5.4\bin\go run x.go
> ^Z
[3 "\x1a\r\n" <nil>]
> hello^Zworld
[13 "hello\x1aworld\r\n" <nil>]
>
CL 4310 attempted to fix this bug, then known as #6303,
by changing the use of ReadConsole to ReadFile.
This CL was released as part of Go 1.6 and did fix the case
of a ^Z by itself, but not as part of a larger input:
C:\>c:\go1.6.3\bin\go run x.go
> ^Z
[0 "" EOF]
> hello^Zworld
[13 "hello\x1aworld\r\n" <nil>]
>
So the fix was incomplete.
Worse, the fix broke Unicode console input.
ReadFile does not handle Unicode console input correctly.
To handle Unicode correctly, programs must use ReadConsole.
Early versions of Go used ReadFile to read the console,
leading to incorrect Unicode handling, which was filed as #4760
and fixed in CL 7312053, which switched to ReadConsole
and was released as part of Go 1.1 and still worked as of Go 1.5:
C:\>c:\go1.5.4\bin\go run x.go
> hello
[7 "hello\r\n" <nil>]
> hello world™
[16 "hello world™\r\n" <nil>]
>
But in Go 1.6:
C:\>c:\go1.6.3\bin\go run x.go
> hello
[7 "hello\r\n" <nil>]
> hello world™
[0 "" EOF]
>
That is, changing back to ReadFile in Go 1.6 reintroduced #4760,
which has been refiled as #17097. (We have no automated test
for this because we don't know how to simulate console input
in a test: it appears that one must actually type at a keyboard
to use the real APIs. This CL at least adds a comment warning
not to reintroduce ReadFile again.)
CL 29493 attempted to fix #17097, but it was not a complete fix:
the hello world™ example above still fails, as does Shift-JIS input,
which was filed as #17939.
CL 29493 also broke ^Z handling, which was filed as #17427.
This CL attempts the never before successfully performed trick
of simultaneously fixing Unicode console input and ^Z handling.
It changes the console input to use ReadConsole again,
as in Go 1.5, which seemed to work for all known Unicode input.
Then it adds explicit handling of ^Z in the input stream.
(In the case where standard input is a redirected file, ^Z processing
should not happen, and it does not, because this code path is only
invoked when standard input is the console.)
With this CL:
C:\>go run x.go
> hello
[7 "hello\r\n" <nil>]
> hello world™
[16 "hello world™\r\n" <nil>]
> ^Z
[0 "" EOF]
> [2 "\r\n" <nil>]
> hello^Zworld
[5 "hello" <nil>]
> [0 "" EOF]
> [7 "world\r\n" <nil>]
This almost matches Unix:
$ go run /tmp/x.go
> hello
[6 "hello\n" <nil>]
> hello world™
[15 "hello world™\n" <nil>]
> ^D
[0 "" EOF]
> [1 "\n" <nil>]
> hello^Dworld
[5 "hello" <nil>]
> [6 "world\n" <nil>]
>
The difference is in the handling of hello^Dworld / hello^Zworld.
On Unix, hello^Dworld terminates the read of hello but does not
result in a zero-length read between reading hello and world.
This is dictated by the tty driver, not any special Go code.
On Windows, in this CL, hello^Zworld inserts a zero length read
result between hello and world, which is treated as an interior EOF.
This is implemented by the Go code in this CL, but it matches the
handling of ^Z on the console in other programs:
C:\>copy con x.txt
hello^Zworld
1 file(s) copied.
C:\>type x.txt
hello
C:\>
A natural question is how to test all this. As noted above, we don't
know how to write automated tests using the actual Windows console.
CL 29493 introduced the idea of substituting a different syscall.ReadFile
implementation for testing; this CL continues that idea but substituting
for syscall.ReadConsole instead. To avoid the regression of putting
ReadFile back, this CL adds a comment warning against that.
Fixes #17427.
Fixes #17939.
Change-Id: Ibaabd0ceb2d7af501d44ac66d53f64aba3944142
Reviewed-on: https://go-review.googlesource.com/33451
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Quentin Smith <quentin@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-11-22 11:31:16 -07:00
|
|
|
src := f.readbyte[f.readbyteOffset:]
|
|
|
|
var i int
|
|
|
|
for i = 0; i < len(src) && i < len(b); i++ {
|
|
|
|
x := src[i]
|
|
|
|
if x == 0x1A { // Ctrl-Z
|
|
|
|
if i == 0 {
|
|
|
|
f.readbyteOffset++
|
|
|
|
}
|
|
|
|
break
|
2013-02-25 20:18:48 -07:00
|
|
|
}
|
os: fix handling of Windows Unicode console input and ^Z
Go 1.5 worked with Unicode console input but not ^Z.
Go 1.6 did not work with Unicode console input but did handle one ^Z case.
Go 1.7 did not work with Unicode console input but did handle one ^Z case.
The intent of this CL is for Go 1.8 to work with Unicode console input
and also handle all ^Z cases.
Here's a simple test program for reading from the console.
It prints a "> " prompt, calls read, prints what it gets, and repeats.
package main
import (
"fmt"
"os"
)
func main() {
p := make([]byte, 100)
fmt.Printf("> ")
for {
n, err := os.Stdin.Read(p)
fmt.Printf("[%d %q %v]\n> ", n, p[:n], err)
}
}
On Unix, typing a ^D produces a break in the input stream.
If the ^D is at the beginning of a line, then the 0 bytes returned
appear as an io.EOF:
$ go run /tmp/x.go
> hello
[6 "hello\n" <nil>]
> hello^D[5 "hello" <nil>]
> ^D[0 "" EOF]
> ^D[0 "" EOF]
> hello^Dworld
[5 "hello" <nil>]
> [6 "world\n" <nil>]
>
On Windows, the EOF character is ^Z, not ^D, and there has
been a long-standing problem that in Go programs, ^Z on Windows
does not behave in the expected way, namely like ^D on Unix.
Instead, the ^Z come through as literal ^Z characters:
C:\>c:\go1.5.4\bin\go run x.go
> ^Z
[3 "\x1a\r\n" <nil>]
> hello^Zworld
[13 "hello\x1aworld\r\n" <nil>]
>
CL 4310 attempted to fix this bug, then known as #6303,
by changing the use of ReadConsole to ReadFile.
This CL was released as part of Go 1.6 and did fix the case
of a ^Z by itself, but not as part of a larger input:
C:\>c:\go1.6.3\bin\go run x.go
> ^Z
[0 "" EOF]
> hello^Zworld
[13 "hello\x1aworld\r\n" <nil>]
>
So the fix was incomplete.
Worse, the fix broke Unicode console input.
ReadFile does not handle Unicode console input correctly.
To handle Unicode correctly, programs must use ReadConsole.
Early versions of Go used ReadFile to read the console,
leading to incorrect Unicode handling, which was filed as #4760
and fixed in CL 7312053, which switched to ReadConsole
and was released as part of Go 1.1 and still worked as of Go 1.5:
C:\>c:\go1.5.4\bin\go run x.go
> hello
[7 "hello\r\n" <nil>]
> hello world™
[16 "hello world™\r\n" <nil>]
>
But in Go 1.6:
C:\>c:\go1.6.3\bin\go run x.go
> hello
[7 "hello\r\n" <nil>]
> hello world™
[0 "" EOF]
>
That is, changing back to ReadFile in Go 1.6 reintroduced #4760,
which has been refiled as #17097. (We have no automated test
for this because we don't know how to simulate console input
in a test: it appears that one must actually type at a keyboard
to use the real APIs. This CL at least adds a comment warning
not to reintroduce ReadFile again.)
CL 29493 attempted to fix #17097, but it was not a complete fix:
the hello world™ example above still fails, as does Shift-JIS input,
which was filed as #17939.
CL 29493 also broke ^Z handling, which was filed as #17427.
This CL attempts the never before successfully performed trick
of simultaneously fixing Unicode console input and ^Z handling.
It changes the console input to use ReadConsole again,
as in Go 1.5, which seemed to work for all known Unicode input.
Then it adds explicit handling of ^Z in the input stream.
(In the case where standard input is a redirected file, ^Z processing
should not happen, and it does not, because this code path is only
invoked when standard input is the console.)
With this CL:
C:\>go run x.go
> hello
[7 "hello\r\n" <nil>]
> hello world™
[16 "hello world™\r\n" <nil>]
> ^Z
[0 "" EOF]
> [2 "\r\n" <nil>]
> hello^Zworld
[5 "hello" <nil>]
> [0 "" EOF]
> [7 "world\r\n" <nil>]
This almost matches Unix:
$ go run /tmp/x.go
> hello
[6 "hello\n" <nil>]
> hello world™
[15 "hello world™\n" <nil>]
> ^D
[0 "" EOF]
> [1 "\n" <nil>]
> hello^Dworld
[5 "hello" <nil>]
> [6 "world\n" <nil>]
>
The difference is in the handling of hello^Dworld / hello^Zworld.
On Unix, hello^Dworld terminates the read of hello but does not
result in a zero-length read between reading hello and world.
This is dictated by the tty driver, not any special Go code.
On Windows, in this CL, hello^Zworld inserts a zero length read
result between hello and world, which is treated as an interior EOF.
This is implemented by the Go code in this CL, but it matches the
handling of ^Z on the console in other programs:
C:\>copy con x.txt
hello^Zworld
1 file(s) copied.
C:\>type x.txt
hello
C:\>
A natural question is how to test all this. As noted above, we don't
know how to write automated tests using the actual Windows console.
CL 29493 introduced the idea of substituting a different syscall.ReadFile
implementation for testing; this CL continues that idea but substituting
for syscall.ReadConsole instead. To avoid the regression of putting
ReadFile back, this CL adds a comment warning against that.
Fixes #17427.
Fixes #17939.
Change-Id: Ibaabd0ceb2d7af501d44ac66d53f64aba3944142
Reviewed-on: https://go-review.googlesource.com/33451
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Quentin Smith <quentin@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-11-22 11:31:16 -07:00
|
|
|
b[i] = x
|
2016-09-20 19:19:36 -06:00
|
|
|
}
|
os: fix handling of Windows Unicode console input and ^Z
Go 1.5 worked with Unicode console input but not ^Z.
Go 1.6 did not work with Unicode console input but did handle one ^Z case.
Go 1.7 did not work with Unicode console input but did handle one ^Z case.
The intent of this CL is for Go 1.8 to work with Unicode console input
and also handle all ^Z cases.
Here's a simple test program for reading from the console.
It prints a "> " prompt, calls read, prints what it gets, and repeats.
package main
import (
"fmt"
"os"
)
func main() {
p := make([]byte, 100)
fmt.Printf("> ")
for {
n, err := os.Stdin.Read(p)
fmt.Printf("[%d %q %v]\n> ", n, p[:n], err)
}
}
On Unix, typing a ^D produces a break in the input stream.
If the ^D is at the beginning of a line, then the 0 bytes returned
appear as an io.EOF:
$ go run /tmp/x.go
> hello
[6 "hello\n" <nil>]
> hello^D[5 "hello" <nil>]
> ^D[0 "" EOF]
> ^D[0 "" EOF]
> hello^Dworld
[5 "hello" <nil>]
> [6 "world\n" <nil>]
>
On Windows, the EOF character is ^Z, not ^D, and there has
been a long-standing problem that in Go programs, ^Z on Windows
does not behave in the expected way, namely like ^D on Unix.
Instead, the ^Z come through as literal ^Z characters:
C:\>c:\go1.5.4\bin\go run x.go
> ^Z
[3 "\x1a\r\n" <nil>]
> hello^Zworld
[13 "hello\x1aworld\r\n" <nil>]
>
CL 4310 attempted to fix this bug, then known as #6303,
by changing the use of ReadConsole to ReadFile.
This CL was released as part of Go 1.6 and did fix the case
of a ^Z by itself, but not as part of a larger input:
C:\>c:\go1.6.3\bin\go run x.go
> ^Z
[0 "" EOF]
> hello^Zworld
[13 "hello\x1aworld\r\n" <nil>]
>
So the fix was incomplete.
Worse, the fix broke Unicode console input.
ReadFile does not handle Unicode console input correctly.
To handle Unicode correctly, programs must use ReadConsole.
Early versions of Go used ReadFile to read the console,
leading to incorrect Unicode handling, which was filed as #4760
and fixed in CL 7312053, which switched to ReadConsole
and was released as part of Go 1.1 and still worked as of Go 1.5:
C:\>c:\go1.5.4\bin\go run x.go
> hello
[7 "hello\r\n" <nil>]
> hello world™
[16 "hello world™\r\n" <nil>]
>
But in Go 1.6:
C:\>c:\go1.6.3\bin\go run x.go
> hello
[7 "hello\r\n" <nil>]
> hello world™
[0 "" EOF]
>
That is, changing back to ReadFile in Go 1.6 reintroduced #4760,
which has been refiled as #17097. (We have no automated test
for this because we don't know how to simulate console input
in a test: it appears that one must actually type at a keyboard
to use the real APIs. This CL at least adds a comment warning
not to reintroduce ReadFile again.)
CL 29493 attempted to fix #17097, but it was not a complete fix:
the hello world™ example above still fails, as does Shift-JIS input,
which was filed as #17939.
CL 29493 also broke ^Z handling, which was filed as #17427.
This CL attempts the never before successfully performed trick
of simultaneously fixing Unicode console input and ^Z handling.
It changes the console input to use ReadConsole again,
as in Go 1.5, which seemed to work for all known Unicode input.
Then it adds explicit handling of ^Z in the input stream.
(In the case where standard input is a redirected file, ^Z processing
should not happen, and it does not, because this code path is only
invoked when standard input is the console.)
With this CL:
C:\>go run x.go
> hello
[7 "hello\r\n" <nil>]
> hello world™
[16 "hello world™\r\n" <nil>]
> ^Z
[0 "" EOF]
> [2 "\r\n" <nil>]
> hello^Zworld
[5 "hello" <nil>]
> [0 "" EOF]
> [7 "world\r\n" <nil>]
This almost matches Unix:
$ go run /tmp/x.go
> hello
[6 "hello\n" <nil>]
> hello world™
[15 "hello world™\n" <nil>]
> ^D
[0 "" EOF]
> [1 "\n" <nil>]
> hello^Dworld
[5 "hello" <nil>]
> [6 "world\n" <nil>]
>
The difference is in the handling of hello^Dworld / hello^Zworld.
On Unix, hello^Dworld terminates the read of hello but does not
result in a zero-length read between reading hello and world.
This is dictated by the tty driver, not any special Go code.
On Windows, in this CL, hello^Zworld inserts a zero length read
result between hello and world, which is treated as an interior EOF.
This is implemented by the Go code in this CL, but it matches the
handling of ^Z on the console in other programs:
C:\>copy con x.txt
hello^Zworld
1 file(s) copied.
C:\>type x.txt
hello
C:\>
A natural question is how to test all this. As noted above, we don't
know how to write automated tests using the actual Windows console.
CL 29493 introduced the idea of substituting a different syscall.ReadFile
implementation for testing; this CL continues that idea but substituting
for syscall.ReadConsole instead. To avoid the regression of putting
ReadFile back, this CL adds a comment warning against that.
Fixes #17427.
Fixes #17939.
Change-Id: Ibaabd0ceb2d7af501d44ac66d53f64aba3944142
Reviewed-on: https://go-review.googlesource.com/33451
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Quentin Smith <quentin@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-11-22 11:31:16 -07:00
|
|
|
f.readbyteOffset += i
|
|
|
|
return i, nil
|
2013-02-25 20:18:48 -07:00
|
|
|
}
|
|
|
|
|
2011-04-26 02:09:46 -06:00
|
|
|
// read reads up to len(b) bytes from the File.
|
|
|
|
// It returns the number of bytes read and an error, if any.
|
2011-11-13 20:44:52 -07:00
|
|
|
func (f *File) read(b []byte) (n int, err error) {
|
2011-04-26 02:09:46 -06:00
|
|
|
f.l.Lock()
|
|
|
|
defer f.l.Unlock()
|
2013-02-25 20:18:48 -07:00
|
|
|
if f.isConsole {
|
|
|
|
return f.readConsole(b)
|
|
|
|
}
|
2014-10-28 13:00:13 -06:00
|
|
|
return fixCount(syscall.Read(f.fd, b))
|
2011-04-26 02:09:46 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
// pread reads len(b) bytes from the File starting at byte offset off.
|
|
|
|
// It returns the number of bytes read and the error, if any.
|
|
|
|
// EOF is signaled by a zero count with err set to 0.
|
2011-11-13 20:44:52 -07:00
|
|
|
func (f *File) pread(b []byte, off int64) (n int, err error) {
|
2011-04-26 02:09:46 -06:00
|
|
|
f.l.Lock()
|
|
|
|
defer f.l.Unlock()
|
2016-04-05 12:22:53 -06:00
|
|
|
curoffset, e := syscall.Seek(f.fd, 0, io.SeekCurrent)
|
2011-11-13 20:44:52 -07:00
|
|
|
if e != nil {
|
2011-04-26 02:09:46 -06:00
|
|
|
return 0, e
|
|
|
|
}
|
2016-04-05 12:22:53 -06:00
|
|
|
defer syscall.Seek(f.fd, curoffset, io.SeekStart)
|
2011-04-26 02:09:46 -06:00
|
|
|
o := syscall.Overlapped{
|
|
|
|
OffsetHigh: uint32(off >> 32),
|
|
|
|
Offset: uint32(off),
|
|
|
|
}
|
|
|
|
var done uint32
|
2016-04-14 20:09:36 -06:00
|
|
|
e = syscall.ReadFile(f.fd, b, &done, &o)
|
2011-11-13 20:44:52 -07:00
|
|
|
if e != nil {
|
2013-06-10 03:14:41 -06:00
|
|
|
if e == syscall.ERROR_HANDLE_EOF {
|
|
|
|
// end of file
|
|
|
|
return 0, nil
|
|
|
|
}
|
2011-04-26 02:09:46 -06:00
|
|
|
return 0, e
|
|
|
|
}
|
2011-11-13 20:44:52 -07:00
|
|
|
return int(done), nil
|
2011-04-26 02:09:46 -06:00
|
|
|
}
|
|
|
|
|
2012-09-11 20:04:45 -06:00
|
|
|
// writeConsole writes len(b) bytes to the console File.
|
|
|
|
// It returns the number of bytes written and an error, if any.
|
|
|
|
func (f *File) writeConsole(b []byte) (n int, err error) {
|
|
|
|
n = len(b)
|
|
|
|
runes := make([]rune, 0, 256)
|
|
|
|
if len(f.lastbits) > 0 {
|
|
|
|
b = append(f.lastbits, b...)
|
|
|
|
f.lastbits = nil
|
|
|
|
|
|
|
|
}
|
|
|
|
for len(b) >= utf8.UTFMax || utf8.FullRune(b) {
|
|
|
|
r, l := utf8.DecodeRune(b)
|
|
|
|
runes = append(runes, r)
|
|
|
|
b = b[l:]
|
|
|
|
}
|
|
|
|
if len(b) > 0 {
|
|
|
|
f.lastbits = make([]byte, len(b))
|
|
|
|
copy(f.lastbits, b)
|
|
|
|
}
|
2012-09-19 00:55:21 -06:00
|
|
|
// syscall.WriteConsole seems to fail, if given large buffer.
|
|
|
|
// So limit the buffer to 16000 characters. This number was
|
|
|
|
// discovered by experimenting with syscall.WriteConsole.
|
|
|
|
const maxWrite = 16000
|
|
|
|
for len(runes) > 0 {
|
|
|
|
m := len(runes)
|
|
|
|
if m > maxWrite {
|
|
|
|
m = maxWrite
|
|
|
|
}
|
|
|
|
chunk := runes[:m]
|
|
|
|
runes = runes[m:]
|
|
|
|
uint16s := utf16.Encode(chunk)
|
2012-09-11 20:04:45 -06:00
|
|
|
for len(uint16s) > 0 {
|
|
|
|
var written uint32
|
|
|
|
err = syscall.WriteConsole(f.fd, &uint16s[0], uint32(len(uint16s)), &written, nil)
|
|
|
|
if err != nil {
|
|
|
|
return 0, nil
|
|
|
|
}
|
|
|
|
uint16s = uint16s[written:]
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return n, nil
|
|
|
|
}
|
|
|
|
|
2011-04-26 02:09:46 -06:00
|
|
|
// write writes len(b) bytes to the File.
|
|
|
|
// It returns the number of bytes written and an error, if any.
|
2011-11-13 20:44:52 -07:00
|
|
|
func (f *File) write(b []byte) (n int, err error) {
|
2011-04-26 02:09:46 -06:00
|
|
|
f.l.Lock()
|
|
|
|
defer f.l.Unlock()
|
2012-09-11 20:04:45 -06:00
|
|
|
if f.isConsole {
|
|
|
|
return f.writeConsole(b)
|
|
|
|
}
|
2014-10-28 13:00:13 -06:00
|
|
|
return fixCount(syscall.Write(f.fd, b))
|
2011-04-26 02:09:46 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
// pwrite writes len(b) bytes to the File starting at byte offset off.
|
|
|
|
// It returns the number of bytes written and an error, if any.
|
2011-11-13 20:44:52 -07:00
|
|
|
func (f *File) pwrite(b []byte, off int64) (n int, err error) {
|
2011-04-26 02:09:46 -06:00
|
|
|
f.l.Lock()
|
|
|
|
defer f.l.Unlock()
|
2016-04-05 12:22:53 -06:00
|
|
|
curoffset, e := syscall.Seek(f.fd, 0, io.SeekCurrent)
|
2011-11-13 20:44:52 -07:00
|
|
|
if e != nil {
|
2011-04-26 02:09:46 -06:00
|
|
|
return 0, e
|
|
|
|
}
|
2016-04-05 12:22:53 -06:00
|
|
|
defer syscall.Seek(f.fd, curoffset, io.SeekStart)
|
2011-04-26 02:09:46 -06:00
|
|
|
o := syscall.Overlapped{
|
|
|
|
OffsetHigh: uint32(off >> 32),
|
|
|
|
Offset: uint32(off),
|
|
|
|
}
|
|
|
|
var done uint32
|
2016-04-14 20:09:36 -06:00
|
|
|
e = syscall.WriteFile(f.fd, b, &done, &o)
|
2011-11-13 20:44:52 -07:00
|
|
|
if e != nil {
|
2011-04-26 02:09:46 -06:00
|
|
|
return 0, e
|
|
|
|
}
|
2011-11-13 20:44:52 -07:00
|
|
|
return int(done), nil
|
2011-04-26 02:09:46 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
// seek sets the offset for the next Read or Write on file to offset, interpreted
|
|
|
|
// according to whence: 0 means relative to the origin of the file, 1 means
|
|
|
|
// relative to the current offset, and 2 means relative to the end.
|
|
|
|
// It returns the new offset and an error, if any.
|
2011-11-13 20:44:52 -07:00
|
|
|
func (f *File) seek(offset int64, whence int) (ret int64, err error) {
|
2011-04-26 02:09:46 -06:00
|
|
|
f.l.Lock()
|
|
|
|
defer f.l.Unlock()
|
|
|
|
return syscall.Seek(f.fd, offset, whence)
|
|
|
|
}
|
|
|
|
|
2010-04-27 00:17:14 -06:00
|
|
|
// Truncate changes the size of the named file.
|
|
|
|
// If the file is a symbolic link, it changes the size of the link's target.
|
2011-11-01 19:49:08 -06:00
|
|
|
func Truncate(name string, size int64) error {
|
2011-04-05 00:57:08 -06:00
|
|
|
f, e := OpenFile(name, O_WRONLY|O_CREATE, 0666)
|
2010-04-27 00:17:14 -06:00
|
|
|
if e != nil {
|
|
|
|
return e
|
|
|
|
}
|
|
|
|
defer f.Close()
|
|
|
|
e1 := f.Truncate(size)
|
|
|
|
if e1 != nil {
|
|
|
|
return e1
|
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
2011-07-01 08:18:07 -06:00
|
|
|
|
2011-12-19 17:52:20 -07:00
|
|
|
// Remove removes the named file or directory.
|
2012-02-08 22:55:36 -07:00
|
|
|
// If there is an error, it will be of type *PathError.
|
2011-12-19 17:52:20 -07:00
|
|
|
func Remove(name string) error {
|
2016-10-28 11:01:51 -06:00
|
|
|
p, e := syscall.UTF16PtrFromString(fixLongPath(name))
|
syscall: return EINVAL when string arguments have NUL characters
Since NUL usually terminates strings in underlying syscalls, allowing
it when converting string arguments is a security risk, especially
when dealing with filenames. For example, a program might reason that
filename like "/root/..\x00/" is a subdirectory or "/root/" and allow
access to it, while underlying syscall will treat "\x00" as an end of
that string and the actual filename will be "/root/..", which might
be unexpected. Returning EINVAL when string arguments have NUL in
them makes sure this attack vector is unusable.
R=golang-dev, r, bradfitz, fullung, rsc, minux.ma
CC=golang-dev
https://golang.org/cl/6458050
2012-08-05 15:24:32 -06:00
|
|
|
if e != nil {
|
|
|
|
return &PathError{"remove", name, e}
|
|
|
|
}
|
2011-12-19 17:52:20 -07:00
|
|
|
|
|
|
|
// Go file interface forces us to know whether
|
|
|
|
// name is a file or directory. Try both.
|
syscall: return EINVAL when string arguments have NUL characters
Since NUL usually terminates strings in underlying syscalls, allowing
it when converting string arguments is a security risk, especially
when dealing with filenames. For example, a program might reason that
filename like "/root/..\x00/" is a subdirectory or "/root/" and allow
access to it, while underlying syscall will treat "\x00" as an end of
that string and the actual filename will be "/root/..", which might
be unexpected. Returning EINVAL when string arguments have NUL in
them makes sure this attack vector is unusable.
R=golang-dev, r, bradfitz, fullung, rsc, minux.ma
CC=golang-dev
https://golang.org/cl/6458050
2012-08-05 15:24:32 -06:00
|
|
|
e = syscall.DeleteFile(p)
|
2011-12-19 17:52:20 -07:00
|
|
|
if e == nil {
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
e1 := syscall.RemoveDirectory(p)
|
|
|
|
if e1 == nil {
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// Both failed: figure out which error to return.
|
|
|
|
if e1 != e {
|
|
|
|
a, e2 := syscall.GetFileAttributes(p)
|
|
|
|
if e2 != nil {
|
|
|
|
e = e2
|
|
|
|
} else {
|
|
|
|
if a&syscall.FILE_ATTRIBUTE_DIRECTORY != 0 {
|
|
|
|
e = e1
|
2016-04-07 12:24:24 -06:00
|
|
|
} else if a&syscall.FILE_ATTRIBUTE_READONLY != 0 {
|
|
|
|
if e1 = syscall.SetFileAttributes(p, a&^syscall.FILE_ATTRIBUTE_READONLY); e1 == nil {
|
|
|
|
if e = syscall.DeleteFile(p); e == nil {
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
}
|
2011-12-19 17:52:20 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return &PathError{"remove", name, e}
|
|
|
|
}
|
|
|
|
|
2015-02-26 13:10:11 -07:00
|
|
|
func rename(oldname, newname string) error {
|
2016-10-28 11:01:51 -06:00
|
|
|
e := windows.Rename(fixLongPath(oldname), fixLongPath(newname))
|
2015-02-26 13:10:11 -07:00
|
|
|
if e != nil {
|
|
|
|
return &LinkError{"rename", oldname, newname, e}
|
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2011-07-01 08:18:07 -06:00
|
|
|
// Pipe returns a connected pair of Files; reads from r return bytes written to w.
|
2011-11-01 19:49:08 -06:00
|
|
|
// It returns the files and an error, if any.
|
|
|
|
func Pipe() (r *File, w *File, err error) {
|
2011-07-01 08:18:07 -06:00
|
|
|
var p [2]syscall.Handle
|
|
|
|
|
|
|
|
// See ../syscall/exec.go for description of lock.
|
|
|
|
syscall.ForkLock.RLock()
|
|
|
|
e := syscall.Pipe(p[0:])
|
2011-11-13 20:44:52 -07:00
|
|
|
if e != nil {
|
2011-07-01 08:18:07 -06:00
|
|
|
syscall.ForkLock.RUnlock()
|
|
|
|
return nil, nil, NewSyscallError("pipe", e)
|
|
|
|
}
|
|
|
|
syscall.CloseOnExec(p[0])
|
|
|
|
syscall.CloseOnExec(p[1])
|
|
|
|
syscall.ForkLock.RUnlock()
|
|
|
|
|
2012-02-10 14:47:19 -07:00
|
|
|
return NewFile(uintptr(p[0]), "|0"), NewFile(uintptr(p[1]), "|1"), nil
|
2011-07-01 08:18:07 -06:00
|
|
|
}
|
2011-11-14 12:06:50 -07:00
|
|
|
|
|
|
|
// TempDir returns the default directory to use for temporary files.
|
|
|
|
func TempDir() string {
|
2015-02-12 22:12:07 -07:00
|
|
|
n := uint32(syscall.MAX_PATH)
|
|
|
|
for {
|
|
|
|
b := make([]uint16, n)
|
|
|
|
n, _ = syscall.GetTempPath(uint32(len(b)), &b[0])
|
|
|
|
if n > uint32(len(b)) {
|
|
|
|
continue
|
2011-11-14 12:06:50 -07:00
|
|
|
}
|
2015-02-12 22:12:07 -07:00
|
|
|
if n > 0 && b[n-1] == '\\' {
|
|
|
|
n--
|
|
|
|
}
|
|
|
|
return string(utf16.Decode(b[:n]))
|
2011-11-14 12:06:50 -07:00
|
|
|
}
|
|
|
|
}
|
2014-07-17 01:02:46 -06:00
|
|
|
|
|
|
|
// Link creates newname as a hard link to the oldname file.
|
|
|
|
// If there is an error, it will be of type *LinkError.
|
|
|
|
func Link(oldname, newname string) error {
|
2016-10-28 11:01:51 -06:00
|
|
|
n, err := syscall.UTF16PtrFromString(fixLongPath(newname))
|
2014-07-17 01:02:46 -06:00
|
|
|
if err != nil {
|
|
|
|
return &LinkError{"link", oldname, newname, err}
|
|
|
|
}
|
2016-10-28 11:01:51 -06:00
|
|
|
o, err := syscall.UTF16PtrFromString(fixLongPath(oldname))
|
2014-07-17 01:02:46 -06:00
|
|
|
if err != nil {
|
|
|
|
return &LinkError{"link", oldname, newname, err}
|
|
|
|
}
|
2015-02-27 10:34:25 -07:00
|
|
|
err = syscall.CreateHardLink(n, o, 0)
|
|
|
|
if err != nil {
|
2014-07-17 01:02:46 -06:00
|
|
|
return &LinkError{"link", oldname, newname, err}
|
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// Symlink creates newname as a symbolic link to oldname.
|
|
|
|
// If there is an error, it will be of type *LinkError.
|
|
|
|
func Symlink(oldname, newname string) error {
|
|
|
|
// CreateSymbolicLink is not supported before Windows Vista
|
|
|
|
if syscall.LoadCreateSymbolicLink() != nil {
|
|
|
|
return &LinkError{"symlink", oldname, newname, syscall.EWINDOWS}
|
|
|
|
}
|
|
|
|
|
|
|
|
// '/' does not work in link's content
|
|
|
|
oldname = fromSlash(oldname)
|
|
|
|
|
|
|
|
// need the exact location of the oldname when its relative to determine if its a directory
|
|
|
|
destpath := oldname
|
|
|
|
if !isAbs(oldname) {
|
|
|
|
destpath = dirname(newname) + `\` + oldname
|
|
|
|
}
|
|
|
|
|
|
|
|
fi, err := Lstat(destpath)
|
|
|
|
isdir := err == nil && fi.IsDir()
|
|
|
|
|
2016-10-28 11:01:51 -06:00
|
|
|
n, err := syscall.UTF16PtrFromString(fixLongPath(newname))
|
2014-07-17 01:02:46 -06:00
|
|
|
if err != nil {
|
|
|
|
return &LinkError{"symlink", oldname, newname, err}
|
|
|
|
}
|
2016-10-28 11:01:51 -06:00
|
|
|
o, err := syscall.UTF16PtrFromString(fixLongPath(oldname))
|
2014-07-17 01:02:46 -06:00
|
|
|
if err != nil {
|
|
|
|
return &LinkError{"symlink", oldname, newname, err}
|
|
|
|
}
|
|
|
|
|
|
|
|
var flags uint32
|
|
|
|
if isdir {
|
|
|
|
flags |= syscall.SYMBOLIC_LINK_FLAG_DIRECTORY
|
|
|
|
}
|
|
|
|
err = syscall.CreateSymbolicLink(n, o, flags)
|
|
|
|
if err != nil {
|
|
|
|
return &LinkError{"symlink", oldname, newname, err}
|
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
2016-10-06 22:46:56 -06:00
|
|
|
|
|
|
|
const badFd = syscall.InvalidHandle
|