C'est curieux que rien ne s'affiche, ça doit vouloir dire que quelque chose échoue très tôt dans l'exécution du script. Pour pouvoir exécuter le script, il faut quand même un minimum de choses installées dans l'environnement Cygwin, dont un interpréteur Python 3 (il me semble, en tout cas "python3" est lancé avant la première ligne qui affiche quelque chose) et gcc.
https://hackspire.org/index.php/C_and_a ... troduction en liste plusieurs autres.
Transforme le
- Code: Select all
set -eu
qui est au début du script en
- Code: Select all
set -eux
, et relance le script. Ca devrait donner une indication de l'origine de l'échec.
Note que d'une manière générale, pour des raisons de performance (taux de création des processus, accès disque), tu devrais utiliser un vrai Linux (non, pas WSL2, même si j'avais vu qu'il peut gommer certaines inefficacités de Windows notamment dans les accès disque, ce dont WSL1 qui avait l'avantage de ne pas utiliser de virtualisation est incapable) ou BSD pour développer...
Pour l'exercice, je suis en train de compiler le SDK Ndless sous Cygwin sous Win10 x64 virtualisé: c'est toujours
vraiment beaucoup plus lent que sous Linux (EDIT: 2h plus tard, on n'en est toujours qu'au build de GCC), et ce n'est clairement pas seulement dû à la virtualisation. J'ai attribué 4 VCPUs à la VM, le host a 4 coeurs. C'est pour ça que j'ai abandonné Windows très tôt dans le développement de libti*/gfm/tilp, et que j'ai travaillé sur l'automatisation de la cross-compilation de GCC4TI: au fil des années, je pense que j'ai ainsi gagné du temps.
C'est aussi parce que Windows est lent pour la création de processus et les accès disque que non seulement le fuzzing de logiciels portables se fait souvent sur Linux, mais que certains morceaux de logiciels closed source ne fonctionnant que sur Windows (pro-virus MS, par exemple, par James Forshaw et. al) sont fuzzés sous Linux grâce à des couches de compatibilité / émulation.