De bonnes alternatives à Cygwin? - Cygwin ne prend pas en charge nativement les applications Win32
Mise à jour 1/9/2014: TL; version DR: Allez en bas de cet article pour obtenir un moyen pour que Cygwin puisse appeler des non-Cygwin programmes.
Après avoir passé du temps à créer des scripts bash de taille significative, les nouvelles versions de Cygwin les ont cassés. Ces scripts appellent des applications Win32 natives qui ne sont pas liées à Cygwin, qui n'est apparemment pas officiellement pris en charge par Cygwin.
Cela m'a surpris, car pendant des années, j'avais l'impression que Cygwin pouvait être utilisé dans un environnement plus mixte combinant à la fois des applications natives non Cygwin Win32 et des programmes POSIX utilisant la couche de compatibilité Cygwin. Mais apparemment, seule la couche de compatibilité POSIX est réellement prise en charge, et si les applications natives Win32 non Cygwin fonctionnent, cela est considéré comme une heureuse coïncidence.
J'ai découvert cela à partir d'une incompatibilité que j'ai rencontrée avec les programmes en cours d'exécution compilés avec le .NET Framework à partir de Cygwin. Cela fonctionnait bien, mais a été rompu il y a quelques mois. Plus précisément, la sortie standard d'un programme .NET qui est redirigée vers l'entrée standard de tout autre programme Win32 entraînera généralement le programme Win32 récepteur pour obtenir un signal de fin de fichier prématuré car Cygwin est récemment passé aux canaux de messages des canaux d'octets il y a quelques mois - et les canaux de message semblent incompatibles avec toute application de réception utilisant Visual C++ ou .NET Framework. Cela est dû au fait que .NET émet une écriture nulle sur la sortie standard, qui n'est transmise à l'application réceptrice que si un canal de message est utilisé. L'application réceptrice lit avec succès zéro octet, donc pense que c'est la fin du fichier. Le chef de projet ne semble pas considérer cela comme un vrai problème, car il ne prend apparemment pas vraiment en charge l'exécution de programmes non-Cygwin depuis Cygwin (surprise!).
Pour citer le responsable du projet Christopher Faylor à partir de plusieurs e-mails sur la liste de diffusion:
Ce que vous voyez peut être parce que Cygwin a été modifié pour utiliser des canaux de type message il y a quelques révisions. Cela ne va pas changer. Le changement a été adopté pour résoudre un problème avec les programmes Cygwin et ceux-ci sont évidemment notre priorité n ° 1.
Quel que soit le nombre de personnes qui utilisent Visual C++ ou .NET, elles ne sont vraiment pas notre public cible. C'est bien quand les choses fonctionnent pour les personnes qui ne veulent pas utiliser les outils UNIX mais qu'elles ne sont pas notre objectif principal. Résoudre les problèmes des personnes qui souhaitent utiliser des éléments non Cygwin n'est pas quelque chose que je trouve hautement prioritaire.
Depuis pipe.cc: notez que le côté écriture du tuyau est ouvert en tant que PIPE_TYPE_MESSAGE. Ceci semble pour imiter de plus près le comportement du pipe Linux et est définitivement requis pour la manipulation de pty puisque fhandler_pty_master écrit dans le pipe en morceaux, terminé par une nouvelle ligne lorsque le mode Canon est spécifié.
Le commentaire ci-dessus montre une relation "et" ici. Les canaux de type de message imitent plus étroitement le comportement des canaux Linux (UNIX) ET sont définitivement requis pour les ptys.
Je suis d'accord avec James que les temps d'exécution sont probablement buggés MAIS je suis également d'accord que cygwin devrait pouvoir gérer ces scénarios.
Votre accord complet les uns avec les autres n'aura pas beaucoup d'effet. Le code source de Cygwin n'est pas modifié par le vote.
Même si ce problème est finalement résolu d'une manière ou d'une autre - qui sait - ils pourraient casser quelque chose d'autre en 3 mois et ne pas se soucier de corriger la régression. Ils pourraient envisager un patch, mais il me faudrait un certain temps pour comprendre quelque chose qui fonctionne. Je pense que mon temps est mieux utilisé ailleurs, car il est clair qu'ils sont tout à fait disposés à rompre la compatibilité avec les applications Win32 natives et ne veulent pas perdre plus de temps à faire fonctionner les applications Win32. Je suppose donc que Cygwin ne devrait pas être considéré comme une plate-forme stable pour les environnements mixtes Win32/Cygwin - quelles sont mes alternatives? Par où dois-je commencer pour éviter une réécriture complète dans autre chose que bash? Je n'utilise pas plus que l'installation de base de Cygwin + quelques scripts Perl de base.
MISE À JOUR: Après la publication de cette question originale, ils ont finalement fait un nouveau pipe_byte flag dans la variable d'environnement CYGWIN: regardez la documentation. Si cet indicateur est défini, il résoudra le problème décrit ci-dessus. Lors de l'appel d'un programme non Cygwin Win32, toujours assurez-vous que le pipe_byte L'indicateur est défini.
Cependant, j'ai depuis découvert une incompatibilité avec .NET Framework 4.0 et Cygwin. Les versions précédentes de .NET Framework n'ont pas ce problème. J'ai mentionné le problème en premier sur la liste de diffusion Cygwin ici:
Syncronisation de canal et incompatibilité entre Cygwin et .NET Framework 4.
N'obtenant aucune réponse fructueuse, j'ai approfondi mes recherches et constaté que Cygwin crée des tuyaux qui se chevauchent, ce qui cause le problème. Notez qu'essayer d'utiliser des appels d'API Win32 non superposés avec un canal superposé n'est pas défini, et la plupart (tous?) Les programmes Win32 non Cygwin n'utilisent pas les E/S superposées avec leurs descripteurs de fichiers standard. J'ai soumis un patch qui crée un pipe_nooverlap flag dans la variable d'environnement CYGWIN qui empêche cela de se produire:
Patch pour désactiver éventuellement les canaux qui se chevauchent
Malheureusement, ils ont rejeté le correctif, vous ne le verrez donc jamais dans la DLL Cygwin principale:
Re: Patch pour désactiver éventuellement les canaux qui se chevauchent
La raison du rejet du patch:
- Il a été sous-entendu que j'ai interrompu l'implémentation du signal dans Cygwin; Je n'ai pas trouvé que c'était le cas, car les signaux utilisent toujours des tuyaux qui se chevauchent.
- Ils n'ont pas envie d'ajouter un indicateur de variable d'environnement, même si cela résout apparemment des problèmes.
- Ils ne veulent pas prendre en charge le code qui a même la possibilité d'avoir des canaux non superposés.
Avec un raisonnement et des attitudes comme celui-ci, je crains de ne pas trouver de moyen de changer le patch pour l'adapter à leurs besoins ... ils semblent déterminés à interdire l'utilisation de tuyaux non superposés. J'utilise le patch depuis un certain temps maintenant et je n'ai eu aucun problème avec. De plus, je ne peux penser à aucune situation où le pipe_nooverlap le drapeau se brisera (voir mon e-mail de suivi sur leur liste de diffusion), mais je l'ai laissé comme drapeau au cas où il y aurait des problèmes.
Par conséquent, si vous souhaitez appeler des programmes non Cygwin Win32 ou .NET Framework à partir de Cygwin, vous devez procéder comme suit:
- Appliquez mon patch à la source de la version de Cygwin que vous utilisez. Ne vous attendez pas à ce que ce correctif apparaisse dans les futures versions de Cygwin.
- Met le
pipe_byteetpipe_nooverlapdrapeaux dans la variable d'environnementCYGWIN.
Cela fonctionne ... pour l'instant !!! Je poste ceci au cas où cela aiderait quelqu'un d'autre qui souhaite encore utiliser Cygwin pour certaines choses.
La meilleure alternative que j'ai trouvée est Gow (Gnu sous Windows) .
C'est une alternative légère à Cygwin, environ 10 fois plus légère. Autant que je sache, les 130 outils installés avec Gow sont des applications Win32 normales.
Réponse 2016
J'ai construit Cash cette année, une implémentation multiplateforme de commandes Linux fonctionnant sur Node.js .
Cela prend en charge les installations globales de chaque commande dans votre path, ou un shell interactif avec prise en charge complète de la syntaxe de type bash, de la tuyauterie de commande, de la saisie semi-automatique et de l'historique.
Cela exécute également des applications win32 dans le shell.
Il peut y avoir moins de packages "pris en charge", en ce sens que vous devez installer les choses à la main, mais il n'y en aura pas:
- Problèmes de chemin (
cygpathn'est pas une solution, car vous ne pouvez pas toujours le pousser) - Programmes confondus par les packages cygwin signalant leur système d'exploitation comme "cygwin"
- .dll/.so/.lib/.a confusion
Et il existe une bien meilleure interopérabilité avec les applications Windows.
Cygnal est mon projet pour créer un Cygwin modifié, servant de bibliothèque de support d'exécution pour les applications destinées à s'exécuter en tant que programmes Windows natifs, en suivant les conventions externes familières aux utilisateurs Windows.
L'idée est que vous pouvez utiliser l'environnement Cygwin complet pour développer, en utilisant sa chaîne d'outils par défaut: le même compilateur qui rend les exécutables Cygwin. Vous pouvez ensuite déployer votre programme en tant que programme Cygnal en le regroupant avec le cygwin1.dll du projet Cygnal.
Ceci est particulièrement utile pour les programmes qui ont beaucoup de dépendances POSIX et ont besoin d'une implémentation POSIX de bonne qualité et décemment riche.
Le chef de projet ne semble pas considérer cela comme un vrai problème, car il ne prend apparemment pas vraiment en charge l'exécution de programmes non Cygwin depuis Cygwin (surprise!).
En revanche, dans le projet Cygnal, ce genre de chose est considéré comme un problème pour lequel une solution raisonnable sera fusionnée.
J'ai utilisé cygwin principalement pour la fonction de serveur X11. Il était utile d'exécuter tous les outils sur un serveur distant et d'exporter l'affichage vers cygwin local. Je trouve que je peux réaliser la même chose en utilisant le serveur Xming qui est beaucoup plus léger.