¿Por qué las construcciones de Shell no se pueden ejecutar con letras mayúsculas, pero sí otros comandos?

¿Por qué es esto?

Cuando hago esto

CD ~/Desktop

No me lleva al escritorio. Pero esto:

echo "foo
bar" | GREP bar

me da

bar

— Nombre para mostrar
fuente

Verifique si alias GREPo which GREPproduce algo.

— chepner

Ahí tienes. Tiene un comando llamado GREP, que es distinto de grep. (Es cierto que puede ser simplemente un enlace duro o un enlace simbólico a /usr/bin/grep, pero desde el punto de vista de la cáscara, que es un comando separado.)

— chepner

Espera: estás en Mac OS X, ¿no? HFS + conserva las mayúsculas y minúsculas de forma predeterminada, lo que significa que si las mayúsculas y minúsculas son importantes cuando crea un archivo, pero una vez que el archivo existe, las búsquedas no distinguen entre mayúsculas y minúsculas. Es decir, bashpodría pedir un archivo llamado GREP, pero el sistema de archivos considera grepuna coincidencia.

— chepner

Sí, porque es Unix.

— DisplayName

Los sistemas de archivos son independientes del sistema operativo. Puede usar otros sistemas de archivos con Mac OS X, y puede (en teoría) usar HFS + con otros sistemas operativos. Además, puede hacer que HFS + distinga entre mayúsculas y minúsculas; el comportamiento de preservación de mayúsculas y minúsculas es el predeterminado por razones históricas

— chepner

De sus otras preguntas, supongo que está utilizando OS X. El sistema de archivos HFS + predeterminado en OS X no distingue entre mayúsculas y minúsculas: no puede tener dos archivos llamados "abc" y "ABC" en el mismo directorio, y tratando de acceder cualquiera de los nombres llegará al mismo archivo. Lo mismo puede suceder con Cygwin o con sistemas de archivos que no distinguen entre mayúsculas y minúsculas (como FAT32 o ciopfs ) en cualquier lugar.

Como grepes un ejecutable real, se busca en el sistema de archivos (en los directorios de PATH). Cuando su shell busque /usr/bincualquiera de ellos grepo GREPencontrará el grepejecutable.

Los componentes integrados de Shell no se buscan en el sistema de archivos: debido a que están integrados, se accede a ellos a través de comparaciones de cadenas (sensibles a mayúsculas y minúsculas) dentro del propio shell.

Lo que estás encontrando es un caso interesante. Mientras que cdes un incorporado, se accede a mayúsculas y minúsculas, CDse encuentra como un ejecutable /usr/bin/cd. El cdejecutable es bastante inútil: debido a que cdafecta el entorno actual de ejecución del shell, siempre se proporciona como un shell incorporado regularmente , pero de todos modos hay un cdejecutable por el bien de POSIX , que cambia el directorio por sí mismo y luego termina inmediatamente, dejando el shell circundante donde empezó

Puede probar estos con el typeincorporado :

$ type cd
cd is a shell builtin
$ type CD
CD is /usr/bin/CD

typele dice qué hará el shell cuando ejecute ese comando. Cuando ejecutas cd, accedes al builtin, pero CDencuentra el ejecutable. Para otros componentes integrados, el componente integrado y el ejecutable serán razonablemente compatibles (intente echo), pero cdeso no es posible.

— Michael Homer
fuente

buena respuesta. Estaba a punto de decir cygwin, que tendría el mismo efecto.

— Joshua

@Joshua El problema del OP está resuelto, pero creo que para otros lectores de la pregunta, una respuesta basada en Cygwin sería al menos tan útil como la existente; ¿Quizás pueda hacer que esta sea una respuesta separada, aunque sea breve, y diferir a la existente para obtener más detalles?

— Volker Siegel

¿Por qué posix requeriría un comando inútil como cd, y por qué el cd interno de osx no califica?

— John

51 votos a favor! Debería haber publicado una respuesta, en lugar de un comentario :)

— chepner

/ usr / bin / cd tiene un propósito. la sintaxis es / usr / bin / cd argumentos del programa de directorio

— Joshua