|
|
|
Le gestionnaire du fichier avec commandes système intégrées pour systèmes Unix |
|
|
|
|
Le gestionnaire du fichier avec commandes système intégrées pour systèmes Unix |
|
Documentation technique |
|
LINUX est un système d'exploitation puissant, stable, fiable et (souvent) gratuit.
Comme les autres environnements UNIX, il est doté de nombreuses commandes de traitement des fichiers, écrites de façon a prendre des fichiers en entrée, et rendre des fichiers en sortie. Ceci permet d'associer les commandes comme on compose des fonctions mathématiques, et d'effectuer des traitements massifs et automatiques, notamment à l'aide des langages de scripts.
Ces outils sont très puissants par la variété des applications possibles qu'ils offrent. Cependant, les commandes sont nombreuses, et possèdent de nombreuses options, ce qui certes accroît leur puissance mais aussi la difficulté d'apprendre à s'en servir, ce dernier point n'est pas négligeable.
Les scripts sont intéressants pour effectuer des opérations à effectuer régulièrement, car l'écriture d'une commande peut être fastidieuse, particulièrement pour un non spécialiste.
Nous savons tous que pour le moment la grande majorité des personnes n’étant pas réellement initiées à l’informatique se tournent vers Windows, car celui ci est d’une part plus répandu et d’autre part il ne demande jamais à l’utilisateur d’écrire des fameuses lignes de commandes. Souvent l’utilisateur lambda préfère un système simple et intuitif, comme un environnement graphique par exemple, même si cela limite les possibilités dont dispose l’utilisateur.
Dans un soucis de vulgarisation, LINUX fournit aussi des environnements graphiques équipés d'outils équivalents à ceux que l'on trouve dans d'autres systèmes. Mais les fonctions proposés ne sont guère plus puissantes et surtout, elles interfacent peu les fonctionnalités des commandes du Shell.
Ce rapprochement de Linux vis à vis du " grand public " ne remet pas en cause le fait que l’utilisateur a toujours accès aux lignes de commandes sous Xterm. Il peut ainsi réaliser avec les commandes Shell ce qu'il ne peut pas faire avec son gestionnaire de fichier. En somme, l'usager est partagé entre deux mode de gestion des données: soit il sacrifie l'efficacité au profit de la convivialité (et inversement) soit il jongle avec les deux méthodes(pas très pratique!)
Par exemple actuellement, il n’y a pas à notre connaissance de gestionnaire de fichier qui permette l’utilisation de la fonction grep. Celle-ci sélectionne uniquement les fichiers ayant une chaîne de caractères voulue:
Prenons l’exemple de la ligne de commande suivante:
$ ls | grep mul qui est donc la concaténation de la fonction lister et de grep signifiant ayant la chaîne de caractère " mul " dans leur nom.
Avec GROR, il y a simplement un bouton " rechercher les fichier " " contenant le texte … " que n’importe quel utilisateur peut intuitivement utiliser sans avoir à connaître ce que sont ls et grep
GROR est le juste compromis entre le gestionnaire de fichier basic " style Windows " que l’utilisateur ne peut pas configurer et la ligne de commande si peu conviviale et réservée aux initiés.
Vous l’aurez compris GROR, est entièrement personnalisable et n’encombrera pas l’utilisateur de boutons qui ne lui servent pas. GROR contiendra uniquement les fonctions qui servent souvent et celles crées par l'utilisateur pour répondre à des besoins spécifiques. Par exemple, l'utilisateur peut créer une fonction pour compiler des fichiers sélectionnés tout en choisissant le compilateur: souplesse et gain de temps en évitant de retaper les lignes de commandes.
GROR permettra en plus de faire des traitements de masse pour une sélection de fichier, ce qui est un gain de temps.
GROR travaille aussi avec des liste de fichier. On peut donc sans problème enchaîner des actions sur les listes sans avoir à reprendre l’action au départ. Par exemple, la recherche de tous les fichiers contenant " project " dans leur nom donnera une liste, sur laquelle on pourra ensuite créer une nouvelle liste de ceux qui ont l’extension .c ou .h, etc.
GROR doit travailler en étroite relation avec l'environnement UNIX et ses fonctions systèmes. Ainsi, le langage C semble incontournable. Cependant, pour travailler en groupe et se répartir la charge de travail, un langage orienté objet paraît plus approprié. Le choix du langage C++ est donc évident. Il permet entre autre d'éviter les problèmes d'interfaçage avec les fonctions C et dispose d'un outil puissant: la STL.
a) Une certitude :quelque soit la modélisation, nous manipulons des objets Fichiers, listes de fichiers et listes de listes de fichiers. Ce dernier type d'objet permet notamment de stocker d'effectuer des opérations ensemblistes sur des listes de fichiers. Pour des raisons évidemment pratiques, les deux types de listes généralisent (de façon incomplète) la classe générique list de la STL.
b) Comment modéliser les fonctions demandées par le cahier des charges?
Nous classons les actions suivant deux critères: une classe action physique regroupe les action modifiant les propriétés, l'aspect ou le contenu du(des) fichier(s). Une classe action symbolique rassemble les actions ne modifiant pas le(s) fichier(s).
Exemple d'actions physiques: création, suppression, renommage, déplacement, remplacement d'occurrence, concaténation...
Exemple d'actions symboliques: lecture des propriétés d'un fichiers, édition, sélection, recherche d'occurrences, parcours d'arborescence...
Cette modélisation ne nous a jamais satisfait pour plusieurs raisons:
Exemple: Le tri du contenu d'un répertoire. Celui ci ne modifie pas les fichiers triés mais modifient le répertoire; or sous UNIX un répertoire est un fichier!
Exemple : Un fichier peut afficher ses propriétés. Il peut s'auto-éditer...
Elle est basée sur le principe que les lignes de commande permettent de (presque) tout faire.
Ainsi, nous créons une classe ActionSyst capable de saisir une sorte de commande UNIX paramétrée et de générer l'action correspondante sur des fichiers sélectionnées au préalable.
Ensuite, assez logiquement, nous considérons que les fonctions ensemblistes sur les listes de fichiers seront simplement des méthode de la classe ListeFichier.
Il est tentant de penser que nous implémentons une seconde ligne de commande; mais non! En effet, la commande entrée comporte des paramètres qui rendent l'instruction générique. Les paramètres indiqueraient notamment si l'action agit sur un seul fichier ou sur une (sous)liste de fichiers, si le résultat est mis dans un autre fichier... Il suffit de stocker l'action dans une liste (classe ListActionSyst) et de la réutiliser ultérieurement avec le(s) fichier(s) désiré(s). Les avantages et la puissance de cette modélisation sont considérables comme le montre la partie suivante.
GROR, au début n'a pas de fonction superflue; l'utilisateur peut ensuite le personnaliser en fonction de sa pratique, de ses envie. => personnalisation idéale.
On voit immédiatement les avantages d’un tel système: qui ne s’est jamais embêté à renommer des fichiers .TXT en .txt les uns après les autres, ou à chercher tous les *~ pour les supprimer. Avec GROR, il suffit de créer une fois pour toute la commande adéquate, puis de la lancer chaque fois que nécessaire sur une liste de fichier (comme les fichiers .TXT justement). Il suffit juste de donner " des valeurs " aux paramètres de la fonction que l'on aura crée. GROR permet donc une personnalisation unique en fonction des goûts et des besoins de l'informaticien.
De plus, en tapant des lignes de commande en mode console, nous risquons de faire des fautes de frappes ou des oublies (d’inattention) pouvant entraîner des erreurs irrécupérables… Exemple: tar cvzf mon_rep_projet/ où on oublie de stipuler le nom de l’archive tar à créer => le premier fichier du répertoire (AceFicherEstTresImportant.doc) est écrasé par le contenu compressé de tous les autres. Avec GROR, il suffit de créer une fois pour toute (ou par un tiers) et avec soin les fonctions risquées et de les rappeler sans soucis. Seuls les paramètres sont à remplir. GROR permet donc de manipuler ses données avec plus de sécurité.
Les commandes UNIX utilisées pour générer les fonctions permettent de tout faire (ou presque). Ainsi GROR est un outil très puissant et d'une évolutivité sans limite: il peut donc répondre à tout vos besoins et sera toujours au goût du jour pour gérer vos fichiers.
De plus, on peut très facilement posséder des actions performantes ou risquées même si l'on est pas un pro de la ligne de commande: il suffit se les faire faire par un ‘spécialiste’. En effet, un simple copier/coller suffit puisque le fichier de sauvegarde des actions est un fichier texte. Certaines fonctions de bases seront disponibles sur le site web de GROR. GROR s'adresse donc à un public assez large et peut permettre un apprentissage progressif des commandes UNIX.
Notons enfin qu’un bouton est bien plus agréable et bien plus rapide qu’une ligne de commande, surtout si elle est longue et compliquée !
D'un point de vue programmation, le fait de générer progressivement des fonctions grâce à la classe ActionSyst permet de coder au début un " noyau " du logiciel. Le reste des fonctions se construise peu à peu : la gain de temps est appréciable.
Au final, GROR est un gage de gain de temps, de sécurité, de personnalisation unique et surtout d'évolutivité sans limite.
Il est possible de créer des actions dangereuses. En effet, la grande liberté laissée à l'utilisateur pour personnaliser son logiciel GROR et créer ses propres actions, peut s'avérer dangereuse s'il manque de prudence.
Exemple: rien n'empêche l'utilisateur de créer la commande
rm -Rf /home/mon_login/*
Une solution peut être de créer un " dictionnaire des mots dangereux " et d'alerter l'utilisateur si un des mots de la commande apparaît dans ce dictionnaire.
Pour créer une ligne de commande, il faut posséder un minimum les rudiments des commandes UNIX (dans le cas contraire, on peut demander à un ami de créer des fonctions ou les piocher sur le site web de GROR).
NB: les inconvénients précédents se retrouvent très bien avec les simples consoles UNIX utilisées par les étudiants, les programmeurs... Ainsi, ce public est tout désigné pour profiter des nombreux avantages de GROR.
Afin de faire un code plus lisible et optimisé, nous avons choisi d'utiliser toutes les fonctionnalités offertes par la STL (Standard Template Librarie). Du fait que nous ne maîtrisions pas complètement la structure de cette bibliothèque, nous avions du mal à l'implémenter d'une manière efficace et surtout, dans un premier temps, à obtenir le résultat que nous cherchions.
Nous connaissions quelques rudiments des fonctions systèmes existants, mais notre connaissance se limitait surtout aux entrée/sortie avec les fichiers. Il nous a fallu alors trouver les fonctions nécessaires pour notamment parcourir une arborescence, lancer une commande système de manière efficace.
La programmation en utilisant plusieurs processus serait une des
améliorations les plus importantes à apporter
pour améliorer le confort d'utilisation du
logiciel. En effet, cela permettrait que le programme ne soit pas
bloqué lorsqu'une action longue vient d'être lancée,
et que l'utilisateur puisse faire autre chose pendant qu'une (voire
plusieurs) action s'exécute.
L'utilisation de barre de progression serait, elles, aussi fort utiles,
mais très difficile à implémenter. En effet,
lorsqu'un algorithme s'exécute, il est aisé de
quantifier sa progression, mais ici il s'agit d'opérations
sur des fichiers, dont la durée d'exécution est bien
moins évidente à déterminer.
Leur utilisation permettrait de récupérer la sortie d'une opération système. Par exemple, si on veut visualiser le résultat d'une recherche dans un ensemble de fichier, pour l'instant, nous sommes obligés de passer par un fichier temporaire pour y placer ce résultat, et ensuite de visualiser ce fichier avec un éditeur de texte externe.
Notre objectif principal était de faire avancer au maximum l'évolution de notre logiciel, nous n'avons donc pas investi beaucoup de temps pour améliorer la qualité de notre code en terme de rapidité d'exécution. Même si, durant toute la phase de développement, nous nous sommes attachés à produire un code lisible, commenté et efficace au maximum.
Si l'on veut que le logiciel ressemble au produit initialement désiré, il faudra bien évidemment songer à quelques améliorations. Il faudra notamment implémenter la classe EnsListeFichiers. Une instance de cette classe contiendra des listes de fichiers. Ces dernières listes seront représentées par des onglets créés durant l'utilisation du logiciel.
Voici tout d'abord une idée de l'apparence que pourrait avoir (elle dépend des modifications de l'utilisateur et du gestionnaire de fenêtres utilisé : KDE, Gnome, ...) notre logiciel au final :
Notez bien tout d'abord, qu'il s'agit ici d'un exemple. Ce logiciel a pour but d'être au maximum configurable.
Les menus "Fichier", "Utilitaires" et "Compilation" sont en
fait des menus créés par l'utilisateur, dont voici ce
que pourrait être le contenu de ces menus :
Fichiers : supprimer ; déplacer ; archiver
; renommer ; nouveau fichier ; droits ... .
Où "droits ..." est en fait un sous-menu qui
contiendrait : groupe ; propriétaire ; général (chmod).
Utilitaires : xemacs ; gimp ; xmms ; QtDesigner
Compilation : gcc -c ; javac ; java
.
On pourrait donc organiser ses actions dans des menus en cascade, un peu à la manière des signets sous netscape.
Les menus "ensembles" et "gror" sont eux, les menus par défaut. Le menu "ensembles" contient les outils permettant d'effectuer des opérations sur des listes de fichiers : Union;Intersection ; Privation. Le menu "gror" contient lui les outils pour configurer et paramétrer le logiciel : Nouvel onglet d'exploration ; Ouvrir un terminal dans le répertoire courant ; Configurer la barre de boutons ; Créer une nouvelle action ; Supprimer une action ; rafraîchir ;about .
Elle est, elle aussi, entièrement
paramétrable. L'utilisateur pourrait donc créer des
boutons à partir d'une action déjà existante et
y associer une image à choisir dans une liste où à
importer. Dans le cas présent voici la signification des boutons
utilisés :
Nouvelle Action ; Nouveau fichier ; Copier un fichier ; Supprimer un
fichier ; Privation ; Union ; Intersection ;
Compresser la sélection ; compiler la sélection ;
Ouvrir avec xemacs ; Ouvrir un terminal dans le
répertoire courant ; arrêter l'opération en
cours.
Les items soulignés sont les boutons prédéfinis, fournis avec le logiciel, mais que l'on peut tout de même retirer ou ajouter de la barre de boutons.
On va ici, distinguer deux types d'onglets :
Les onglets d'exploration classique, qui permettent une navigation dans l'arborescence. Il est possible de créer plusieurs onglets d'exploration grace au menu gror->Nouvel onglet d'exploration.
Les onglets "résultats d'actions", qui ne contiennent pas d'arborescence des répertoires, mais juste une liste de fichiers et/ou de répertoires, qui est le résultat d'une action lancée (recherche, opération ensembliste sur d'autres listes, ...).
La modélisation de GROR nous semble très prometteuse tant par les capacités de personnalisation du logiciel que par les innombrables fonctions qu'il est possible de créer. Cependant, nous n'avons pas eu le temps nécessaire de créer un produit parfaitement abouti. Nous n'avons donc pas réellement mis à l'épreuve le concept de GROR.
Ainsi, nous encourageons la reprise du projet par d'autres équipes. Pour simplifier cette poursuite, GROR dispose d'un site web au sein duquel vous trouverez un dossier complet comprenant la modélisation, une explication de l'outil graphique et du code, etc... Vous pourrez aussi télécharger les sources commentées. De plus, GROR possède une adresse e-mail pour nous contacter en cas de besoin.
Pour nous joindre:
Contact : contact@bobuse.fr.st
Dernière mise à jour : 28 janvier 2002
