8000 Error piping on Conemu · Issue #28814 · moby/moby · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Error piping on Conemu #28814

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.

Sign up for GitHub

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

Jump to bottom
Closed
giggio opened this issue Nov 24, 2016 · 12 comments
Closed

Error piping on Conemu #28814

giggio opened this issue Nov 24, 2016 · 12 comments
Labels
area/builder area/cli kind/bug Bugs are bugs. The cause may or may not be known at triage time so debugging may be needed. platform/desktop version/1.12

Comments

@giggio
Copy link
giggio commented Nov 24, 2016

When you pipe to docker build on Windows it fails under Conemu.
It is probably related to these lines which explicitly target Conemu.

Versions

C:\> docker version
Client:
 Version:      1.12.3
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   6b644ec
 Built:        Thu Oct 27 00:09:21 2016
 OS/Arch:      windows/amd64
 Experimental: true

Server:
 Version:      1.12.3
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   6b644ec
 Built:        Thu Oct 27 00:09:21 2016
 OS/Arch:      linux/amd64
 Experimental: true

ConEmu build: x64
ConEmu version: 16.10.22.0
OS version: Windows 10 x64 (Version 1607 OS Build 14393.447)
Used shell version (Far Manager, git-bash, cmd, powershell, cygwin, whatever): ???

Problem description

When using Docker for Windows, while using Linux containers, if you run on Conemu:

And PowerShell:

 echo 'FROM hello-world' | docker build -t temp -

or

'FROM hello-world' | docker build -t temp -

Or on cmd:

echo FROM hello-world | docker build -t temp -

You get this error:

unable to prepare context: failed to peek context header from STDIN: Incorrect function.

The command works on cmd and PowerShell without Conemu.
@giggio giggio mentioned this issue Nov 24, 2016
Closed
@thaJeztah thaJeztah added area/cli kind/bug Bugs are bugs. The cause may or may not be known at triage time so debugging may be needed. labels Nov 24, 2016
@sergluka
Copy link

+1

@sergluka
Copy link
sergluka commented Apr 20, 2017 •
edited
Loading

As a workaround, disabling ConEmu Settings -> Features -> ANSI and xterm sequences helped me.

@takekazuomi
Copy link
takekazuomi commented May 28, 2017 •
edited
Loading

+1

$ docker version
Client:
 Version:      17.05.0-ce
 API version:  1.29
 Go version:   go1.7.5
 Git commit:   89658be
 Built:        Thu May  4 21:43:09 2017
 OS/Arch:      windows/amd64

Server:
 Version:      17.05.0-ce
 API version:  1.29 (minimum version 1.24)
 Go version:   go1.7.5
 Git commit:   89658be
 Built:        Thu May  4 21:43:09 2017
 OS/Arch:      windows/amd64
 Experimental: true

@friism
Copy link
Contributor
friism commented May 28, 2017

cc @jhowardmsft

@jannis-baratheon jannis-baratheon mentioned this issue Oct 23, 2017
Closed
@edrevo
Copy link
Contributor
edrevo commented Aug 3, 2018

As far as I can tell, the ConEmu author thinks this is a problem with Docker because Docker doesn't behave exactly the same as it does with Powershell/cmd. Would it be reasonable to fix this by removing the ConEmuANSI check in

moby/pkg/term/term_windows.go

Lines 74 to 79 in 28cca5d

if os.Getenv("ConEmuANSI") == "ON" || os.Getenv("ConsoleZVersion") != "" {
// The ConEmu and ConsoleZ terminals emulate ANSI on output streams well.
emulateStdin = true
emulateStdout = false
emulateStderr = false
}
and treat it just like cmd?

I would be happy to make and test that change if that is an acceptable fix for this issue.

@edrevo edrevo mentioned this issue Aug 3, 2018
Closed
@thaJeztah
Copy link
Member

Looks like it's possible to test that theory; the code checks for the ConEmuANSI environment variable to be "ON" - what happens if you manually change that environment variable to another value; does it work correctly then?

@edrevo
Copy link
Contributor
edrevo commented Aug 3, 2018 •
edited
Loading

Yes, it works correctly. It is actually the workaround that's specified in Maximus5/ConEmu#958 (comment)

@thaJeztah
Copy link
Member

That comment says; disable the feature in ConEmu; in that case, the code on Docker's side will do emulation.

I'm interested if keeping the feature enabled, but overriding the env-var (to make Docker think the feature isn't enabled) does the job

If that works, there may still be something to check for; does it work because Docker is handling emulating, or did it then correctly detect that emulation is not needed.

@edrevo
Copy link
Contributor
edrevo commented Aug 3, 2018

With the feature enabled, is it impossible to override the env var unfortunately:

> $Env:ConEmuANSI="OFF"
> env
[...]
ConEmuANSI=ON
[...]

I have also tried setting a system variable ConEmuANSI="OFF", but ConEmu will override it. It looks like ConEmu is doing some work to ensure that the env var refects whether the feature is enabled or not.

I'll try removing the ConEmuANSI check from the if and try with the feature enabled in ConEmu.

@thaJeztah
Copy link
Member

Sounds good; looks like some of the code can be simplified in that case (some of the detections won't be needed), but that can be looked at after that

@edrevo
Copy link
Contributor
edrevo commented Aug 7, 2018 •
edited
Loading

A bit of an update on this:

I have removed the if os.Getenv("ConEmuANSI") == "ON" || os.Getenv("ConsoleZVersion") != "" altogether and that seems to fix the issue:

> echo 'FROM hello-world' | .\build\docker-windows-amd64.exe build -t temp -
Sending build context to Docker daemon  2.048kB
Step 1/1 : FROM hello-world
 ---> 2cb0d9787c4d
Successfully built 2cb0d9787c4d
Successfully tagged temp:latest
SECURITY WARNING: You are building a Docker image from Windows against a non-Windows Docker host. All files and directories added to build context will have '-rwxr-xr-x' permissions. It is recommended to double check and reset permissions for sensitive files and directories.
~\git\cli [master ≡ +0 ~1 -0 !]
> echo 'FROM hello-world' | docker build -t temp -
unable to prepare context: failed to peek context header from STDIN: Función incorrecta.

I have also verified that removing this block does not produce a regression on #25475

For the record, I am using Windows 10 1803 (17134.112) and ConEmu 180626. I have also verified the fix with ConsoleZ 1.18.3.18143

I have looked at some old PRs and I have seen that there have been attempts to enable native VT code processing in recent versions of Windows, but I am not sure if that effort was abandoned. There is a risk that by removing this we are falling back to a different behavior in Windows 10 than in previous Windows versions. Someone with more knowledge of the codebase should check this.

I have opened #37600

@edrevo
Copy link
Contributor
edrevo commented Aug 7, 2018 •
edited
Loading

It's also worth mentioning microsoft/terminal#231 (comment): the root cause of this bug might be a problem in IsConsole. However, since the ConEmu author prefers to not have code that specifically targets ConEmu (see Maximus5/ConEmu#958 (comment)) I think it is best to remove the if block and handle the underlying bug once there is real support in the Docker CLI for native streams (with VT processing by the console emulator).

yongtang added a commit that referenced this issue Aug 15, 2018
@yongtang
Merge pull request #37600 from edrevo/conemu-fix
74c43af 
Fix #28814: use emulation for ConEmu and ConsoleZ
@xenoscopic xenoscopic mentioned this issue Oct 25, 2018
Closed
@cdalexndr cdalexndr mentioned this issue Jun 22, 2020
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area/builder area/cli kind/bug Bugs are bugs. The cause may or may not be known at triage time so debugging may be needed. platform/desktop version/1.12
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@takekazuomi @friism @giggio @thaJeztah @edrevo @sergluka @GordonTheTurtle
0