Interface de ligne de commande

Une interface de ligne de commande ( CLI ) traite les commandes d’un programme informatique sous la forme de lignes de texte. Le programme qui gère l’interface est appelé interpréteur de ligne de commande ou processeur de ligne de commande . Les systèmes d’exploitation implémentent une interface de ligne de commande dans un shell pour un accès interactif aux fonctions ou services du système d’exploitation. Cet accès a été principalement fourni aux utilisateurs par des terminaux informatiques à partir du milieu des années 1960 et a continué à être utilisé tout au long des années 1970 et 1980 sur VAX/VMS , systèmes Unix et systèmes informatiques personnels, y compris DOS , CP/Met AppleDOS .

Capture d’écran d’un exemple de session Bash dans GNOME Terminal 3, Fedora 15 Capture d’écran de Windows PowerShell 1.0, exécuté sur Windows Vista

Aujourd’hui, de nombreux utilisateurs s’appuient sur des interfaces utilisateur graphiques et des interactions pilotées par des menus. Cependant, certaines tâches de programmation et de maintenance peuvent ne pas avoir d’Interface utilisateur graphique et peuvent toujours utiliser une ligne de commande.

Les alternatives à l’interface de ligne de commande incluent des menus d’interface utilisateur textuels (par exemple, IBM AIX SMIT ), des raccourcis clavier et diverses métaphores de bureau centrées sur le pointeur (généralement contrôlé avec une souris ). Des exemples de cela incluent Microsoft Windows, DOS Shell et Mouse Systems PowerPanel. Les interfaces de ligne de commande sont souvent implémentées dans des terminaux qui sont également capables d’interfaces utilisateur textuelles orientées écran qui utilisent l’adressage du curseur pour placer des symboles sur un écran d’affichage.

Les programmes avec des interfaces de ligne de commande sont généralement plus faciles à automatiser via des scripts .

De nombreux systèmes logiciels implémentent des interfaces de ligne de commande pour le contrôle et le fonctionnement. Cela inclut les environnements de programmation et les programmes utilitaires.

Comparaison avec les interfaces utilisateur graphiques

Une Interface utilisateur graphique avec des icônes et des fenêtres ( GEM 1.1 Desktop )

Par rapport à une Interface utilisateur graphique, une interface de ligne de commande nécessite moins de ressources système pour être implémentée. Étant donné que les options des commandes sont données en quelques caractères dans chaque ligne de commande, un utilisateur expérimenté peut souvent trouver les options plus faciles d’accès. L’automatisation des tâches répétitives est simplifiée par des mécanismes d’édition de ligne et d’historique pour stocker les séquences fréquemment utilisées ; cela peut s’étendre à un langage de script qui peut prendre des paramètres et des options variables. Un historique de la ligne de commande peut être conservé, permettant la révision ou la répétition des commandes.

Un système de ligne de commande peut nécessiter des manuels papier ou en ligne pour la référence de l’utilisateur, bien que souvent une option “aide” fournisse un examen concis des options d’une commande. L’environnement de ligne de commande peut ne pas fournir d’améliorations graphiques telles que différentes polices ou fenêtres d’édition étendues trouvées dans une interface graphique. Il peut être difficile pour un nouvel utilisateur de se familiariser avec toutes les commandes et options disponibles, par rapport aux icônes et aux menus déroulants d’une Interface utilisateur graphique, sans référence répétée aux manuels.

Les types

Interfaces de ligne de commande du système d’exploitation

CommandShell d’ Apple Computer dans A/UX 3.0.1

Les interfaces de ligne de commande du système d’exploitation (OS) sont généralement des programmes distincts fournis avec le système d’exploitation. Un programme qui implémente une telle interface texte est souvent appelé interpréteur de ligne de commande, processeur de commandes ou shell .

Des exemples d’interpréteurs de ligne de commande incluent DIGITAL Command Language (DCL) de DEC dans OpenVMS et RSX-11 , les différents shells Unix ( sh , ksh , csh , tcsh , zsh , Bash , etc.), CP/M ‘s CCP , DOS ‘ COMMAND.COM , ainsi que les programmes OS/2 et Windows cmd.exe , ces derniers groupes étant fortement basés sur RSX-11 et RSTS de DECCLI. Sous la plupart des systèmes d’exploitation, il est possible de remplacer le programme shell par défaut par des alternatives ; les exemples incluent 4DOS pour DOS, 4OS2 pour OS/2 et 4NT / Take Command pour Windows.

Bien que le terme « shell » soit souvent utilisé pour décrire un interpréteur de ligne de commande, à proprement parler, un « shell » peut être n’importe quel programme qui constitue l’interface utilisateur, y compris ceux entièrement orientés graphiquement. Par exemple, l’interface graphique Windows par défaut est un programme shell nommé EXPLORER.EXE , tel que défini dans la ligne SHELL=EXPLORER.EXE du fichier de configuration WIN.INI. Ces programmes sont des shells, mais pas des CLI.

Interfaces de ligne de commande des applications

Interface graphique de GNU Octave avec interface de ligne de commande

Les programmes d’application (par opposition aux systèmes d’exploitation) peuvent également avoir des interfaces de ligne de commande.

Un programme d’application peut prendre en charge aucun, tout ou tous ces trois principaux types de mécanismes d’interface de ligne de commande :

  • Paramètres : La plupart des systèmes d’exploitation prennent en charge un moyen de transmettre des informations supplémentaires à un programme lors de son lancement. Lorsqu’un programme est lancé à partir d’un shell de ligne de commande du système d’exploitation, le texte supplémentaire fourni avec le nom du programme est transmis au programme lancé.
  • Sessions interactives en ligne de commande : après le lancement, un programme peut fournir à un opérateur un moyen indépendant d’entrer des commandes sous forme de texte.
  • Communication inter-processus : La plupart des systèmes d’exploitation prennent en charge les moyens de communication inter-processus (par exemple, les flux standard ou les tubes nommés ). Les lignes de commande des processus client peuvent être redirigées vers un programme CLI par l’une de ces méthodes.

Certaines applications ne prennent en charge qu’une CLI, présentant une invite CLI à l’utilisateur et agissant sur les lignes de commande au fur et à mesure qu’elles sont saisies. D’autres programmes prennent en charge à la fois une CLI et une interface graphique. Dans certains cas, une interface graphique est simplement un wrapper autour d’un Fichier exécutable CLI séparé . Dans d’autres cas, un programme peut fournir une CLI comme alternative facultative à son interface graphique. Les CLI et les GUI prennent souvent en charge différentes fonctionnalités. Par exemple, toutes les fonctionnalités de MATLAB , un programme informatique d’ analyse numérique , sont disponibles via la CLI, tandis que l’interface graphique MATLAB n’expose qu’un sous-ensemble de fonctionnalités.

Les premiers jeux Sierra, tels que les trois premiers jeux King’s Quest (1984–1986), utilisaient des commandes à partir d’une ligne de commande interne pour déplacer le personnage dans la fenêtre graphique.

Histoire

L’interface de ligne de commande a évolué à partir d’une forme de dialogue autrefois menée par des humains sur des machines à téléimprimeur (TTY), dans laquelle les opérateurs humains échangeaient à distance des informations, généralement une ligne de texte à la fois. Les premiers systèmes informatiques utilisaient souvent des téléscripteurs comme moyen d’interaction avec un opérateur humain. L’ordinateur est devenu une extrémité du modèle de téléimprimeur interhumain. Ainsi, au lieu qu’un humain communique avec un autre humain via un téléimprimeur, un humain communiquait avec un ordinateur.

Le téléimprimeur mécanique a été remplacé par un “glass tty” , un clavier et un écran émulant le téléimprimeur. Les terminaux «intelligents» permettaient des fonctions supplémentaires, telles que le déplacement du curseur sur tout l’écran ou l’édition locale de données sur le terminal pour transmission à l’ordinateur. Alors que la révolution des micro -ordinateurs a remplacé l’architecture traditionnelle – mini-ordinateur + terminaux – en temps partagé , les terminaux matériels ont été remplacés par des émulateurs de terminaux – des logiciels PC qui interprétaient les signaux des terminaux envoyés via les ports série du PC.. Ceux-ci étaient généralement utilisés pour interfacer les nouveaux PC d’une organisation avec leurs mini-ordinateurs ou ordinateurs centraux existants, ou pour connecter PC à PC. Certains de ces ordinateurs exécutaient le logiciel Bulletin Board System .

Les premières CLI du système d’exploitation ont été implémentées dans le cadre des programmes de moniteurs résidents et ne pouvaient pas être facilement remplacées. La première implémentation du shell en tant que composant remplaçable faisait partie du système d’exploitation à temps partagé Multics . [1] En 1964, Louis Pouzin , membre du personnel du centre de calcul du MIT , a développé l’ outil RUNCOM pour exécuter des scripts de commande tout en permettant la substitution d’arguments. [2] Pouzin a inventé le terme « shell » pour décrire la technique d’utilisation des commandes comme un langage de programmation, et a écrit un article sur la façon de mettre en œuvre l’idée dans le système d’exploitation Multics . [3] Pouzin est retourné dans sa France natale en 1965 et le premier obus Multics a été développé par Glenda Schroeder . [2]

Interaction du shell Bourne sur la version 7 d’Unix

Le premier shell Unix , le shell V6 , a été développé par Ken Thompson en 1971 aux Bell Labs et a été calqué sur le shell Multics de Schroeder. [4] [5] L’ obus Bourne a été introduit en 1977 en remplacement de l’obus V6. Bien qu’il soit utilisé comme interpréteur de commandes interactif, il a également été conçu comme un langage de script et contient la plupart des fonctionnalités généralement considérées comme produisant des programmes structurés. Le shell Bourne a conduit au développement du shell KornShell (ksh), du shell Almquist (ash) et du populaire shell Bourne-again (ou Bash). [5]

Les premiers micro-ordinateurs eux-mêmes étaient basés sur une interface de ligne de commande telle que CP/M , DOS ou AppleSoft BASIC . Au cours des années 1980 et 1990, l’introduction d ‘ Apple Macintosh et de Microsoft Windows sur les PC a vu l’interface de ligne de commande comme interface utilisateur principale remplacée par l’ Interface utilisateur graphique . La ligne de commande est restée disponible comme interface utilisateur alternative, souvent utilisée par les administrateurs système et d’autres utilisateurs avancés pour l’administration système, la programmation informatique et le traitement par lots .

En novembre 2006, Microsoft a publié la version 1.0 de Windows PowerShell (anciennement nommée Monad ), qui combinait les fonctionnalités des shells Unix traditionnels avec leur .NET Framework propriétaire orienté objet . MinGW et Cygwin sont des packages open source pour Windows qui offrent une CLI de type Unix. Microsoft fournit le shell MKS Korn d’ implémentation ksh de MKS Inc. pour Windows via son module complémentaire Services for UNIX .

Depuis 2001, le système d’exploitation Macintosh macOS est basé sur un système d’exploitation de type Unix appelé Darwin . Sur ces ordinateurs, les utilisateurs peuvent accéder à une interface de ligne de commande de type Unix en exécutant le programme d’ émulation de terminal appelé Terminal , qui se trouve dans le sous-dossier Utilitaires du dossier Applications, ou en se connectant à distance à la machine à l’aide de ssh . Le shell Z est le shell par défaut pour macOS ; Bash, tcsh et KornShell sont également fournis. Avant macOS Catalina , Bash était la valeur par défaut.

Usage

Apprendre encore plus Cette section ne cite aucune source . ( avril 2015 ) Please help improve this section by adding citations to reliable sources. Unsourced material may be challenged and removed. (Learn how and when to remove this template message)

Une CLI est utilisée chaque fois qu’un large vocabulaire de commandes ou de requêtes, associé à une large gamme (ou arbitraire) d’options, peut être saisi plus rapidement sous forme de texte qu’avec une interface graphique pure. C’est généralement le cas avec les shells de commande du système d’exploitation . Les CLI sont également utilisées par les systèmes disposant de ressources insuffisantes pour prendre en charge une Interface utilisateur graphique. Certains systèmes de langage informatique (tels que Python , Forth , LISP , Rexx et de nombreux dialectes de BASIC ) fournissent un mode de ligne de commande interactif pour permettre une évaluation rapide du code.

Les CLI sont souvent utilisées par les programmeurs et les administrateurs système, dans les environnements d’ingénierie et scientifiques, et par les utilisateurs d’ordinateurs personnels techniquement avancés. Les CLI sont également populaires parmi les personnes ayant une déficience visuelle, car les commandes et les réponses peuvent être affichées à l’aide d’afficheurs braille actualisables .

Anatomie d’un shell CLI

Apprendre encore plus Cette section a besoin de citations supplémentaires pour vérification . ( juillet 2015 ) Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. (Learn how and when to remove this template message)

Le modèle général d’une interface de ligne de commande de système d’exploitation [6] [7] est :

Invite de commande param1 param2 param3 … paramN

  • Invite — générée par le programme pour fournir un contexte au client.
  • Commande — fournie par le client. Les commandes appartiennent généralement à l’une des trois classes suivantes :
    1. Les commandes internes sont reconnues et traitées par l’interpréteur de ligne de commande lui-même et ne dépendent d’aucun Fichier exécutable externe.
    2. Les commandes incluses exécutent des fichiers exécutables séparés généralement considérés comme faisant partie de l’environnement d’exploitation et toujours inclus avec le système d’exploitation.
    3. Les commandes externes exécutent des fichiers exécutables qui ne font pas partie du système d’exploitation de base, mais ajoutés par d’autres parties à des fins et applications spécifiques.
  • param1 …paramN — Paramètres facultatifs fournis par le client. Le format et la signification des paramètres dépendent de la commande émise. Dans le cas des commandes incluses ou externes, les valeurs des paramètres sont fournies au programme (spécifié par la commande) au fur et à mesure qu’il est lancé par l’OS. Les paramètres peuvent être Arguments ou Options .

Dans cet exemple, les délimiteurs entre les éléments de ligne de commande sont des caractères d’espacement et le délimiteur de fin de ligne est le délimiteur de retour à la ligne . Il s’agit d’une convention largement utilisée (mais pas universelle) pour les interfaces de ligne de commande.

Une CLI peut généralement être considérée comme composée d’ une syntaxe et d’ une sémantique . La syntaxe est la grammaire que toutes les commandes doivent suivre. Dans le cas des systèmes d’exploitation , DOS et Unix définissent chacun leur propre ensemble de règles que toutes les commandes doivent suivre. Dans le cas des systèmes embarqués , chaque fournisseur, tel que Nortel , Juniper Networks ou Cisco Systems , définit son propre ensemble de règles propriétaires auxquelles toutes les commandes de leur CLI se conforment. Ces règles dictent également la manière dont un utilisateur navigue dans le système de commandes. La sémantiquedéfinir quel type d’opérations sont possibles, sur quel type de données ces opérations peuvent être effectuées et comment la grammaire représente ces opérations et ces données – la signification symbolique de la syntaxe.

Deux CLI différentes peuvent s’accorder sur la syntaxe ou la sémantique, mais ce n’est que lorsqu’elles s’accordent sur les deux qu’elles peuvent être considérées comme suffisamment similaires pour permettre aux utilisateurs d’utiliser les deux CLI sans rien apprendre, ainsi que pour permettre la réutilisation des scripts. .

Une simple CLI affichera une invite, acceptera une “ligne de commande” tapée par l’utilisateur terminée par la touche Entrée , puis exécutera la commande spécifiée et fournira un affichage textuel des résultats ou des messages d’erreur. Les CLI avancées valideront, interpréteront et développeront les paramètres de la ligne de commande avant d’exécuter la commande spécifiée, et captureront ou redirigeront éventuellement sa sortie.

Contrairement à un bouton ou à un élément de menu dans une interface graphique, une ligne de commande est généralement auto-documentée, indiquant exactement ce que l’utilisateur veut faire. De plus, les lignes de commande incluent généralement de nombreuses valeurs par défaut qui peuvent être modifiées pour personnaliser les résultats. Des lignes de commande utiles peuvent être enregistrées en attribuant une chaîne de caractères ou un alias pour représenter la commande complète, ou plusieurs commandes peuvent être regroupées pour effectuer une séquence plus complexe – par exemple, compiler le programme, l’installer et l’exécuter – créant une seule entité , appelée procédure de commande ou script qui peut lui-même être traité comme une commande. Ces avantages signifient qu’un utilisateur ne doit comprendre qu’une seule fois une commande complexe ou une série de commandes, car elles peuvent être enregistrées pour être réutilisées.

Les commandes données à un shell CLI se présentent souvent sous l’une des formes suivantes :

  • doSomething how toFiles
  • doSomething how sourceFile destinationFile
  • doSomething how < inputFile > outputFile
  • doSomething how | doSomething how | doSomething how > outputFile

doSomething est, en effet, un verbe , how un adverbe (par exemple, la commande doit-elle être exécutée “verbosely” ou “silencieusement”) et toFiles un objet ou des objets (généralement un ou plusieurs fichiers) sur lesquels la commande doit agir. Le >dans le troisième exemple est un opérateur de redirection , indiquant à l’interpréteur de ligne de commande d’envoyer la sortie de la commande non pas à sa propre sortie standard (l’écran) mais au fichier nommé. Cela écrasera le fichier. Utiliser >>redirigera la sortie et l’ajoutera au fichier. Un autre opérateur de redirection est la barre verticale ( |), qui crée un pipelineoù la sortie d’une commande devient l’entrée de la commande suivante.

CLI et protection des ressources

On peut modifier l’ensemble des commandes disponibles en modifiant les chemins qui apparaissent dans la variable d’environnement PATH . Sous Unix, les commandes doivent également être marquées comme des fichiers exécutables . Les répertoires de la variable path sont recherchés dans l’ordre dans lequel ils sont donnés. En réordonnant le chemin, on peut exécuter par exemple OS2MDOSE.EXE au lieu de OS2E.EXE, alors que la valeur par défaut est l’inverse. Renommer les exécutables fonctionne également : les gens renomment souvent leur éditeur préféré en EDIT, par exemple.

La ligne de commande permet de restreindre les commandes disponibles, telles que l’accès aux commandes internes avancées. C’est ce que fait Windows cmd.exe . Souvent, les programmes shareware limitent la gamme de commandes, y compris l’impression d’une commande “votre administrateur a désactivé l’exécution des fichiers de commandes” à partir de l’invite. [ clarification nécessaire ]

Certaines CLI, telles que celles des routeurs réseau , ont une hiérarchie de modes , avec un ensemble différent de commandes prises en charge dans chaque mode. L’ensemble de commandes est regroupé par association avec la sécurité, le système, l’interface, etc. Dans ces systèmes, l’utilisateur peut parcourir une série de sous-modes. Par exemple, si la CLI avait deux modes appelés interface et system , l’utilisateur peut utiliser la commande interface pour entrer dans le mode interface. À ce stade, les commandes du mode système peuvent ne pas être accessibles jusqu’à ce que l’utilisateur quitte le mode interface et entre dans le mode système.

Invite de commande

Invite d’un BBC Micro après la mise sous tension ou la réinitialisation matérielle

Une invite de commande (ou simplement invite ) est une séquence de (un ou plusieurs) caractères utilisés dans une interface de ligne de commande pour indiquer que l’on est prêt à accepter des commandes. Il invite littéralement l’utilisateur à agir. Une invite se termine généralement par l’un des caractères $, %, #, [8] [9] : ou [10]> et inclut souvent d’autres informations, telles que le chemin du répertoire de travail actuel et le nom d’hôte .-

Sur de nombreux systèmes Unix et dérivés , l’invite se termine généralement par $ou %si l’utilisateur est un utilisateur normal, mais par #si l’utilisateur est un superutilisateur (“root” dans la terminologie Unix).

Les utilisateurs finaux peuvent souvent modifier les invites. Selon l’environnement, ils peuvent inclure des couleurs, des caractères spéciaux et d’autres éléments (comme des variables et des fonctions pour l’heure actuelle, l’utilisateur, le numéro de shell ou le répertoire de travail) afin, par exemple, de rendre l’invite plus informative ou visuellement agréable, pour distinguer les sessions sur différentes machines, ou pour indiquer le niveau actuel d’imbrication des commandes. Sur certains systèmes, des jetons spéciaux dans la définition de l’invite peuvent être utilisés pour provoquer l’appel de programmes externes par l’interpréteur de ligne de commande lors de l’affichage de l’invite.

Dans COMMAND.COM de DOS et cmd.exe de Windows NT, les utilisateurs peuvent modifier l’invite en exécutant une PROMPTcommande ou en modifiant directement la valeur de la %PROMPT% variable d’environnement correspondante . Par défaut de la plupart des systèmes modernes, le C:>style est obtenu, par exemple, avec PROMPT $P$G. La valeur par défaut des systèmes DOS plus anciens C>est obtenue uniquement par PROMPT, bien que sur certains systèmes, cela produise le C:>style le plus récent, à moins qu’il ne soit utilisé sur les lecteurs de disquette A: ou B:; sur ces systèmes PROMPT $N$Gpeut être utilisé pour remplacer la valeur par défaut automatique et passer explicitement à l’ancien style.

De nombreux systèmes Unix comportent la $PS1variable (Prompt String 1), [11] bien que d’autres variables puissent également affecter l’invite (selon le shell utilisé). Dans le shell Bash, une invite de la forme :

[ heure ] utilisateur@hôte : work_dir $

peut être défini en lançant la commande

exporter PS1 = ‘[t] u@H: W $’

Dans zsh , la $RPROMPTvariable contrôle une “invite” facultative sur le côté droit de l’écran. Il ne s’agit pas d’une véritable invite dans la mesure où l’emplacement de la saisie de texte ne change pas. Il est utilisé pour afficher des informations sur la même ligne que l’invite, mais justifiées à droite.

Dans RISC OS , l’invite de commande est un *symbole, et donc les commandes CLI (OS) sont souvent appelées “commandes étoiles”. [12] On peut également accéder aux mêmes commandes à partir d’autres lignes de commande (comme la ligne de commande BBC BASIC ), en faisant précéder la commande d’un *.

Arguments

Une ligne de commande MS-DOS, illustrant l’analyse en commande et arguments

Un argument ou paramètre de ligne de commande est un élément d’information fourni à un programme lors de son démarrage. Un programme peut avoir de nombreux arguments de ligne de commande qui identifient des sources ou des destinations d’informations, ou qui modifient le fonctionnement du programme.

Lorsqu’un processeur de commandes est actif, un programme est généralement appelé en tapant son nom suivi d’arguments de ligne de commande (le cas échéant). Par exemple, dans les environnements Unix et de type Unix , un exemple d’argument de ligne de commande est :

rm fichier.s

“file.s” est un argument de ligne de commande qui indique au programme rm de supprimer le fichier “file.s”.

Certains langages de programmation, tels que C , C++ et Java , permettent à un programme d’interpréter les arguments de la ligne de commande en les traitant comme des paramètres de chaîne dans la fonction main . D’autres langages, tels que Python , exposent une API (fonctionnalité) spécifique au système d’exploitation via sys module , et en particulier sys.argvpour les “arguments de ligne de commande”.

Dans les systèmes d’exploitation de type Unix , un seul trait d’union utilisé à la place d’un nom de fichier est une valeur spéciale spécifiant qu’un programme doit gérer les données provenant de l’ entrée standard ou envoyer des données à la sortie standard .

Option de ligne de commande

Une option de ligne de commande ou simplement une option (également connue sous le nom de flag ou switch ) modifie le fonctionnement d’une commande ; l’effet est déterminé par le programme de la commande. Les options suivent le nom de la commande sur la ligne de commande, séparés par des espaces. Un espace avant la première option n’est pas toujours requis, comme Dir/?et DIR /?sous DOS, qui ont le même effet [10] de lister les options disponibles de la commande DIR, alors que dir –help(dans de nombreuses versions d’Unix) nécessite que l’option soit précédée de au moins un espace (et est sensible à la casse).

Le format des options varie considérablement d’un système d’exploitation à l’autre. Dans la plupart des cas, la syntaxe est une convention plutôt qu’une exigence du système d’exploitation ; la ligne de commande entière est simplement une chaîne transmise à un programme, qui peut la traiter comme le programmeur le souhaite, tant que l’interpréteur peut dire où se termine le nom de la commande et où commencent ses arguments et ses options.

Quelques exemples représentatifs d’options de ligne de commande, toutes liées à la liste des fichiers dans un répertoire, pour illustrer certaines conventions :

Système opérateur Commande Alternative valide Remarques
OpenVMS directory/owner Dir /Owner demandez à la commande de répertoire d’afficher également la propriété des fichiers.
Notez que le nom de la commande Directory n’est pas sensible à la casse et peut être abrégé en aussi peu de lettres que nécessaire pour rester unique.
les fenêtres DIR/Q/O:S d* dir /q d* /o:s affiche la propriété des fichiers dont le nom commence par “D”, triés par taille, le plus petit en premier.
Notez que les espaces autour de l’argument d* sont obligatoires.
Systèmes de type Unix ls -lS D* ls -S -l D* afficher dans les fichiers et répertoires au format long commençant par “D” (mais pas “d”), triés par taille (le plus grand en premier).
Notez que des espaces sont requis autour de tous les arguments et options, mais certains peuvent être exécutés ensemble, par exemple -lS est identique à -l -S .
Données RDOS générales CLI list/e/s 04-26-80/b List /S/E 4-26-80/B répertorie tous les attributs des fichiers créés avant le 26 avril 1980.
Notez que le /B à la fin de l’argument date est un commutateur local , qui modifie la signification de cet argument, tandis que /S et /E sont des commutateurs globaux , c’est-à-dire s’appliquent à l’ensemble commande.

Commandes abrégées

Dans Multics , les options de ligne de commande et les mots clés du sous-système peuvent être abrégés. Cette idée semble provenir du langage de programmation PL/I , avec ses mots-clés raccourcis (par exemple, STRG pour STRINGRANGE et DCL pour DECLARE). Par exemple, dans le sous-système “forum” Multics, le paramètre -long_subject peut être abrégé -lgsj . Il est également courant que les commandes Multics soient abrégées, correspondant généralement aux lettres initiales des mots qui sont enchaînées avec des traits de soulignement pour former des noms de commande, comme l’utilisation de did pour delete_iacl_dir .

Dans certains autres systèmes, les abréviations sont automatiques, comme permettre suffisamment de premiers caractères d’un nom de commande pour l’identifier de manière unique (comme SUune abréviation pour SUPERUSER) tandis que d’autres peuvent avoir des abréviations spécifiques préprogrammées (par exemple MDpour MKDIRdans COMMAND.COM) ou défini par l’utilisateur via des scripts batch et des alias (par exemple alias md mkdirdans tcsh ).

Conventions d’options sous DOS, Windows, OS/2

Sous DOS, OS/2 et Windows, différents programmes appelés depuis leur COMMAND.COM ou cmd.exe (ou leurs commandes internes) peuvent utiliser une syntaxe différente dans le même système d’exploitation. Par example:

  • Les options peuvent être indiquées par l’un ou l’autre des « caractères de commutation » : /, -, ou l’un ou l’autre peut être autorisé. Voir ci-dessous.
  • Ils peuvent ou non être sensibles à la casse .
  • Parfois, les options et leurs arguments sont exécutés ensemble, parfois séparés par des espaces, et parfois par un caractère, généralement :ou= ; ainsi Prog -fFilename, Prog -f Filename, Prog -f:Filename, Prog -f=Filename.
  • Certains programmes permettent de combiner des options à caractère unique ; [10] d’autres non. Le commutateur -fApeut signifier la même chose que -f -A, [10] ou il peut être incorrect, ou il peut même s’agir d’un paramètre valide mais différent.

Sous DOS , OS/2 et Windows , la barre oblique ( /) est la plus courante, bien que le tiret moins soit également parfois utilisé. Dans de nombreuses versions de DOS (MS-DOS/PC DOS 2.xx et supérieur, toutes les versions de DR-DOS depuis 5.0, ainsi que PTS-DOS , Embedded DOS , FreeDOS et RxDOS ) le caractère switch (parfois abrégé switchar ou switchchar ) à utiliser est défini par une valeur renvoyée par un appel système ( INT 21h /AX=3700h). Le caractère par défaut renvoyé par cette API est/, mais peut être remplacé par un tiret moins sur les systèmes mentionnés ci-dessus, sauf sous Datalight ROM-DOS et MS-DOS/PC DOS 5.0 et supérieur, qui reviennent toujours /de cet appel (à moins que l’un des nombreux TSR disponibles pour réactiver la fonction SwitChar est chargée). Dans certains de ces systèmes (MS-DOS/PC DOS 2.xx, DOS Plus 2.1, DR-DOS 7.02 et supérieur, PTS-DOS, Embedded DOS, FreeDOS et RxDOS), le paramètre peut également être préconfiguré par un SWITCHAR directive dans CONFIG.SYS . Embedded DOS de General Software fournit une commande SWITCH dans le même but, tandis que 4DOS permet de modifier le paramètre via SETDOS /W:n. [13] Sous DR-DOS, si le réglage a été modifié de/, le premier séparateur de répertoire dans l’affichage du paramètre PROMPT$G se transforme en une barre oblique /(qui est également un séparateur de répertoire valide sous DOS, FlexOS, 4680 OS, 4690 OS, OS/2 et Windows) servant ainsi d’indice visuel pour indiquer le changement. [10] En outre, le réglage actuel est également reflété dans les écrans d’aide intégrés. [10] Certaines versions de DR-DOS COMMAND.COM prennent également en charge un jeton PROMPT $/pour afficher le paramètre actuel. COMMAND.COM depuis DR-DOS 7.02 fournit également une pseudo-variable d’environnement nommée %/%pour permettre l’écriture de travaux par lots portables. [14] [15]Plusieurs commandes DR-DOS externes prennent également en charge une variable d’environnement %SWITCHAR% pour remplacer le paramètre système.

Cependant, de nombreux programmes sont câblés pour être utilisés /uniquement, plutôt que de récupérer le paramètre du commutateur avant d’analyser les arguments de la ligne de commande. Un très petit nombre, principalement des ports de systèmes de type Unix, sont programmés pour accepter “-” même si le caractère de commutation n’y est pas défini (par exemple netstatet ping, fourni avec Microsoft Windows , acceptera l’option /? pour lister les options disponibles , et pourtant la liste spécifiera la convention “-“).

Conventions d’options dans les systèmes de type Unix

Apprendre encore plus Cette section a besoin de citations supplémentaires pour vérification . ( juillet 2021 ) Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. (Learn how and when to remove this template message)

Dans les systèmes de type Unix, le trait d’union ASCII -moins commence les options ; la nouvelle (et GNU ) convention est d’utiliser deux traits d’union puis un mot (par exemple –create) pour identifier l’utilisation de l’option tandis que l’ancienne convention (et toujours disponible en option pour les options fréquemment utilisées) consiste à utiliser un trait d’union puis une lettre (par exemple , -c); si un trait d’union est suivi de deux lettres ou plus, cela peut signifier que deux options sont spécifiées, ou cela peut signifier que la deuxième lettre et les suivantes sont un paramètre (tel que le nom de fichier ou la date) pour la première option. [16]

Deux caractères tiret moins sans lettres suivantes ( –) peuvent indiquer que les arguments restants ne doivent pas être traités comme des options, ce qui est utile par exemple si un nom de fichier lui-même commence par un trait d’union, ou si d’autres arguments sont destinés à une commande interne (par exemple , sudo ). Des doubles traits d’union-moins sont également parfois utilisés pour préfixer les “options longues” là où des noms d’options plus descriptifs sont utilisés. C’est une caractéristique commune des logiciels GNU . La fonction et le programme getopt, ainsi que la commande getopts sont généralement utilisés pour analyser les options de ligne de commande.

Les noms de commande, les arguments et les options Unix sont sensibles à la casse (sauf dans quelques exemples, principalement lorsque des commandes populaires d’autres systèmes d’exploitation ont été portées sur Unix).

Conventions d’options dans d’autres systèmes

Utilisation de FlexOS , 4680 OS et 4690 OS- .

CP/M généralement utilisé [.

Conversational Monitor System (CMS) utilise une seule parenthèse gauche pour séparer les options à la fin de la commande des autres arguments. Par exemple, dans la commande suivante, les options indiquent que le fichier cible doit être remplacé s’il existe, et la date et l’heure du fichier source doivent être conservées sur la copie :COPY source file a target file b (REPLACE OLDDATE

La CLI de Data General sous leurs systèmes d’exploitation RDOS , AOS , etc. , ainsi que la version de CLI fournie avec leur Business Basic , utilise uniquement /comme caractère de commutateur, est insensible à la casse et autorise les “commutateurs locaux” sur certains arguments pour contrôler la façon dont ils sont interprétés, comme MAC/U LIB/S A B C $LPT/Ll’option globale “U” à la commande de macro assembleur pour ajouter des symboles utilisateur, mais deux commutateurs locaux, l’un pour spécifier LIB doivent être ignorés lors de la passe 2 et l’autre pour diriger la liste vers l’imprimante, $LPT.

Aide à l’utilisation intégrée

L’une des critiques d’une CLI est le manque d’indices pour l’utilisateur quant aux actions disponibles. [ citation nécessaire ] En revanche, les interfaces graphiques informent généralement l’utilisateur des actions disponibles avec des menus, des icônes ou d’autres repères visuels. [ citation nécessaire ] Pour surmonter cette limitation, de nombreux programmes CLI affichent un bref résumé de ses paramètres valides, généralement lorsqu’ils sont invoqués sans arguments ou l’un des ?, -?, -h, -H, /?, /h, /H, /Help, -help, ou –help. [10] [17] [18]

Cependant, entrer un nom de programme sans paramètres dans l’espoir qu’il affichera une aide à l’utilisation peut être dangereux, car les programmes et les scripts pour lesquels les arguments de ligne de commande sont facultatifs s’exécuteront sans préavis.

Bien que souhaitable au moins pour le paramètre d’aide, les programmes peuvent ne pas prendre en charge tous les caractères d’entrée d’option illustrés ci-dessus. Sous DOS, où le caractère d’option de ligne de commande par défaut peut être modifié de /à -, les programmes peuvent interroger l’ API SwitChar afin de déterminer le paramètre actuel. Ainsi, si un programme n’est pas câblé pour les prendre en charge tous, un utilisateur peut avoir besoin de connaître le paramètre actuel même pour pouvoir demander de l’aide de manière fiable. Si le SwitChar a été remplacé par -et que le /caractère est donc accepté comme délimiteur de chemin alternatif également sur la ligne de commande DOS, les programmes peuvent mal interpréter des options comme /hou /Hcomme des chemins plutôt que des paramètres d’aide. [dix]Cependant, s’il est donné comme premier ou unique paramètre, la plupart des programmes DOS l’accepteront, par convention, comme demande d’aide, quel que soit le paramètre SwitChar actuel. [10] [13]

Dans certains cas, différents niveaux d’aide peuvent être sélectionnés pour un programme. Certains programmes prenant en charge cela permettent de donner un niveau de verbosité comme argument facultatif au paramètre d’aide (comme dans /H:1, /H:2, etc.) ou ils donnent juste une courte aide sur les paramètres d’aide avec un point d’interrogation et un écran d’aide plus long pour les autres options d’aide. [19]

Selon le programme, une aide supplémentaire ou plus spécifique sur les paramètres acceptés est parfois disponible en fournissant le paramètre en question comme argument du paramètre d’aide ou vice versa (comme dans /H:Wou dans /W:?(en supposant /Wqu’il y aurait un autre paramètre pris en charge par le programme)) . [20] [21] [18] [17] [19] [nb 1]

De la même manière que le paramètre d’aide, mais beaucoup moins courant, certains programmes fournissent des informations supplémentaires sur eux-mêmes (comme le mode, le statut, la version, l’auteur, la licence ou les informations de contact) lorsqu’ils sont invoqués avec un paramètre “à propos” comme -!, /!, -aboutou –about. [17]

Étant donné que les caractères ?et !servent généralement à d’autres fins sur la ligne de commande, ils peuvent ne pas être disponibles dans tous les scénarios. Par conséquent, ils ne doivent pas être les seules options pour accéder aux informations d’aide correspondantes.

La fin de la sortie de la commande HELP du RT-11SJ affichée sur un VT100

Si une aide plus détaillée est nécessaire que celle fournie par l’aide interne intégrée d’un programme, de nombreux systèmes prennent en charge une commande externe ” ” dédiée (ou similaire), qui accepte un nom de commande comme paramètre d’appel et invoquera un système d’aide externe.help command

Dans la famille DR-DOS, taper /?ou /Hà l’ invite COMMAND.COM au lieu d’une commande elle-même affichera une liste générée dynamiquement des commandes internes disponibles ; [10] 4DOS et NDOS prennent en charge la même fonctionnalité en tapant ?à l’invite [13] (qui est également acceptée par les nouvelles versions de DR-DOS COMMAND.COM) ; les commandes internes peuvent être désactivées ou réactivées individuellement via SETDOS /I. [13] En plus de cela, certaines versions plus récentes de DR-DOS COMMAND.COM acceptent également une ?%commande pour afficher une liste de pseudo-variables d’environnement intégrées disponibles. Outre leur objectif de référence d’aide rapide, cela peut être utilisé dans les travaux par lots pour interroger les fonctionnalités du processeur de ligne de commande sous-jacent. [dix]

Syntaxe de la description de la commande

L’ aide à l’utilisation intégrée et les pages de manuel utilisent généralement une petite syntaxe pour décrire la forme de commande valide : [22] [23] [24] [nb 2]

  • crochets angulaires pour les paramètres requis :ping <hostname>
  • crochets pour les paramètres facultatifs :mkdir [-p] <dirname>
  • points de suspension pour les éléments répétés :cp <source1> [source2…] <dest>
  • barres verticales pour le choix des articles :netstat {-t|-u}

Notez que ces caractères ont des significations différentes que lorsqu’ils sont utilisés directement dans le shell. Les chevrons peuvent être omis lorsqu’il est peu probable que le nom du paramètre soit confondu avec une chaîne littérale.

Le personnage de l’espace

Dans de nombreux domaines de l’informatique, mais particulièrement dans la ligne de commande, le caractère espace peut poser des problèmes car il a deux fonctions distinctes et incompatibles : en tant que partie d’une commande ou d’un paramètre, ou en tant que paramètre ou séparateur de nom . L’ambiguïté peut être évitée soit en interdisant les espaces intégrés dans les noms de fichiers et de répertoires en premier lieu (par exemple, en les remplaçant par des traits de soulignement _ ), soit en entourant un nom avec des espaces intégrés entre guillemets ou en utilisant un caractère d’échappement avant l’espace, généralement une barre oblique inverse ( ). Par example

Long path/Long program name Parameter one Parameter two…

est ambigu (le “nom du programme” fait-il partie du nom du programme, ou de deux paramètres ? ); pourtant

Long_path/Long_program_name Parameter_one Parameter_two…, LongPath/LongProgramName ParameterOne ParameterTwo…, “Long path/Long program name” “Parameter one” “Parameter two”…

et

Long path/Long program name Parameter one Parameter two…

ne sont pas ambigus. Les systèmes d’exploitation basés sur Unix minimisent l’utilisation des espaces intégrés pour minimiser le besoin de guillemets. Dans Microsoft Windows , il faut souvent utiliser des guillemets car les espaces intégrés (comme dans les noms de répertoire) sont courants.

Interpréteur de ligne de commande

Bien que la plupart des utilisateurs considèrent le shell comme un interpréteur de commandes interactif, il s’agit en réalité d’un langage de programmation dans lequel chaque instruction exécute une commande. Parce qu’il doit satisfaire à la fois les aspects interactifs et de programmation de l’exécution des commandes, c’est un langage étrange, façonné autant par l’histoire que par la conception.

– Brian W. Kernighan et Rob Pike [25]

Le terme interpréteur de ligne de commande ( CLI ) s’applique aux programmes informatiques conçus pour interpréter une séquence de lignes de texte pouvant être saisies par un utilisateur, lues à partir d’un fichier ou d’un autre type de flux de données . Le contexte d’interprétation est généralement celui d’un système d’exploitation ou d’ un langage de programmation donné .

Les interpréteurs de ligne de commande permettent aux utilisateurs d’émettre diverses commandes de manière très efficace (et souvent concise). Cela nécessite que l’utilisateur connaisse les noms des commandes et leurs paramètres, ainsi que la syntaxe du langage interprété.

Le mécanisme Unix #!et la commande OS/2 EXTPROC facilitent le passage des fichiers batch aux processeurs externes. On peut utiliser ces mécanismes pour écrire des processeurs de commandes spécifiques pour des usages dédiés, et traiter des fichiers de données externes qui résident dans des fichiers batch.

De nombreuses interfaces graphiques, telles que le gestionnaire de présentation OS / 2 et les premières versions de Microsoft Windows, utilisent des lignes de commande pour appeler des programmes d’assistance afin d’ouvrir des documents et des programmes. Les commandes sont stockées dans le shell graphique [ clarification nécessaire ] ou dans des fichiers comme le registre ou le fichier OS/2 OS2USER.INI .

Histoire ancienne

Un clavier de téléimprimeur Teletype Model 33 ASR avec lecteur de bande perforée et poinçon Borne DEC VT52

Les premiers ordinateurs ne prenaient pas en charge les périphériques d’entrée/sortie interactifs, s’appuyant souvent sur des interrupteurs de détection et des voyants pour communiquer avec l’ opérateur de l’ordinateur . Cela était suffisant pour les systèmes par lots qui exécutaient un programme à la fois, souvent avec le programmeur agissant comme opérateur. Cela présentait également l’avantage d’une faible surcharge, car les lumières et les interrupteurs pouvaient être testés et réglés avec une seule instruction machine. Plus tard, une console système unique a été ajoutée pour permettre à l’opérateur de communiquer avec le système.

À partir des années 1960, l’interaction de l’utilisateur avec les ordinateurs se faisait principalement au moyen d’ interfaces de ligne de commande , initialement sur des machines comme le Teletype Model 33 ASR , mais ensuite sur les premiers terminaux informatiques basés sur CRT tels que le VT52 .

Tous ces appareils étaient purement textuels, sans possibilité d’afficher des graphiques ou des images. [nb 3] Pour les programmes d’application métier, des menus textuels ont été utilisés, mais pour une interaction plus générale, la ligne de commande était l’interface.

Vers 1964 , Louis Pouzin a introduit le concept et le nom shell dans Multics , en s’appuyant sur des installations antérieures et plus simples du système de Partage de temps compatible (CTSS). [26] [ meilleure source nécessaire ]

Depuis le début des années 1970, le système d’exploitation Unix a adapté le concept d’un puissant environnement de ligne de commande et a introduit la possibilité de diriger la sortie d’une commande comme entrée vers une autre. Unix avait également la capacité d’enregistrer et de réexécuter des chaînes de commandes en tant que ” scripts shell ” qui agissaient comme des commandes personnalisées.

La ligne de commande était également l’interface principale des premiers ordinateurs personnels tels que le Commodore PET , Apple II et BBC Micro – presque toujours sous la forme d’un interpréteur BASIC . Lorsque des micro-ordinateurs plus puissants à vocation commerciale sont arrivés avec des ordinateurs CP / M et plus tard DOS tels que l’ IBM PC , la ligne de commande a commencé à emprunter une partie de la syntaxe et des fonctionnalités des shells Unix telles que la globalisation et la canalisation de la sortie.

La ligne de commande a d’abord été sérieusement remise en question par l’ approche PARC GUI utilisée dans l’ Apple Lisa de 1983 et l’ Apple Macintosh de 1984 . Quelques utilisateurs d’ordinateurs ont utilisé des interfaces graphiques telles que GEOS et Windows 3.1 , mais la majorité des utilisateurs d’ IBM PC n’ont pas remplacé leur shell COMMAND.COM par une interface graphique avant la sortie de Windows 95 en 1995. [27] [28]

Utilisation moderne en tant que shell de système d’exploitation

Alors que la plupart des utilisateurs d’ordinateurs non experts utilisent désormais presque exclusivement une interface graphique, les utilisateurs plus avancés ont accès à de puissants environnements de ligne de commande :

  • Le shell de commande VAX/VMS par défaut, utilisant le langage DCL , a été porté sur des systèmes Windows au moins trois fois, y compris PC-DCL et Acceler8 DCL Lite. Les shells de commande Unix ont été portés sur les types de systèmes d’exploitation VMS et DOS / Windows 95 et Windows NT.
  • COMMAND.COM est l’interpréteur de ligne de commande de MS-DOS , IBM PC DOS et des clones tels que DR-DOS , SISNE plus , PTS-DOS , ROM-DOS et FreeDOS .
  • Le kit de ressources Windows et les services Windows pour UNIX incluent les shells Korn et Bourne ainsi qu’un interpréteur Perl (les services pour UNIX contiennent ActiveState ActivePerl dans les versions ultérieures et Interix pour les versions 1 et 2 et un shell compilé par Microsoft)
  • IBM OS/2 (et ses dérivés tels que eComStation et ArcaOS ) possède le processeur cmd.exe . Cela copie les commandes COMMAND.COM , avec des extensions à REXX .
  • cmd.exe fait partie du flux Windows NT des systèmes d’exploitation.
  • Encore un autre cmd.exe est un shell simplifié pour Windows CE 3.0.
  • Un interpréteur de type MS-DOS appelé PocketDOS a été porté sur les machines Windows CE ; la version la plus récente est presque identique à MS-DOS 6.22 et peut également exécuter Windows 1, 2 et 3.0, QBasic et d’autres outils de développement, 4NT et 4DOS. La dernière version comprend plusieurs shells, à savoir MS-DOS 6.22, PC DOS 7, DR DOS 3.xx et autres.
  • Les utilisateurs Windows peuvent utiliser l’ interface CScript pour alterner les programmes, à partir de la ligne de commande. PowerShell fournit une interface de ligne de commande, mais ses applets ne sont pas écrites en script Shell . Des implémentations du shell Unix sont également disponibles dans le cadre du sous-système POSIX , [29] Cygwin , MKS Toolkit , UWIN , Hamilton C shell et d’autres progiciels. Les shells disponibles pour ces outils d’interopérabilité incluent csh , ksh , sh , Bash , rsh , tclsh et moins fréquemment zsh, psh
  • Les implémentations de PHP ont un shell pour une utilisation interactive appelé php-cli.
  • Tcl/Tk standard a deux shells interactifs, Tclsh et Wish, ce dernier étant la version graphique.
  • Python , Ruby , Lua , XLNT et d’autres interpréteurs ont également des shells de commande pour une utilisation interactive.
  • FreeBSD utilise tcsh comme shell interactif par défaut pour le superutilisateur et ash comme shell de script par défaut.
  • De nombreuses distributions Linux ont l’implémentation Bash du shell Unix .
  • Apple macOS et certaines distributions Linux utilisent zsh . Auparavant, macOS utilisait tcsh et Bash.
  • Les périphériques Linux embarqués (et d’autres périphériques embarqués de type Unix ) utilisent souvent l’ implémentation Ash du shell Unix, dans le cadre de Busybox .
  • Android utilise le shell mksh , [30] [31] qui remplace un shell dérivé de ash [32] qui était utilisé dans les anciennes versions d’Android, complété par des commandes du binaire séparé de la boîte à outils [33] .
  • Les routeurs avec Cisco IOS , [34] Junos [35] et bien d’autres sont généralement configurés à partir de la ligne de commande.
  • Le système d’exploitation Plan 9 utilise le shell rc dont la conception est similaire au shell Bourne .

Script

La plupart des interpréteurs de ligne de commande prennent en charge les scripts , à des degrés divers. (Ils sont, après tout, des interprètes d’un langage de programmation interprété , bien que dans de nombreux cas, le langage soit unique à l’interpréteur de ligne de commande particulier.) Ils interpréteront des scripts (diversement appelés scripts shell ou fichiers batch ) écrits dans le langage qu’ils interpréter. Certains interpréteurs de ligne de commande intègrent également les moteurs d’interprétation d’autres langages, tels que REXX , en plus du leur, permettant l’exécution de scripts, dans ces langages, directement dans l’interpréteur de ligne de commande lui-même.

À l’inverse, les langages de programmation de scripts , en particulier ceux dotés d’une fonction eval (tels que REXX, Perl , Python , Ruby ou Jython ), peuvent être utilisés pour implémenter des interpréteurs et des filtres de ligne de commande. Pour quelques systèmes d’exploitation , notamment DOS , un tel interpréteur de commandes fournit une interface de ligne de commande plus flexible que celle fournie. Dans d’autres cas, un tel interpréteur de commandes peut présenter une interface utilisateur hautement personnalisée utilisant l’interface utilisateur et les fonctionnalités d’entrée/sortie du langage.

Autres interfaces de ligne de commande

La ligne de commande fournit une interface entre les programmes ainsi que l’utilisateur. En ce sens, une ligne de commande est une alternative à une boîte de dialogue . Les éditeurs et les bases de données présentent une ligne de commande, dans laquelle d’autres processeurs de commande peuvent s’exécuter. D’un autre côté, on peut avoir des options sur la ligne de commande, qui ouvre une boîte de dialogue. La dernière version de ‘Take Command’ a cette fonctionnalité. DBase a utilisé une boîte de dialogue pour construire des lignes de commande, qui pourraient être modifiées avant utilisation.

Des programmes tels que BASIC, diskpart , Edlin et QBASIC fournissent tous des interfaces de ligne de commande, dont certaines utilisent le shell système. Basic est calqué sur l’interface par défaut des ordinateurs Intel 8 bits. Les calculatrices peuvent être exécutées en tant qu’interfaces de ligne de commande ou de dialogue.

Emacs fournit une interface de ligne de commande sous la forme de son mini-tampon. Les commandes et les arguments peuvent être saisis à l’aide du support d’édition de texte standard d’Emacs, et la sortie est affichée dans un autre tampon.

Il existe un certain nombre de jeux en mode texte, comme Adventure ou King’s Quest 1-3 , qui reposaient sur la saisie de commandes par l’utilisateur en bas de l’écran. On contrôle le personnage en tapant des commandes comme ‘get ring’ ou ‘look’. Le programme renvoie un texte qui décrit la façon dont le personnage le voit ou réalise l’action. L’ aventure textuelle The Hitchhiker’s Guide to the Galaxy , une fiction interactive basée sur le livre du même nom de Douglas Adam , est un jeu en ligne de commande de style télétype.

La plus notable de ces interfaces est l’ interface de flux standard, qui permet de transmettre la sortie d’une commande à l’entrée d’une autre. Les fichiers texte peuvent également servir l’un ou l’autre objectif. Cela fournit les interfaces de tuyauterie, de filtres et de redirection. Sous Unix, les périphériques sont aussi des fichiers, donc le type de fichier normal pour le shell utilisé pour stdin, stdout et stderr est un fichier de périphérique tty .

Une autre interface de ligne de commande permet à un programme shell de lancer des programmes d’assistance, soit pour lancer des documents, soit pour démarrer un programme. La commande est traitée en interne par le shell, puis transmise à un autre programme pour lancer le document. L’interface graphique de Windows et d’OS/2 s’appuie fortement sur les lignes de commande transmises à d’autres programmes – console ou graphique, qui traitent ensuite généralement la ligne de commande sans présenter de console utilisateur.

Des programmes comme l’éditeur OS/2 E et certains autres éditeurs IBM peuvent traiter des lignes de commande normalement destinées au shell, la sortie étant placée directement dans la fenêtre du document.

Le champ de saisie d’URL d’un navigateur Web peut être utilisé comme ligne de commande. Il peut être utilisé pour “lancer” des applications Web , accéder à la configuration du navigateur et effectuer une recherche. Google , qui a été appelé “la ligne de commande d’Internet”, effectuera une recherche spécifique à un domaine lorsqu’il détectera des paramètres de recherche dans un format connu. [36] Cette fonctionnalité est présente que la recherche soit déclenchée à partir d’un champ du navigateur ou sur le site Web de Google.

Il existe des bibliothèques JavaScript qui permettent d’écrire des applications en ligne de commande dans le navigateur en tant qu’applications Web autonomes ou dans le cadre d’une application plus importante. [37] Un exemple d’un tel site Web est l’interface CLI de DuckDuckGo . [38] Il existe également des applications SSH basées sur le Web, qui permettent de donner accès à l’interface de ligne de commande du serveur à partir d’un navigateur.

De nombreux jeux vidéo sur PC disposent d’une interface de ligne de commande souvent appelée console. Il est généralement utilisé par les développeurs de jeux pendant le développement et par les développeurs de mods à des fins de débogage ainsi que pour tricher ou sauter des parties du jeu.

Voir également

  • Comparaison des shells de commande
  • Liste des interpréteurs de ligne de commande
  • Application de la console
  • Directive interprète
  • Boucle de lecture-évaluation-impression
  • Script shell
  • Exécuter la commande
  • Interface utilisateur graphique § Comparaison avec d’autres interfaces
  • Au début… était la ligne de commande

Remarques

  1. ^ Un exemple est le système d’aide interne complet de la commande DR-DOS 7.03 DEBUG , qui peut être invoquée via??l’invite de débogage (plutôt que uniquement la?ensemble par défaut). Des pages d’aide spécifiques peuvent être sélectionnées via?n(oùnest le numéro de la page). De plus, l’aide pour des commandes spécifiques peut être affichée en spécifiant le nom de la commande après?, fe?Dappellera l’aide pour les différentes commandes de vidage (commeDetc.). Certaines de ces fonctionnalités étaient déjà prises en charge par DR DOS 3.41 SID86 et GEMSID .
  2. ^ Différence notable pour décrire la syntaxe de commandedes systèmes d’exploitation de type DOS : la documentation de Windows Server 2003 R2 utilise des lettres en italique pour les “informations que l’utilisateur doit fournir”, mais la documentation de Windows Server 2008 utilise des crochets angulaires. Les italiques ne peuvent pas être affichés par le système interne. commande “help”, alors qu’il n’y a pas de problème avec les chevrons.
  3. ^ À l’exception de l’art ASCII .

Références

  1. ^ “Coques Unix” . Archivé de l’original le 2007-11-08. la notion d’avoir un “shell de commande” remplaçable plutôt qu’un “moniteur” étroitement intégré au noyau du système d’exploitation a tendance à être attribuée à Multics.
  2. ^ un b “L’Origine de la Coquille” . www.multicians.org . Récupéré le 12/04/2017 .
  3. ^ Metz, Cade (2013-01-03). “Dites bonjour à l’oncle français perdu depuis longtemps sur Internet” . Câblé . Récupéré le 31/07/2017 .
  4. ^ Mazières, David (automne 2004). “MULTICS – Les sept premières années” . Systèmes d’exploitation avancés . Département d’informatique de Stanford . Récupéré le 01/08/2017 .
  5. ^ un b Jones, M. (2011-12-06). “Evolution des shells sous Linux” . développeurWorks . IBM . Récupéré le 01/08/2017 .
  6. ^ “Référence GNU BASH” .
  7. ^ “Présentation du shell de commande Microsoft Windows” .
  8. ^ Guide de l’utilisateur SID (PDF) . Recherche numérique . 1978. 595-2549. Archivé (PDF) de l’original le 2019-10-20 . Récupéré le 06/02/2020 . (4+69 pages)
  9. ^ Guide de l’utilisateur SID-86 pour CP / M-86 (2 éd.). Recherche numérique . août 1982 [mars 1982]. SID86UG.WS4. Archivé de l’original le 2019-10-20 . Récupéré le 06/02/2020 . [1] (NB. Une version retapée du manuel par Emmanuel Roche avec les commandes Q, SR et Z ajoutées.)
  10. ^ un bcdefghijk Paul , Matthias R. ( 1997-07-30 ) . _ _ NWDOS-TIPs – Tips & Tricks rund um Novell DOS 7, mit Blick auf undokumentierte Details, Bugs and Workarounds . MPDOSTIP . Version 157 (en allemand) (3 éd.). Archivé de l’original le 10/09/2017 . Récupéré le 06/09/2014 . (NB. NWDOSTIP.TXT est un travail complet sur Novell DOS 7 et OpenDOS 7.01 , y compris la description de nombreuses fonctionnalités et internes non documentés. Il fait partie de la collection MPDOSTIP.ZIP encore plus grande de l’auteur maintenue jusqu’en 2001 et distribuée sur de nombreux sites à Le lien fourni pointe vers une ancienne version convertie en HTML du fichier NWDOSTIP.TXT.)
  11. ^ Parker, Steve (2011). “Chapitre 11: Choisir et utiliser des obus”. Shell Scripting : Recettes expertes pour Linux, Bash et plus . Programmeur à programmeur. Indianapolis, États-Unis : John Wiley & Sons . p. 262.ISBN _ 978-111816632-1. Le shell a quatre invites de commande différentes, appelées PS1, P52, P53 et PS4. PS signifie chaîne d’invite.
  12. ^ Guide de l’utilisateur RISC OS 3 (PDF) . Acorn Computers Limited . 1992-03-01. p. 125.
  13. ^ un bcd Frères , Hardin ; Rawson, Tom ; Conn, Rex C. ; Paul, Matthias R.; Dye, Charles E.; Georgiev, Luchezar I. (2002-02-27). Aide en ligne de 4DOS 8.00 .
  14. ^ Paul, Matthias R. (1998-01-09). DELTREE.BAT R1.01 Suppression étendue de fichiers et de répertoires . Caldera, Inc. Archivé de l’original le 2019-04-08 . Récupéré le 08/04/2019 .
  15. ^ DR-DOS 7.03 WHATSNEW.TXT — Modifications de DR-DOS 7.02 à DR-DOS 7.03 . Caldera, Inc. 1998-12-24. Archivé de l’original le 2019-04-08 . Récupéré le 08/04/2019 .
  16. ^ “La syntaxe des arguments (la bibliothèque GNU C)” . www.gnu.org . Récupéré le 09/07/2021 .
  17. ^ un bc Paul, Matthias R. (2002-05-13). “[fd-dev] mkeyb” . freedos-dev . Archivé de l’original le 2018-09-10 . Récupéré le 10/09/2018 . […] IPC /H […] IPC [@] [@] [/?|/Help[:topic]] [/!|/About] […] [?|&] […] /?, /Help Afficher cet écran d’aide ou une aide spécifique pour un sujet (+) […] /!, /About Afficher l’écran d’information ‘About’ […] /Cpifile (+) .CPI/.CP file name <EGA.CPI>; extension : <.IPC> ; CPI.EXE=StdIn […] /Report Nom du fichier de rapport <‘ ‘=StdOut> ; extension : <.RPT> […] /Style (+) Exporter <0>-6=BIN-raw/ROM/RAM/PSF0/1/SH/CHED ; [ …] CPI /H:S […] Vue d’ensemble des paramètres /Style : […] ?, & Mode d’édition en ligne (demande de saisie de paramètres supplémentaires) […]
  18. ^ un b Paul, Matthias R. (2002-01-09). “SID86” . Newsgroup : comp.os.cpm . Récupéré le 08/04/2018 . […] Étant donné que le DR-DOS 7.03 DEBUG est toujours basé sur l’ancien SID86.EXE , je suggère d’exécuter DEBUG 1.51 et d’entrer dans le système d’aide étendu avec ?? à partir de l’invite de débogage. Cela vous donnera huit écrans pleins d’aide sur la syntaxe et les fonctionnalités. Certaines de ces fonctionnalités étaient également prises en charge par des problèmes plus anciens. […]
  19. ^ un b Paul, Matthias R.; Frinke, Axel C. (2006-01-16). FreeKEYB – Pilote international avancé de clavier et de console DOS (Manuel de l’utilisateur) (v7 éd. préliminaire).
  20. ^ Documentation en ligne CCI Multiuser DOS 7.22 GOLD . Concurrent Controls, Inc. (CCI). 1997-02-10. AIDE.HLP. (NB. Le débogueur d’instructions symboliques SID86 fournit un court écran d’aide sur ?et une aide complète sur ??.)
  21. ^ Paul, Matthias R. (1997-05-24) [1991]. DRDOSTIP.TXT – Trucs et astuces pour DR DOS 3.41 – 5.0 . MPDOSTIP (en allemand) (47 éd.). Archivé de l’original le 2016-11-07 . Récupéré le 07/11/2016 .
  22. ^ “Le numéro 7 des spécifications de base du groupe ouvert, chapitre 12.1 Syntaxe des arguments d’utilité” . Le groupe ouvert . 2008 . Récupéré le 07/04/2013 . man-pages(7) – Linux Conventions and Miscellany Manual (NB. Conventions pour décrire les commandes sur les systèmes d’exploitation de type Unix.)
  23. ^ “Aperçu du shell de commande” . Aide du produit Windows Server 2003 . Microsoft . 2005-01-21 . Récupéré le 07/04/2013 .
  24. ^ “Clé de syntaxe de ligne de commande” . Bibliothèque TechNet Windows Server 2008 R2 . Microsoft . 2010-01-25 . Récupéré le 07/04/2013 .
  25. ^ Kernighan, Brian W. ; Brochet, Rob (1984). L’environnement de programmation UNIX . Falaises d’Englewood : Prentice-Hall . ISBN 0-13-937699-2.
  26. Pouzin, Louis. “L’origine de la coquille” . Multicians.org . Récupéré le 22/09/2013 .
  27. ^ “Se souvenir du lancement de Windows 95 15 ans plus tard” . 2010-08-24.
  28. ^ “Une histoire de Windows” . windows.microsoft.com . Archivé de l’original le 01/03/2015.
  29. ^ “Compatibilité du shell Windows POSIX” .
  30. ^ “maître – plate-forme/externe/mksh – Git chez Google” . android.googlesource.com . Récupéré le 18/03/2018 .
  31. ^ “Android adb shell – ash ou ksh?” . stackoverflow.com . Récupéré le 14/03/2018 .
  32. ^ “Source sh Android” . GitHub . Archivé de l’original le 17/12/2012.
  33. ^ “Source de la boîte à outils Android” . GitHub .
  34. ^ “Guide de configuration des principes de base de la configuration, Cisco IOS version 15M&T” . Cisco . 2013-10-30. Utilisation de l’interface de ligne de commande. L’interface de ligne de commande (CLI) Cisco IOS est l’interface utilisateur principale…
  35. ^ “Vue d’ensemble de l’interface de ligne de commande” . www.juniper.net . Récupéré le 14/03/2018 .
  36. ^ “Google étrange bonté” .
  37. ^ Émulateur de terminal jQuery
  38. ^ DuckDuckGo ATS

Liens externes

  • Les racines de DOS David Hunter, Softalk pour l’ordinateur personnel IBM , mars 1983. Archivé sur Patersontech.com depuis 2000 .
  • Référence de la ligne de commande : Base de données Microsoft TechNet “Référence de la ligne de commande”
commandecommandesligneligne de commandeWindows
Comments (0)
Add Comment