¿Cuál es la función del asterisco como comando independiente en Unix?

Estaba jugando en la terminal en Red Hat Linux, y cuando escribí el asterisco ( *) seguido de return, ejecuté uno de los programas en mi directorio. ¿Por qué?

Mi mejor conjetura es que Unix lo trató como un comodín, por lo que ejecutó el primer programa alfabético. Dado my_program.exey one_of_my_programs.programse puede ejecutar simplemente escribiendo el nombre del archivo, el operador comodín representa todos los archivos posibles. Como un programa es primero alfabéticamente, Unix lo ejecuta. ¿Es este un juicio correcto?

— usuario6086585
fuente

Creo que no todos los shells ordenan la expansión *alfabéticamente, pero bash es uno que sí.

— aschepler

@aschepler: todos los shells conformes con POSIX deben; ver pubs.opengroup.org/onlinepubs/9699919799/utilities/… para 3.

— dave_thompson_085

Respuestas:

Tu interpretación es correcta. El resto de los archivos se presentarán como su lista de parámetros.

Tenga en cuenta que solo hará esto si el programa tiene el bit ejecutable establecido y el directorio actual está en la PATHlista.

Un par de notas que pueden ayudar a comprender: -

Si escribe ./*, la PATHentrada no es un requisito.
Si escribe . *o . ./*y el primer archivo coincidente es un script, no es necesario que sea ejecutable ni que el directorio actual esté PATH(puede que no sea cierto para shells que no sean bash).

— AFH
fuente

"solo hará esto ..." - Puede ser más interesante. Si hay una función de shell, integrada o un ejecutable anterior PATHcon el mismo nombre que el primer archivo, se ejecutará este otro comando. mkdir foo; cd foo; touch rm xyz; ls; *; ls.

— Kamil Maciorowski el

@KamilMaciorowski - Punto justo: mi afirmación "hará esto solo ..." especificó las condiciones necesarias , pero no las suficientes . El comando también se comportará de manera diferente si *es un alias.

— AFH

Conclusión: ¡no hagas esto! Incluso si cree que puede confiar en el orden alfabético de expansión global, tenga en cuenta que este orden depende de la configuración regional.

— Aaron

además de . *o . ./*una lata bash *(o cualquier otro caparazón).

— Olivier Dulac

Esto sugiere que .es parte de su PATHvariable. Esa es una muy mala idea por razones de seguridad (naturalmente, Windows tuvo que convertirla en un valor predeterminado no modificable).

Sin embargo, esta "sugerencia" solo es ligeramente válida: si tiene un archivo nombrado rmen su directorio actual, *estará bien ejecutando el predeterminado rm :

/tmp$ mkdir ohno
/tmp$ cd ohno
/tmp/ohno$ 
/tmp/ohno$ ls
/tmp/ohno$ touch rm what
/tmp/ohno$ ls
rm  what
/tmp/ohno$ *
/tmp/ohno$ ls
rm
/tmp/ohno$

Como puede ver, no se rmejecutó el directorio actual (un archivo vacío y no ejecutable) sino el valor predeterminado del sistema /bin/rm.

Siempre revise sus comandos cuando estén involucrados comodines. Este es uno de los mensajes más terroríficos que jamás haya leído:

rm: cannot remove '.o': No such file or directory

Este es el resultado de llamar

rm * .o

, más o menos la peor ubicación de un espacio espurio que se pueda encontrar.

No está de más crear una función rm()que se agregue -ia los parámetros o verifique los parámetros y solicite confirmación si hay más de un número determinado.

— AFH

+1 para "Este es uno de los mensajes más terroríficos que jamás haya leído".

— Mehrdad

+1 para "Esa es una muy mala idea por razones de seguridad (naturalmente, Windows tuvo que convertirla en un valor predeterminado no modificable)".

— Duncan X Simpson

FTFY: mv /tmp/ohno /tmp/ohnoes( google.fr/search?q=ohnoes&source=lnms&tbm=isch )

— Olivier Dulac

Hay una buena razón por la cual Windows lo convirtió en un valor predeterminado no modificable. Tiene que mantener una cadena de compatibilidad con versiones anteriores desde los días anteriores a que DOS implementara directorios. Tenga en cuenta aquellos días que nadie que usaba una PC tenía un disco duro, y los disquetes eran lo suficientemente pequeños como para que los directorios no se consideraran necesarios inicialmente.

— Muzer