Environnement de travail C/UNIX à l'UGA

Table des matières

Cette page décrit l'environnement de travail C/Unix en place à l'UGA et utilisé dans plusieurs UEs d'informatique et qui nécessite :

1. Machine de travail, accès aux ressources

Tout dépend de la machine sur laquelle vous travaillez : au DLST, à l'UFR IM2AG ou sur votre machine personnelle, la procedure ne sera pas forcément la même. Dans tous les cas, le travail se fera sur Turing, un serveur Linux dont l'adresse est im2ag-turing.univ-grenoble-alpes.fr.

1.1. Machine sous windows (DLST ou machine personnelle)

La connexion au serveur de travail distant se fera à l'aide d'un logiciel nommé MobaXterm. Il est déjà installé au DLST et, sur une machine personnelle, il peut s'installer simplement en allant le télécharger sur le site : https://mobaxterm.mobatek.net.

MobaXterm vous permet de vous connecter sur le serveur de travail Turing et vous offre les services suivants :

  • échange de fichiers entre la machine locale et le serveur de travail par simple drag and drop
  • terminal sur le serveur distant (interpréteur de commandes)
  • éditeur de texte pour les fichiers présents sur le serveur distant

La seule chose à faire pour commencer à utiliser MobaXterm est de configurer une nouvelle connexion ssh ayant pour nom d'hôte im2ag-turing.univ-grenoble-alpes.fr et pour nom d'utilisateur votre identifiant Agalan. Une fois connecté, vous pouvez commencer à travailler. Pour des informations plus détaillées, consultez la page dédiée à MobaXterm.

1.2. Machine sous Unix (UFR IMA2G ou machine personnelle)

Sous OSX, Linux ou tout autre UNIX, deux commandes permettent d'interagir avec le serveur : ssh et scp. Pour ces deux commandes, le nom du serveur distant pourra être de la forme : login@im2ag-turing.univ-grenoble-alpes.fr où login est à remplacer par votre identifiant Agalan. Elles s'utilisent alors comme suit :

  • ssh : se connecte sur le serveur distant indiqué en argument et lance un interpréteur. Connectez-vous sur Turing ainsi : ssh login@im2ag-turing.univ-grenoble-alpes.fr ; Pour avoir une connection permettant d'ouvrir des fenêtres, rajouter l'option -X à la ligne de commande.
  • scp : permet de copier des fichiers entre la machine locale et le serveur distant. Son utilisation est très proche de celle de cp, il suffit juste de préfixer les noms de fichiers où répertoire qui se trouvent sur la machine distante par login@im2ag-turing.univ-grenoble-alpes.fr: (avec le : et sans espaces). Par exemple, pour transférer tout le répertoire /Public/XXX_INF_Public/nouveau_TP sur votre machine il faut exécuter sur votre ordinateur : scp -r login@im2ag-turing.univ-grenoble-alpes.fr:/Public/XXX_INF_Public/nouveau_TP . (ne pas oublier le . final qui est la destination (ici, le répertoire courant)).

Il est recommandé de configurer ssh pour simplifier les commandes : voir ci dessous section 4.1.

2. Editer un fichier

MobaXterm intègre un éditeur simple avec coloration syntaxique qui est amplement suffisant pour débuter. Pour les utilisateurs plus avancés, outre la pléthore d'éditeurs de texte disponibles sur de nombreux systèmes (nano directement dans le terminal, jedit, gedit, atom, sublimetext, …), deux éditeurs se démarquent : vi et emacs. Ces deux éditeurs, bien que difficiles d'accès, offrent les avantages suivants :

  • toutes leurs fonctionnalités sont accessibles depuis le clavier ;
  • ils sont extensibles et intègrent à peu près tout ce que peut attendre un développeur (coloration syntaxique, folding, completion, snipets, …) moyennenant parfois l'installation d'un plugin ;
  • ils sont intégralement en mode textuel et disponibles sous tout UNIX, même depuis un simple terminal distant.

Ces caractéristiques en font des outils de choix dans tous les contexte où l'accès à la machine de travail est un accès distant (administration système, calcul haute performance, logiciel embarqué, …).

3. Debugger

Pour débugger un programme en C, il faut le compiler avec l'option -g, qui demande au compilateur d'inclure dans l'executable des informations permettant au débugger de faire le lien avec le code source. En l'absence de cette option, le code source et les symboles ne s'afficheront pas lors d'une session de debug.

Le débugger préconisé est la commande gdb accessible depuis le terminal. Lorsque gdb est exécuté avec le nom d'un programme comme argument il démarre une session interactive dans laquelle il est possible de débugger le programme, par exemple, à l'aide des commandes suivantes :

  • file <nom> : nom de l'exécutable à débugger (si non donné sur la ligne de commande ou si changement)
  • list <position> : affiche le code source autour de position ;
  • break <position> : place un point d'arrêt à la position donnée ;
  • break <position> if <condition> : place un point d'arrêt conditionnel (qui ne s'active que si condition est vraie) à la position donnée ;
  • info breakpoints : affiche les points d'arrêt définis ;
  • delete <numéro> : suprimme le point d'arrêt de numéro donné ;
  • run <arguments> : lance l'exécution avec les arguments donnés.

Où position peut être :

  • un numéro de ligne (dans le fichier courant)
  • un nom de fonction
  • de la forme <nom de fichier>:<numéro de ligne>

Et lorsque l'exécution de interrompue (par un break ou un signal, typiquement) :

  • next : exécute complètement la ligne courante ;
  • step : exécute la prochaine instruction (typiquement en descendant dans les appels de fonctions) ;
  • finish : exécute jusqu'à la fin de la fonction en cours ;
  • until : exécute jusqu'à la ligne qui suit (dans le code source) ;
  • continue : exécute jusqu'au prochain point d'arrêt ;
  • print <expression> : affiche la valeur d'une expression ;
  • display <expression> : affiche la valeur d'une expression et la réaffiche après chaque arrêt ;
  • info display : affiche la liste des expressions en afichage récurent ;
  • undisplay <numéro> : supprime l'affichage récurent de l'expression de numéro donné ;
  • backtrace : affiche la pile d'appels (fonctions appelées dont on n'est pas encore sorti) ;
  • up=/=down : déplacement dans la pile d'appels.

4. Autres outils utiles

Bien que non indispensables, ces quelques outils pouront vous être d'une grande aide lors du développement de vos propore programmme dans l'environnement de l'UGA.

4.1. Configuration ssh

Pour vous simplifier la vie, vous pouvez configurer une clé ssh afin de ne plus avoir besoin de saisir votre mot de passe lors d'une connexion :

  • en laissant une entrée vide lorsqu'un mot de passe vous est demandé, utilisez la commande :
    ssh-keygen <nom de ma clé> deux fichiers sont alors créés : l'un, avec l'extension .pub, contenant une clé publique, que vous pouvez diffuser librement, l'autre, contenant une clé privée, que vous devez garder secrète ou vous risquez de vous faire usurper votre identité sur les machines de l'université.
  • ajoutez votre clé publique au contenu du fichier ~/.ssh/authorized_key sur la machine distante

  • ajoutez la configuration suivante au fichier ~/.ssh/config sur la machine locale : 

    Host turing
      HostName im2ag-turing.univ-grenoble-alpes.fr
      User <login Agalan>
      IdentityFile ~/<chemin vers la clé privée>

Désormais, un simple ssh turing vous permet de vous connecter au serveur sans mot de passe, ou copier des fichiers avec scp monfichier.txt turing: Attention, votre clé privée vous permettant de vous connecter sur le serveur de l'université est stockée sur la machine locale : n'utilisez pas une machine dont vous n'êtes pas certain de la sécurité pour cela.

4.2. Address sanitiser (ASAN)

Les compilateurs gcc et clang supportent tous les deux l'option -fsanitize=address, permettant de produire un exécutable qui vérifie que ses propres accès mémoire ne sont pas en dehors de la mémoire allouée. Bien que les messages qu'il produit soit parfois difficiles à lire, il detecte des erreurs qui sont parfois difficile à reproduire ou à identifier, ainsi que les fuites mémoire.

L'alternative, l'outil valgrind, est moins puissant, car il ne dispose pas du code source, mais peut s'utiliser sur tout binaire, même lorsque le code source n'est pas disponible. Tout programme en C un tant soit peu serieux doit passer l'ASAN ou valgrind sans erreur.

4.3. indenter, linter

L'outil indent permet d'indenter un code écrit en C. Inutile de passer des heures à réindenter vos fichiers avant un rendu, regardez juste les options de indent qui correspondent à votre style et laissez l'outil faire le travail.

L'outil cppcheck détecte les erreurs de programmation les plus usuelles. Il serait dommage de rendre du code sans le vérifier alors que cela ne demande que l'exécution d'une commande.

5. VSCode

VSCode est un IDE (environnement de développement intégré) multilangages que nous déconseillons fortement pour le développement en C sous Unix. Bien que le C soit officiellement supporté, pour que VSCode puisse débugger un programme, il faut qu'il le compile lui même alors qu'il n'intègre pas d'infrastructure de construction d'un programme. Cela fonctionne pour des programmes simples constitués d'un seul fichier mais dès que le programme est découpé, c'est au développeur de gérer la compilation et d'écrire une configuration propre à VSCode en JSON pour chaque configuration d'exécution (compilation, exécutable, arguments, répertoire courant).

Dans le contexte de l'UGA, à moins d'y consacrer des efforts démesurés, il se limite donc rapidement à un simple éditeur avec terminal intégré. Les autres solutions sont alors plus intéressantes.