Forum Linux.débutant question sur les arguments que l'on donne aux commandes

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
1
14
juin
2019

Bonjour,

Si je veux afficher tous les fichiers de mon répertoire courant j'ajoute à la commande ls l'argument -a. Et dans la plupart des arguments que l'on donne aux commandes on a des tirets. Mais dans certaines commandes on met aucun tiret dans les arguments comme par exemple systemctl status ou l'argument status n'a pas de tiret

Pourquoi certain programme ne respecte pas la norme avec le tiret

merci d'avance

  • # Options, arguments, sous-commandes

    Posté par  (site web personnel) . Évalué à 4.

    La convention d'origine, c'est d'utiliser des tirets pour les options — un seul pour une option courte, deux pour une option longue — et de laisser ensuite, sans tirets, les arguments. Une option, tel que je le comprends en tout cas, c'est quelque chose qui vient régler, préciser ou modifier ce que fait la commande. Les arguments sans tirets servent plutôt à indiquer ce sur quoi la commande va agir, en général un fichier ou un répertoire.

    Plus tard, à ce qu'il me semble, on a introduit des commandes avec ce qu'on appelle des sous-commandes, par exemple ce systemctl status. Sans status, ça ne veut rien dire du tout, systemctl ne sait absolument pas ce qu'on veut qu'il fasse, d'où cette idée de « sous-commande ». C'est tout.

    • [^] # Re: Options, arguments, sous-commandes

      Posté par  (site web personnel) . Évalué à 3.

      Depuis très longtemps, on avait 'ps aux' ou 'ps -elf' suivant les systèmes.

      • [^] # Re: Options, arguments, sous-commandes

        Posté par  . Évalué à 2. Dernière modification le 15 juin 2019 à 12:04.

        A noter que les *BSD, le tiret n'est pas déclaré optionnel dans le manuel,
        - alors que la syntaxe sans le tiret est appelée «BSD» sous les linux -
        même si cette syntaxe est toujours acceptée.

        Il me semble que ce n'est plus le cas non plus sur les Linux les plus récents.

    • [^] # Re: Options, arguments, sous-commandes

      Posté par  (site web personnel) . Évalué à 0.

      La documentation, et surtout le comportement de systemctl sans paramètre, semblent contredire cette assertion.

      COMMANDS
       The following commands are understood:

   Unit Commands
       list-units [PATTERN...]
           List units that systemd currently has in memory. This includes
           units that are either referenced directly or through a dependency,
           units that are pinned by applications programmatically, or units
           that were active in the past and have failed. By default only units
           which are active, have pending jobs, or have failed are shown; this
           can be changed with option --all. If one or more PATTERNs are
           specified, only units matching one of them are shown. The units
           that are shown are additionally filtered by --type= and --state= if
           those options are specified.

           This is the default command.

      Debian Consultant @ DEBAMAX

      • [^] # Re: Options, arguments, sous-commandes

        Posté par  . Évalué à 2.

        La documentation, et surtout le comportement de systemctl sans paramètre, semblent contredire cette assertion.

        En quoi ?

        En l'absence de sous-commande explicite, le programme en définit une par défaut. Cela signifie bel et bien qu'une sous-commande est requise pour faire fonctionner le programme.

        SYNOPSIS
       systemctl [OPTIONS...] COMMAND [NAME...]

        COMMAND n'est pas optionnel.

  • # confusion

    Posté par  . Évalué à 2.

    Quelle norme ?

    Les tirets correspondent en principe à une option, un drapeau/commutateur, peut importe comment on l'appelle. Avec des variantes pour les tirets doubles.

    • pour exprimer une option en version longue, qui ne pourrait être représenté avec une seule lettre  ;
    • pour exprimer une option en version étendue, qui n'est pas compatible POSIX, ou non prise en charge par l'outil traditionnel;
    • pour passer une option à un processus enfant ;
    • pour signifier la fin des options et que tout ce qui suit doit être considérer comme arguments .

    status est un argument de la commande systemctl, qui l'interprète comme une sous-commande (comme indiqué dans la page de man).

    Èvidemment, lorsque l'on regarde ps de plus près, tout ce beau principe est foutu en l'air.

    • [^] # Re: confusion

      Posté par  . Évalué à 2.

      Èvidemment, lorsque l'on regarde ps de plus près, tout ce beau principe est foutu en l'air.

      Je peux me tromper sur l'histoire de UNIX mais est-ce que ces outils, comme ps, tar et autres n'ont pas été écrits avant que soit décidé d'adopter la convention que l'on connaît aujourd'hui pour le passage d'arguments?

  • # plus une convention qu'un norme

    Posté par  (site web personnel) . Évalué à 1.

    Une norme, c'est quelque chose de très formel : ISO, ANSI …

    Pour les commandes unix, il y a un eu un gros travail de standardisation qui a amené les normes POSIX. On peut voir dans les pages de man si les commandes respectent POSIX.

    Et puis il y a des machins qui ne respectent pas les convention, j'aime bien prendre pour cela la commande java : pour obtenir la version il faut taper "java -version" , et "java --version" renvoie : "Error: A fatal exception has occurred. Program will exit"

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.