instalar - cygwin windows xp

Buenas alternativas a Cygwin?-Cygwin no es compatible con aplicaciones nativas de Win32 (5)

Actualización del 1/9/2014: versión de TL; DR: vaya al final de esta publicación para obtener una forma de que Cygwin pueda llamar a programas que no son de Cygwin.

Después de haber dedicado el tiempo para crear algunos scripts bash que son de un tamaño considerable, las versiones más nuevas de Cygwin los han roto. Estos scripts llaman a aplicaciones Win32 nativas que no se vinculan con Cygwin, que aparentemente Cygwin no admite oficialmente.

Esto me ha sorprendido, ya que durante años tuve la impresión de que Cygwin podría utilizarse en un entorno más mixto que combina aplicaciones nativas que no son Cygwin Win32 y POSIX con la capa de compatibilidad Cygwin. Pero aparentemente solo la capa de compatibilidad POSIX es realmente compatible, y si las aplicaciones nativas Win32 que no son Cygwin funcionan, entonces se considera una feliz coincidencia.

Descubrí esto a partir de una incompatibilidad con la que me encontré corriendo programas compilados contra .NET Framework desde dentro de Cygwin. Esto solía funcionar bien, pero se rompió hace unos meses. Específicamente, la salida estándar de un programa .NET que se conecta a la entrada estándar de cualquier otro programa Win32 generalmente provocará que el programa receptor Win32 reciba una señal prematura de fin de archivo porque Cygwin recientemente cambió a los tubos de mensajes de los conductos de bytes hace unos meses - y los conductos de mensajes parecen ser incompatibles con cualquier aplicación receptora que use Visual C ++ o .NET Framework. Esto se debe a que .NET emite una escritura nula en el resultado estándar, que solo se transfiere a la aplicación receptora si se utiliza un conducto de mensaje. La aplicación de recepción lee con éxito cero bytes, por lo que cree que es al final del archivo. El líder del proyecto no parece considerar esto como un problema real, ya que aparentemente no admiten ejecutar programas que no sean Cygwin desde Cygwin (¡sorpresa!).

Para citar el proyecto, dirija a Christopher Faylor desde múltiples correos electrónicos en la lista de correo:

Lo que está viendo puede deberse a que Cygwin se modificó para utilizar las tuberías tipo mensaje hace un par de revisiones. Esto no va a cambiar El cambio fue adoptado para solucionar un problema con los programas de Cygwin y obviamente es nuestra prioridad número uno.
Independientemente de cuántas personas usen Visual C ++ o .NET, realmente no son nuestra audiencia objetivo. Es agradable cuando las cosas funcionan para las personas que no quieren usar las herramientas de UNIX, pero no son nuestro foco principal. Solucionar problemas para las personas que quieren usar cosas que no son de Cygwin no es algo que considere una prioridad.
Desde pipe.cc: Tenga en cuenta que el lado de escritura de la tubería se abre como PIPE_TYPE_MESSAGE. Esto parece imitar más de cerca el comportamiento de la tubería de Linux y definitivamente es necesario para el manejo pty ya que fhandler_pty_master escribe en la tubería en trozos, terminado por la nueva línea cuando se especifica el modo CANON.
El comentario anterior muestra una relación "y" aquí. Las tuberías tipo mensaje imitan más de cerca el comportamiento de las tuberías Linux (UNIX) Y son definitivamente necesarias para ptys.
Estoy de acuerdo con James en que los tiempos de ejecución probablemente sean problemáticos PERO también estoy de acuerdo en que Cygwin debería ser capaz de manejar estos escenarios.
El acuerdo completo entre ustedes no tendrá mucho efecto. El código fuente de Cygwin no se cambia al votar.

Incluso si este problema en última instancia se soluciona de alguna manera, quién sabe, podrían romper algo más en 3 meses y no les importa corregir la regresión. Podrían considerar un parche, pero me llevaría bastante tiempo descubrir algo que funciona. Creo que mi tiempo se gasta mejor en otro lado, porque está claro que están dispuestos a romper la compatibilidad con las aplicaciones nativas Win32 y no quieren perder más tiempo en hacer que las aplicaciones Win32 funcionen. Así que supongo que Cygwin no debería considerarse una plataforma estable para entornos mixtos Win32 / Cygwin. ¿Cuáles son mis alternativas? ¿Dónde debo comenzar para evitar una reescritura completa en algo distinto de bash? No uso más que la instalación básica de Cygwin + algunos scripts básicos de Perl.

ACTUALIZACIÓN: Después de la publicación de esta pregunta original, eventualmente hicieron un nuevo indicador pipe_byte en la variable de entorno CYGWIN : mira la documentación. Si se establece este indicador, se solucionará el problema discutido anteriormente. Cuando invoque un programa que no sea Cygwin Win32, siempre asegúrese de que esté configurado el indicador pipe_byte .

Sin embargo, desde entonces descubrí una incompatibilidad con .NET Framework 4.0 y Cygwin. Las versiones anteriores de .NET Framework no tienen este problema. Mencioné el problema primero en la lista de correo de Cygwin aquí:

Sincronización de tuberías e incompatibilidad entre Cygwin y .NET Framework 4.0

Al no obtener respuestas fructíferas, investigué más y descubrí que Cygwin está creando tuberías superpuestas, lo que causa el problema. Tenga en cuenta que tratar de usar llamadas a la API Win32 que no se superpusieron con un enlace superpuesto no está definido, y la mayoría (¿todos?) De los programas Win32 no Cygwin no usan E / S superpuestas con sus identificadores de archivo estándar. pipe_nooverlap un parche que crea un indicador pipe_nooverlap en la variable de entorno CYGWIN que evita que esto suceda:

Parche para desactivar opcionalmente los tubos superpuestos

Desafortunadamente, han rechazado el parche, por lo que nunca verás esto en la DLL principal de Cygwin:

Re: Parche para deshabilitar opcionalmente tuberías superpuestas

El razonamiento para rechazar el parche:

Se implicó que rompí la implementación de la señal en Cygwin; No he encontrado que este sea el caso, ya que las señales aún usan tuberías superpuestas.
No tienen ganas de agregar un indicador de variable de entorno, aunque aparentemente está solucionando problemas.
No quieren admitir código que incluso tenga la opción de tener tuberías no superpuestas.

Con razonamientos y actitudes como esta, me temo que no se me ocurre ninguna manera de cambiar el parche para que se adapte a sus requisitos ... parecen decididos a prohibir el uso de pipas no superpuestas. He estado usando el parche por un tiempo y no he tenido ningún problema con él. Además, no puedo pensar en ninguna situación en la que el indicador pipe_nooverlap se rompa (vea mi correo electrónico de seguimiento en su lista de correo), pero lo dejé como una bandera por si acaso hay problemas.

Por lo tanto, si desea llamar a programas Cygwin Win32 o .NET Framework de Cygwin, debe hacer lo siguiente:

Aplique mi parche a la fuente de la versión de Cygwin que esté utilizando. No espere que este parche aparezca en futuras versiones de Cygwin.
Establezca los pipe_byte y pipe_nooverlap en la variable de entorno CYGWIN .

Esto funciona ... por ahora! Publico esto en caso de que ayude a alguien más que todavía quiera usar Cygwin para algunas cosas.

Respuesta de 2016

Creé Cash este año, una implementación multiplataforma de comandos de Linux que se ejecutan en Node.js

Esto es compatible tanto con las instalaciones globales de cada comando en su path , como con un shell interactivo con soporte completo para la sintaxis tipo bash, la canalización de comandos, el autocompletado y el historial.

Esto también ejecuta aplicaciones win32 dentro del shell.

La mejor alternativa que encontré es Gow (Gnu en Windows) .

Es una alternativa ligera a Cygwin, unas 10 veces más ligera. Hasta donde yo sé, las 130 herramientas instaladas con Gow son aplicaciones regulares de Win32.

Solía usar cygwin principalmente para la función de servidor X11. Fue útil ejecutar cualquier herramienta en un servidor remoto y exportar la pantalla a cygwin local. Me parece que puedo lograr lo mismo con el servidor de Xming, que es mucho más ligero.

Cygnal es mi proyecto para crear un Cygwin modificado, que sirve como una biblioteca de soporte en tiempo de ejecución para aplicaciones destinadas a ejecutarse como programas nativos de Windows, siguiendo convenciones externas familiares para los usuarios de Windows.

La idea es que pueda usar el entorno completo de Cygwin para desarrollar, utilizando su cadena de herramientas predeterminada: el mismo compilador que hace los ejecutables de Cygwin. Luego puede implementar su programa como un programa Cygnal al agruparlo con el cygwin1.dll modificado del proyecto Cygnal.

Esto es especialmente útil para los programas que tienen muchas dependencias POSIX y necesitan una implementación POSIX de buena calidad y buena calidad.

El líder del proyecto no parece considerar esto como un problema real, ya que aparentemente no admiten ejecutar programas que no sean Cygwin desde Cygwin (¡sorpresa!).

Por el contrario, en el proyecto Cygnal, este tipo de cosas se considera un problema para el cual se fusionará una solución razonable.

MSYS

Puede haber menos paquetes "compatibles", en el sentido de que debe instalar cosas a mano, pero no habrá:

Problemas de ruta ( cygpath es una solución, ya que no siempre se puede meter)
Programas confundidos por los paquetes de cygwin que informan su sistema operativo como ''cygwin''
.dll / .so / .lib / .una confusión

Y hay una interoperabilidad mucho mejor con las aplicaciones de Windows.