I've been working with Docker for Windows, attempting to create a Windows Container that can run cygwin as the shell within the container itself. I haven't had any luck getting this going yet. Here's the Dockerfile that I've been messing with.
# escape=` FROM microsoft/windowsservercore SHELL ["powershell", "-command"] RUN Invoke-WebRequest https://chocolatey.org/install.ps1 -UseBasicParsing | Invoke-Expression RUN choco install cygwin -y RUN refreshenv RUN [Environment]::SetEnvironmentVariable('Path', $env:Path + ';C:\tools\cygwin\bin', [EnvironmentVariableTarget]::Machine) I've tried setting the ENTRYPOINT and CMD to try and get into cygwin, but neither seems to do anything. I've also attached to the container with docker run -it and fired off the cygwin command to get into the shell, but it doesn't appear to do anything. I don't get an error, it just returns to the command prompt as if nothing happened.
Is it possible to run another shell in the Windows Container, or am I just doing something incorrectly?
Thanks!
2 Answers
Answers 1
You don't "attach" to a container with docker run: you start a container with it.
In your case, as seen here, docker run -it is the right approach.
You can try as an entry point using c:\cygwin\bin\bash, as seen in this issue.
As commented in issue 32330:
Don't get me wrong, cygwin should work in Docker Windows containers.
But, it's also a little paradoxical that containers were painstakingly wrought into Windows, modeled on containers on Linux, only for people to then want to run Linux-utils in these newly minted Docker Windows containers...
That same issue is still unresolved, with new case seen in May and June 2018:
We have an environment that compiles with Visual Studio but still we want to use git and some very useful commands taken from linux.
Also we use of-the-shelve utilities (e.g. git-repo) that uses linux commands (e.g. curl, grep,...)Some builds require Cygwin like ICU (a cross-platform Unicode based globalization library), and worst: our builds require building it from source.
You can see an example of a crash in MSYS2-packages issue 1239:
Step 5/5 : RUN "C:\\msys64\\usr\\bin\\ls.exe" ---> Running in 5d7867a1f8da The command 'cmd /S /C "C:\\msys64\\usr\\bin\\ls.exe"' returned a non-zero code: 3221225794 This can get more information on the crash:
PS C:\msys64\usr\bin> Get-EventLog -Index 28,29,30 -LogName "Application" | Format-List -Property * The workaround was:
PS > xcopy /S C:\Git C:\Git_Copy PS > C:\Git_Copy\usr\bin\sh.exe --version > v.txt PS > type v.txt As mentioned in that thread, the output gets lost somewhere in the container, thus sending it to a text file.
Answers 2
Mainly the solution is to use winpty ahead of mintty
0 comments:
Post a Comment