J'ai le malheur, dans dans le cadre de mon activité professionnelle, de devoir subir les affres suivantes :

  • serveurs MSWin2K (enfin y'a aussi de l'Unix, sans quoi je n'aurait rien à faire là),
  • poste de travail MSWin2K,
  • admin sur les serveurs de prod,
  • pas de mon poste de travail (je dois être comme qui dirait "dangereux" sur celui-ci).

Venant du monde Unix, et ayant passé plus d'un an avec un poste de travail sous Linux (Debian, dois-je le préciser ?), autant dire que ça a été douloureux.

Outils de base de l'unixien

Tous se trouvent là : GNU Utilities for Win32

A noter, vu que pas de droits d'admin et limitation du poste client, pas de possibilité de modifier le %PATH%. Donc, un raccourci lance un .bat qui fait bêtement un
set PATH=e:\usr\local\wbin;%PATH%
call c:\winnt\system32\cmd.exe
(avec bien évidemment e:\usr\local\wbin = l'emplacement où se trouvent les binaires des GNU Tools suite au dézippage)

=> Les joies du ls -lrt, ... enfin retrouvées !

Vim

Utilisateurs de VI, retrouvez vos repères sous Win32, grâce à Vim ! Ô joie de la coloration syntaxique, ô joie des commandes sibyllines qui font tout plein de choses, et ce sans que vous ayez besoin d'avoir un troisième tentacule !
Et surtout, exit le MSNotepad.

Perl

the Swiss-Army chainsaw of Unix programming

Je ne me vois pas bosser sans Perl pour tout ce qui est traitement de données (logs, fichiers de datas, extractions de données en base, ...), voire même petites interfaces graphiques (en Perl/Tk. C'est pas beau, mais ça marche. Sur tous les OS).

Où : récupérer le .zip (pas le .msi) chez ActiveState.
Dézipper quelque part en local, et lancer l'Installer.bat

Dans le .bat (cf plus haut) :
set PATH=e:\Perl\bin;e:\usr\local\wbin;%PATH%
call c:\winnt\system32\cmd.exe

A noter : pour pouvoir récupérer les modules packagés pour ActiveState Perl (perldoc ppm, ou voir là), il faut très certainement configurer les variables d'environnement suivantes dans le .bat :
set HTTP_proxy=http://proxy.maboite.com:8080
set HTTP_proxy_user=mon_login
set HTTP_proxy_pass=mot_de_passe

L'ActiveState Perl est fourni avec pas mal de modules ; d'autre part les repositories ActiveState sont une source importante de modules compilés pour Win32 ; enfin, deux sources supplémentaires au moins sont intéressantes :

  • BdP : http://www.bribes.org/perl/ppm (notamment pour l'indispensable PAR),
  • RothConsulting : http://www.roth.net/perl/packages (packages principalement liés à l'admin Win32).

Faire un perldoc ppm pour avoir la doc de ppm. Donc :
ppm> rep add BdP http://www.bribes.org/perl/ppm

De même, jetez un oeil là pour tout ce qui est modules DBI.

En passant, PAR est LE module indispensable : il permet de générer une archive exécutable sur toute plateforme équivalente. Typiquement, si dans un programme donné j'utilise les modules Tk, DBI & DBD::Oracle, et que je veux exécuter ce programme sur une autre machine sur laquelle il n'y a pas de Perl, PAR me permet de créer un .exe qui contient :

  • un Perl embarqué,
  • le script du programme,
  • les modules nécessaires,
  • les .dll nécessaires !

D'autre part, un perl -MCPAN -e shell permettra d'installer des modules directement depuis le miroir CPAN (voir là) le plus proche. Mais ça devient compliqué pour les modules qui ne sont pas en "Pur Perl"... À moins d'avoir un compilateur C...

minGW

minGW permet d'avoir un compilateur C (GCC), ainsi que différents outils GNU.

De quoi compiler des modules Perl en pur XS (modules qui contiennent toutes les sources du code C), modules qui nous feraient défaut, par exemple !
Un module extrêmement utile dans le cas qui nous intéresse : ExtUtils::FakeConfig

En effet, le Perl d'ActiveState est compilé avec MSVisualC, et pour ma part je n'ai pas de VisualC à ma disposition. Donc ExtUtils::fakeConfig permet de s'affranchir de ce problème. Voir là pour plus de détails.

The Gimp

Là, je le reconnais, on est plus dans l'utile que dans l'indispensable. Néanmoins, pour retravailler des copies d'écran (pour de la doc, par ex.), MSPaint ne suffit pas. J'aurai tendance à dire que MSPaint ne sert qu'à une chose : apprendre à un nouvel utilisateur (arrivant du monde GCOS ou AS/400, par exemple) à se servir d'une souris.

Donc, voir là.

A noter, dans mon cas (pas admin), les setups plantent au moment des modifications de la base de registres... Qu'à cela tienne ! On va s'en passer ! (cliquer "Ignore" à chaque fois).

Dans mon cas, j'ai donné comme cible des installations de GTK et de The Gimp respectivement les répertoires suivants :

  • E:\bin\GTK
  • E:\bin\gimp-2.2

Et donc, pour pouvoir lancer The Gimp sans soucis, il suffit d'un fichier .bat que voici :
set PATH=%PATH%;E:\bin\GTK\2.0\bin;e:\bin\gimp-2.2\bin
E:\bin\GIMP-2.2\bin\gimp-2.2.exe

D'accord, ça ouvre une fenêtre MSDOS disgrâcieuse, que l'on peut fermer aussitôt, mais... ça marche !

PsTools

Une petite voix (enfin, manière de parler. Merci Sniper !) me glisse qu'un jeu d'outils d'admin se trouve sur le site www.sysinternals.com : les PsTools. Pas d'avis pour le moment, à voir un peu plus tard.