Quelle est la différence entre le tiret simple et le tiret double sur les commandes Shell ?

Tout dépend du programme. Habituellement, "-" est utilisé pour les options "courtes" (une lettre, -h), et "--" est utilisé pour les options "longues" (--help).

Les options courtes peuvent généralement être combinées (ainsi "-h -a" est identique à "-ha").

Dans les systèmes de type Unix, le tiret ASCII moins est couramment utilisé pour spécifier des options. Ce caractère est généralement suivi d'une ou plusieurs lettres. Un argument qui est un simple trait d'union minuscule sans aucune lettre indique généralement qu'un programme doit traiter les données provenant de l'entrée standard ou envoyer des données à la sortie standard. Deux traits d'union ( -- ) sont utilisés dans certains programmes pour spécifier des "options longues" où des noms d'options plus descriptifs sont utilisés. Il s'agit d'une caractéristique commune aux logiciels GNU.

source

C'est vraiment une convention. Cependant, elle peut aider les analyseurs à connaître plus efficacement les options passées au programme. De plus, il existe des utilitaires astucieux qui peuvent aider à analyser ces commandes, tels que getopt(3) ou la version non standard getopt_long(3) pour aider à analyser les arguments d'un programme.

C'est bien, car nous pouvons avoir plusieurs options courtes combinées, comme le disent d'autres réponses, par exemple tar -xzf myfile.tar.gz .

S'il y avait un argument "lisa" pour ls il y aurait probablement un sens différent à taper. ls -lisa que ls --lisa . Les premiers sont les l , i , s et a les paramètres, pas le mot.

En fait, vous pourriez écrire ls -l -i -s -a qui signifie exactement la même chose que ls -lisa mais cela dépend du programme.

Il existe également des programmes qui n'obéissent pas à cette convention. Notamment pour ma vue, dd und gcc .

options courtes avec simple tiret vs options longues avec double tiret

Les options courtes peuvent être combinées en un seul argument ;

for example: ls -lrt #instead of ls -l -r -t

Si nous autorisons les options longues avec un seul tiret, cela crée une ambiguïté. Pour résoudre ce problème, nous utilisons le double tiret pour les options longues.

Un autre cas est celui où un script appelle un autre programme, il peut être nécessaire de séparer les options du premier script de celles passées au second programme. Par exemple, vous pouvez écrire une fonction bash pour analyser la ligne de commande, similaire à la fonction ci-dessous. Ensuite, utilisez une ligne de commande similaire à la suivante. Dans ce cas, les doubles tirets maintiennent les options de chaque programme séparées et permettent à la gestion des erreurs de l'analyseur intégré de fonctionner comme prévu. Bien sûr, il peut y avoir des cas particuliers qui doivent être traités.

 firstscript --firstScriptOption -- --optForSecondProgram

# Parse the command line and set variables to control logic.
parseCommandLine() {
  local additionalOpts exitCode optstring optstringLong
  # Indicate specification for single character options:
  # - 1 colon after an option indicates that an argument is required
  # - 2 colons after an option indicates that an argument is optional, must use -o=argument syntax
  optstring="h"
  # Indicate specification for long options:
  # - 1 colon after an option indicates that an argument is required
  # - 2 colons after an option indicates that an argument is optional, must use --option=argument syntax
  optstringLong="help"
  # Parse the options using getopt command:
  # - the -- is a separator between getopt options and parameters to be parsed
  # - output is simple space-delimited command line
  # - error message will be printed if unrecognized option or missing parameter but status will be 0
  # - if an optional argument is not specified, output will include empty string ''
  GETOPT_OUT=$(getopt --options ${optstring} --longoptions ${optstringLong} -- "$@")
  exitCode=$?
  if [ ${exitCode} -ne 0 ]; then
    # Call a separate function to print usage.
    printUsage
    exit 1
  fi
  # The following constructs the command by concatenating arguments:
  # - the $1, $2, etc. variables are set as if typed on the command line
  # - special cases like --option=value and missing optional arguments are generically handled
  #   as separate parameters so shift can be done below
  eval set -- "${GETOPT_OUT}"
  # Loop over the options:
  # - the error handling will catch cases were argument is missing
  # - shift over the known number of options/arguments
  while true; do
    #echo "Command line option is ${opt}"
    case "$1" in
      -h|--help) # Print usage of this script
        printUsage
        shift
        ;;
      --) # No more arguments - following arguments are passed to the second program.
        shift
        break
        ;;
      *) # Unknown option - will never get here because getopt catches up front
        # and remaining options are after --
        echo "Invalid option $1." >&2
        printUsage
        exit 1
        ;;
    esac
  done
  # Get a list of all command line options that do not correspond to dash options:
  # - These are "non-option" arguments after --
  # - For example, one or more file or folder names that need to be processed.
  # - If multiple values, they will be delimited by spaces.
  # - Command line * will result in expansion to matching files and folders.
  shift $((OPTIND-1))
  additionalOpts=$*
  echo "Additional options: ${additionalOpts}"
  # The additional options would be passed to the second program.
}