Bash se comporta de una manera algo no estándar cuando se trata de - .
POSIX dice:
Directriz 10:
El primer -- argumento que no es una opción-argumento debe aceptarse como un delimitador que indica el final de las opciones. Los siguientes argumentos deben tratarse como operandos, incluso si comienzan con el - personaje.
[…]
Directriz 13:
Para utilidades que usan operandos para representar archivos que se abren para lectura o escritura, el - El operando debe usarse para indicar solo una entrada estándar (o una salida estándar cuando está claro por el contexto que se está especificando un archivo de salida) o un archivo llamado - .
Y
Cuando una utilidad descrita en el volumen Shell and Utilities de POSIX.1-2017 como conforme a estas pautas debe aceptar o no aceptar el operando - para significar entrada o salida estándar, este uso se explica en la sección OPERANDS. De lo contrario, si dicha utilidad usa operandos para representar archivos, está definido por la implementación si el operando - significa entrada estándar (o salida estándar), o un archivo llamado - .
Pero entonces man 1 bash lee:
Un -- señala el final de las opciones y deshabilita el procesamiento adicional de opciones. Cualquier argumento después del -- se tratan como nombres de archivo y argumentos. Un argumento de - es equivalente a -- .
Así que para Bash - no significa ni entrada estándar ni un archivo, por lo tanto algo no estándar.
Ahora tu caso particular:
curl -sL https://rpm.nodesource.com/setup_6.x | sudo -E bash -
sospecho el autor de este comando puede no darse cuenta de - es equivalente a -- en este caso. sospecho el autor quería asegurarse de que bash leerá de su entrada estándar, esperaban - trabajar de acuerdo con la directriz 13.
Pero incluso si funcionó de acuerdo con la guía, - sería innecesario aquí porque bash detecta cuando su entrada estándar es una tubería y actúa en consecuencia (a menos que -c se da, etc.).
Sin embargo, - no funciona de acuerdo con la directriz, funciona como -- . Todavía -- es innecesario aquí porque no hay argumentos después.
En mi opinión, el último - no cambia nada El comando funcionaría sin él.
Para ver cómo -- y - puede ser útil en general, estudie el ejemplo a continuación.
cat en mi Kubuntu obedece ambas pautas y lo usaré para demostrar la utilidad de - y -- .
Deje un archivo llamado foo existir. Esto imprimirá el archivo:
cat foo
Deje un archivo llamado --help existir. Esto no imprimirá el archivo:
cat --help
Pero esto imprimirá el archivo llamado --help :
cat -- --help
Esto concatenará el archivo llamado --help con lo que venga de la entrada estándar:
cat -- --help -
Parece que realmente no necesitas -- , porque siempre puedes pasar ./--help que se interpretará como un archivo seguro. Pero considera
cat "$file"
cuando no se sabe de antemano cuál es el contenido de la variable. No puede simplemente anteponer ./ porque puede ser una ruta absoluta y ./ lo rompería. Por otro lado, puede ser un archivo llamado --help (¿Porque, porque no?). En este caso -- es muy útil; este es un comando mucho más robusto:
cat -- "$file"
En man bash , al final de las opciones de un solo carácter hay:-
-- 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 ha citado el comando completo, no veo ninguna razón para usar - después de bash en este caso, pero no hace daño.