Bash se comporte de manière quelque peu non standard lorsqu'il s'agit de - .
POSIX dit :
Ligne directrice 10 :
Le premier--un argument qui n'est pas un argument d'option doit être accepté comme délimiteur indiquant la fin des options. Tous les arguments suivants doivent être traités comme des opérandes, même s'ils commencent par le-caractère.[…]
Ligne directrice 13 :
Pour les utilitaires qui utilisent des opérandes pour représenter des fichiers à ouvrir en lecture ou en écriture, le-l'opérande doit être utilisé pour désigner uniquement l'entrée standard (ou la sortie standard lorsqu'il ressort clairement du contexte qu'un fichier de sortie est spécifié) ou un fichier nommé-.
Et
Lorsqu'un utilitaire décrit dans le volume Shell and Utilities de POSIX.1-2017 comme conforme à ces directives est tenu d'accepter ou de ne pas accepter l'opérande
-pour signifier entrée ou sortie standard, cette utilisation est expliquée dans la section OPÉRANDES. Sinon, si un tel utilitaire utilise des opérandes pour représenter des fichiers, il est défini par l'implémentation si l'opérande-signifie entrée standard (ou sortie standard), ou pour un fichier nommé-.
Mais alors man 1 bash lit :
Un
--signale la fin des options et désactive le traitement ultérieur des options. Tous les arguments après le--sont traités comme des noms de fichiers et des arguments. Un argument de-est équivalent à--.
Donc pour Bash - signifie ni entrée standard ni fichier, donc quelque peu non standard.
Maintenant votre cas particulier :
curl -sL https://rpm.nodesource.com/setup_6.x | sudo -E bash -
Je soupçons l'auteur de cette commande peut ne pas réaliser - est équivalent à -- dans ce cas. Je soupçons l'auteur voulait s'assurer bash lira à partir de son entrée standard, ils s'attendaient à - travailler selon la directive 13.
Mais même si cela fonctionnait conformément à la directive, - serait inutile ici car bash détecte quand son entrée standard est un tube et agit en conséquence (sauf si -c est donné, etc.).
Pourtant - ne fonctionne pas selon la directive, cela fonctionne comme -- . Toujours -- n'est pas nécessaire ici car il n'y a pas d'arguments après.
A mon avis le dernier - ne change rien. La commande fonctionnerait sans elle.
Pour voir comment -- et - peut être utile en général, étudiez l'exemple ci-dessous.
cat dans mon Kubuntu obéit aux deux directives et je vais l'utiliser pour démontrer l'utilité de - et -- .
Laissez un fichier nommé foo exister. Cela imprimera le fichier :
cat foo
Laissez un fichier nommé --help exister. Cela n'imprimera pas le fichier :
cat --help
Mais cela imprimera le fichier nommé --help :
cat -- --help
Cela concaténera le fichier nommé --help avec tout ce qui vient de l'entrée standard :
cat -- --help -
Il semble que vous n'ayez pas vraiment besoin de -- , car vous pouvez toujours passer ./--help qui sera interprété comme un fichier à coup sûr. Mais considérez
cat "$file"
lorsque vous ne savez pas à l'avance quel est le contenu de la variable. Vous ne pouvez pas simplement ajouter ./ car il peut s'agir d'un chemin absolu et ./ le briserait. D'un autre côté, il peut être un fichier nommé --help (parce que pourquoi pas ?). Dans ce cas -- est très utile; c'est une commande beaucoup plus robuste :
cat -- "$file"
En man bash , à la fin des options à caractère unique, il y a :-
-- A -- signals the end of options and disables further option processing.
Any arguments after the -- are treated as filenames and arguments. An
argument of - is equivalent to --.
Si vous avez cité la commande complète, je ne vois aucune raison d'utiliser - après bash dans ce cas, mais cela ne fait aucun mal.