Pour une ligne de commande correcte sous Windows, autant utiliser les outils GNU de http://unxutils.sourceforge.net/ , cela ne risque pas de remplacer bash si jamais c'était porté.
c'est comme Cygwin ou MinSYS ?
euh..MSYS (MinGW) pardon...
http://www.mingw.org/msys.shtml
http://www.cygwin.com/
Pour une ligne de commande correcte sous Windows, autant utiliser les
outils GNU de http://unxutils.sourceforge.net/ , cela ne risque pas de
remplacer bash si jamais c'était porté.
Pour une ligne de commande correcte sous Windows, autant utiliser les outils GNU de http://unxutils.sourceforge.net/ , cela ne risque pas de remplacer bash si jamais c'était porté.
c'est comme Cygwin ou MinSYS ?
euh..MSYS (MinGW) pardon...
http://www.mingw.org/msys.shtml
http://www.cygwin.com/
Nicolas
Pour une ligne de commande correcte sous Windows, autant utiliser les outils GNU de http://unxutils.sourceforge.net/ , cela ne risque pas de remplacer bash si jamais c'était porté.
c'est comme Cygwin ou MinSYS ?
euh..MSYS (MinGW) pardon...
http://www.mingw.org/msys.shtml
http://www.cygwin.com/
Non, c'est recodé. D'après ce que j'ai compris, Cygwin permet de linker les applis utilisant des appels système comme open(), read(), etc en mettant le portage de ces appels dans des DLL externes. Là, il est précisé "In this context, native means the executables do only depend on the Microsoft C-runtime (msvcrt.dll) and not an emulation layer like that provided by Cygwin tools.". J'imagine que fork() doit donc être remplacé dans le code par un CreateProcess(), par exemple.
Mais à l'utilisation, on ne voit pas de différence. Je n'ai pas trop testé les progs spécifiques comme mknod ou mkfifo, mais dans l'ensemble c'est utilisable pour faire des scripts et ça dépanne bien.
L'avantage par rapport à cygwin c'est également le nombre de programmes plus réduit, un package tout fait sans avoir à sélectionner à la main. Le but n'est pas de tout porter mais juste d'avoir un shell utilisable, et cela marche bien.
Nicolas.
Pour une ligne de commande correcte sous Windows, autant utiliser les
outils GNU de http://unxutils.sourceforge.net/ , cela ne risque pas de
remplacer bash si jamais c'était porté.
c'est comme Cygwin ou MinSYS ?
euh..MSYS (MinGW) pardon...
http://www.mingw.org/msys.shtml
http://www.cygwin.com/
Non, c'est recodé. D'après ce que j'ai compris, Cygwin permet de linker
les applis utilisant des appels système comme open(), read(), etc en
mettant le portage de ces appels dans des DLL externes. Là, il est
précisé "In this context, native means the executables do only depend on
the Microsoft C-runtime (msvcrt.dll) and not an emulation layer like
that provided by Cygwin tools.". J'imagine que fork() doit donc être
remplacé dans le code par un CreateProcess(), par exemple.
Mais à l'utilisation, on ne voit pas de différence. Je n'ai pas trop
testé les progs spécifiques comme mknod ou mkfifo, mais dans l'ensemble
c'est utilisable pour faire des scripts et ça dépanne bien.
L'avantage par rapport à cygwin c'est également le nombre de programmes
plus réduit, un package tout fait sans avoir à sélectionner à la main.
Le but n'est pas de tout porter mais juste d'avoir un shell utilisable,
et cela marche bien.
Pour une ligne de commande correcte sous Windows, autant utiliser les outils GNU de http://unxutils.sourceforge.net/ , cela ne risque pas de remplacer bash si jamais c'était porté.
c'est comme Cygwin ou MinSYS ?
euh..MSYS (MinGW) pardon...
http://www.mingw.org/msys.shtml
http://www.cygwin.com/
Non, c'est recodé. D'après ce que j'ai compris, Cygwin permet de linker les applis utilisant des appels système comme open(), read(), etc en mettant le portage de ces appels dans des DLL externes. Là, il est précisé "In this context, native means the executables do only depend on the Microsoft C-runtime (msvcrt.dll) and not an emulation layer like that provided by Cygwin tools.". J'imagine que fork() doit donc être remplacé dans le code par un CreateProcess(), par exemple.
Mais à l'utilisation, on ne voit pas de différence. Je n'ai pas trop testé les progs spécifiques comme mknod ou mkfifo, mais dans l'ensemble c'est utilisable pour faire des scripts et ça dépanne bien.
L'avantage par rapport à cygwin c'est également le nombre de programmes plus réduit, un package tout fait sans avoir à sélectionner à la main. Le but n'est pas de tout porter mais juste d'avoir un shell utilisable, et cela marche bien.
Nicolas.
noone
Non, c'est recodé. D'après ce que j'ai compris, Cygwin permet de linker les applis utilisant des appels système comme open(), read(), etc en mettant le portage de ces appels dans des DLL externes. Là, il est précisé "In this context, native means the executables do only depend on the Microsoft C-runtime (msvcrt.dll) and not an emulation layer like that provided by Cygwin tools.". J'imagine que fork() doit donc être remplacé dans le code par un CreateProcess(), par exemple.
Mais à l'utilisation, on ne voit pas de différence. Je n'ai pas trop testé les progs spécifiques comme mknod ou mkfifo, mais dans l'ensemble c'est utilisable pour faire des scripts et ça dépanne bien.
L'avantage par rapport à cygwin c'est également le nombre de programmes plus réduit, un package tout fait sans avoir à sélectionner à la main. Le but n'est pas de tout porter mais juste d'avoir un shell utilisable, et cela marche bien.
Nicolas.
Pour Cygwin ok pour la dépendance avec la DLL par contre pas pour MSYS il n'y en a pas
et moi MSYS ça me semble plus perreine que Unxutils notamment parce que c'est l'équipe qui gère MinGW
Non, c'est recodé. D'après ce que j'ai compris, Cygwin permet de linker
les applis utilisant des appels système comme open(), read(), etc en
mettant le portage de ces appels dans des DLL externes. Là, il est
précisé "In this context, native means the executables do only depend on
the Microsoft C-runtime (msvcrt.dll) and not an emulation layer like
that provided by Cygwin tools.". J'imagine que fork() doit donc être
remplacé dans le code par un CreateProcess(), par exemple.
Mais à l'utilisation, on ne voit pas de différence. Je n'ai pas trop
testé les progs spécifiques comme mknod ou mkfifo, mais dans l'ensemble
c'est utilisable pour faire des scripts et ça dépanne bien.
L'avantage par rapport à cygwin c'est également le nombre de programmes
plus réduit, un package tout fait sans avoir à sélectionner à la main.
Le but n'est pas de tout porter mais juste d'avoir un shell utilisable,
et cela marche bien.
Nicolas.
Pour Cygwin ok pour la dépendance avec la DLL par contre pas pour MSYS
il n'y en a pas
et moi MSYS ça me semble plus perreine que Unxutils
notamment parce que c'est l'équipe qui gère MinGW
Non, c'est recodé. D'après ce que j'ai compris, Cygwin permet de linker les applis utilisant des appels système comme open(), read(), etc en mettant le portage de ces appels dans des DLL externes. Là, il est précisé "In this context, native means the executables do only depend on the Microsoft C-runtime (msvcrt.dll) and not an emulation layer like that provided by Cygwin tools.". J'imagine que fork() doit donc être remplacé dans le code par un CreateProcess(), par exemple.
Mais à l'utilisation, on ne voit pas de différence. Je n'ai pas trop testé les progs spécifiques comme mknod ou mkfifo, mais dans l'ensemble c'est utilisable pour faire des scripts et ça dépanne bien.
L'avantage par rapport à cygwin c'est également le nombre de programmes plus réduit, un package tout fait sans avoir à sélectionner à la main. Le but n'est pas de tout porter mais juste d'avoir un shell utilisable, et cela marche bien.
Nicolas.
Pour Cygwin ok pour la dépendance avec la DLL par contre pas pour MSYS il n'y en a pas
et moi MSYS ça me semble plus perreine que Unxutils notamment parce que c'est l'équipe qui gère MinGW
