No se "adjunta" a un contenedor con docker run : inicia un contenedor con él.

En su caso, como se ve aquí , docker run -it es el enfoque correcto.

Puede probar como punto de entrada usando c:\cygwin\bin\bash , como se ve en este problema .

Como se comentó en el número 32330 :

No me malinterpreten, cygwin debería funcionar en contenedores Docker de Windows.

Pero, también es un poco paradójico que los contenedores se forjaron minuciosamente en Windows, modelados en contenedores en Linux, solo para que las personas quisieran ejecutar Linux-utils en estos contenedores Docker Windows recién creados...

Ese mismo problema aún no se ha resuelto, con un nuevo caso visto en mayo y junio de 2018:

Tenemos un entorno que compila con Visual Studio, pero aún queremos usar git y algunos comandos muy útiles tomados de Linux.
También usamos utilidades estándar (por ejemplo, git-repo) que usan comandos de Linux (por ejemplo, curl, grep,...)

Algunas compilaciones requieren Cygwin como ICU (una biblioteca de globalización basada en Unicode multiplataforma) , y lo peor: nuestras compilaciones requieren compilación desde la fuente.

Puede ver un ejemplo de un bloqueo en el problema 1239 de MSYS2-packages :

 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

Esto puede obtener más información sobre el accidente:

 PS C:\msys64\usr\bin> Get-EventLog -Index 28,29,30 -LogName "Application" | Format-List -Property *

La solución fue:

 PS > xcopy /SC:\Git C:\Git_Copy PS > C:\Git_Copy\usr\bin\sh.exe --version > v.txt PS > type v.txt

Como se mencionó en ese hilo, la salida se pierde en algún lugar del contenedor, por lo que se envía a un archivo de texto.

Después de jugar con él durante mucho tiempo, mis hallazgos fueron los siguientes:

• Si las utilidades de Cygwin bloquean el contenedor , debe utilizar el aislamiento de procesos . Consulte https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/version-compatibility para conocer los requisitos ( esencialmente, necesita usar Windows Server 2016 y una imagen de Docker que coincida con la compilación ). Pasé un tiempo tratando de entender la razón por la cual el aislamiento de Hyper-V no funciona y hasta ahora no llegué a ninguna conclusión;

• Si sus utilidades de Cygwin aparentemente no hacen nada , pero no bloquean el contenedor, debe eliminar el indicador -t (el indicador -i todavía está bien) o, alternativamente, jugar con la redirección de salida estándar . Aparentemente, parece haber un problema con MSYS2 cuando se trata de algunos pseudo-ttys. Puede verificar que los programas aún se ejecutan si redirige stdout a un archivo (por ejemplo, whoami no generará nada cuando lo ejecute sin ninguna redirección de stdout, pero whoami > out.txt generará el resultado esperado en un archivo). Podría ser posible arreglar esto reemplazando el pseudo-tty pero no lo probé. Sospecho que el problema es un identificador no válido en algún lugar dentro de las bibliotecas MSYS2, ya que otras aplicaciones de consola pueden imprimir cosas en la terminal, pero no verifiqué esto.

Espero que ayude a todos ustedes que tienen el mismo problema.

Pude obtener una copia preinstalada (copiada del host) de Cygwin para trabajar en un contenedor basado en nanoservidor con estos dos pasos:

1. Uso de la recomendación de Żubrówka para no -t en la línea de cmd de ejecución de la ventana acoplable (cuando se ejecuta la ventana acoplable de forma interactiva)
2. Copiar el kernel32.dll del host (Windows Server 2016) en el contenedor c:\windows\system32

Encontré varias versiones de kernel32.dll en mi sistema y usé la de c:\windows\system32 con md5 hash d8948a7af764f7153b3e396ad44992ff

Esto también hizo que funcionara una gran variedad de otros ejecutables. Tenga en cuenta que sin un tty, usar el contenedor es aún más engorroso, y el shell bash no muestra el aviso. Sin embargo, los scripts (a través de Jenkins, en mi caso) que se basan en componentes cygwin funcionan bien.

Si eso no ayuda, prueba esta guía , me ayudó mucho. Si a su aplicación de Windows (que no sea cygwin) le faltan archivos DLL legítimamente, las instrucciones de esta guía pueden ayudar. ¡Nunca se me ocurrió que el procmon.exe de SysInternals se puede ejecutar en el host y seguir informando eventos desde el contenedor!