Bonjour, Tu sollicite quelques avis, voici donc le mien. Les langages se séparent en deux grandes familles selon leur technique de passage du code source au code exécutable : - Les langages compilés - les langages interprétés Les premiers sont exécutés après avoir été traduits par un COMPILATEUR (C, Pascal, Cobol, Java...) Les second sont exécutés à la volée grâce à un INTERPRÉTEUR (certains Basic, php, JavaScript...) Les commandes, qu'elles soient interactives ou par lot (script), sont évidement interprétées (perl présentant un cas particulier de compilation à la volée). Le programme qui se charge de cette exécution par interprétation des commandes se nomme un shell ou en français un INTERPRÉTEUR DE COMMANDES puisqu'il s'agit du programme qui va interpréter chaque commande (comme on parle d'un interpréteur BASIC). Je ne vois aucune discussion possible sur ce sujet de par la définition même de ces langages. Lorsqu'un programme (quel qu'il soit, à partir du moment où il est interactif) attend une réponse de la part de l'utilisateur, il affiche un symbole d'attente (>, #, :, etc.) suivit généralement d'un truc clignotant (| ou _ ). L'ensemble s'appelle, dans la terminologie informatique "l'INVITE". Ces deux composants se nomment respectivement le caractère (ou la chaîne) d'INVITE et le CURSEUR d'INVITE. Dans la terminologie américaine le mot prompt désigne parfois l'ensemble, parfois l'un des deux composants. Lorsque cette INVITE est générée par un INTERPRÉTEUR de COMMANDES, c'est qu'elle attend une commande. Il s'agit donc de "l'invite de l'interpréteur de commandes", soit en raccourci de "l'INVITE de COMMANDE" (shell prompt). Le problème du S ou pas à commandes est visiblement sujet à des variations personnelles. Enfin, s'il faut encore un argument : Imaginons qu'il existe un langage de commande qui compile les commandes au lieu de les interpréter (je ne pense pas que ça existe et surtout je n'en voit pas l'intérêt, mais imaginons). Tu parlerais bien du COMPILATEUR de COMMANDES, pas du COMPILEUR de COMMANDES. Je ne vois donc aucune raison pour parler d'un interprète de commandes. Bien cordialement Valéry Perrin Frederic Lehobey a écrit : > Salut, > > On Mon, Nov 27, 2006 at 07:21:13PM +0100, Frederic Lehobey wrote: >> On Mon, Nov 27, 2006 at 07:08:57PM +0100, Max wrote: >>> Le 27/11/06, Frederic Lehobey a écrit : >>>>> Pour en revenir à « shell » qui est traduit en « invite de commande >>>> », >>>>> je suis tombé sur un exemple ligne 1509 : >>>>> "... non-interactive shell ..." traduit en "... invite de commandes >>>>> non-interactive ..." >>>>> Cela est un contresens, puisque le mot « invite » suggère une >>>> C'est une remarque très pertinente. Je n'avais pas choisi >>>> « interprète » par hasard :-) (et je trouve que cela « coule » >>>> Le « contre-sens » ne me paraît cependant pas si flagrant (je pense >>> Je ne pense pas. Dans ce cas, en lisant dans un fichier, on >>> interprète, et il n'y a pas de notion d'invite. J'insiste sur le sens >>> d'invite qui selon moi implique une interaction avec un utilisateur, >>> donc d'une saisie de commande. >> Oui. >> >>> Donc je dirai pour résumer ma pensée : un shell est un interpréteur >>> (ou interprète si tu préfères) de commandes, et une invite de >>> commandes a pour but d'interagir avec un utilisateur pour transmettre >>> les commandes au shell. >>> >>> Désolé si je suis un peu lourd, mais là ça me paraît très inapproprié >> Je ne te trouves pas lourd du tout puisque je suis plutôt d'accord >> avec toi (en prenant interprête)... >> >>> comme traduction, et pour le man de bash c'est quand même préférable >>> de traduire au mieux le mot shell :) >> Mais j'avoue, que, pour l'avoir fait hier soir et fini ce matin, >> faire le changement à l'envers est un vrai truc pénible (à cause du >> changement de genre), donc si je dois revenir finalement à >> « interprète » (ce qui ne me dérange pas et que je suis prêt à faire), >> j'aimerais avoir auparavant plusieurs avis favorables et concordants >> de traducteurs de cette liste. Dans tous les cas, il me paraît très >> difficile de tenir le délai de *ce soir*¹ promis à Thomas (pour etch). :( > >> 1. Mais demain (soir), cela peut le faire. Encore faut-il que cela en >> vaille vraiment la peine... (Thomas ?) > > Bon c'est parti pour etch : > > http://packages.qa.debian.org/m/manpages-fr-extra/news/20061127T223208Z.html > > (Merci Thomas, pour l'empaquetage.) Reste la discussion sur la > traduction de « shell » pour l'avenir. > > À noter que je viens de découvrir d'autres utilisations de « invite > de commandes » : c'est celle retenue dans Windows XP Pro. > > Librement, > Frédéric > > PS : Dois-je envoyer un [DONE] pour les robots (je pense que oui) ? > >
Attachment:
signature.asc
Description: OpenPGP digital signature