Pourquoi les commandes intégrées de Shell ne peuvent-elles pas être exécutées avec des lettres majuscules, alors que d'autres commandes le peuvent?

Pourquoi est-ce?

Quand je fais ça

CD ~/Desktop

Cela ne me prend pas au bureau. Mais ça:

echo "foo
bar" | GREP bar

Donne moi:

bar

— Afficher un nom
source

Vérifiez si alias GREPou which GREPsortez quelque chose.

— Chepner

Voilà. Vous avez une commande nommée GREP, qui est distincte de grep. (Certes, il peut s'agir simplement d'un lien /usr/bin/grep

— physique

Attendez: vous êtes sur Mac OS X, n'est-ce pas? HFS + préserve la casse par défaut, ce qui signifie que si la casse est importante lorsque vous créez un fichier, mais une fois que le fichier existe, les recherches ne tiennent pas compte de la casse. C'est-à-dire que vous bashpouvez demander un fichier nommé GREP, mais le système de fichiers considère grepune correspondance.

— Chepner

Oui, car c'est Unix.

— DisplayName

Les systèmes de fichiers sont indépendants du système d'exploitation. Vous pouvez utiliser d'autres systèmes de fichiers avec Mac OS X et (en théorie) utiliser HFS + avec d'autres systèmes d'exploitation. En outre, vous pouvez rendre HFS + sensible à la casse; le comportement préservant la casse n'est que le comportement par défaut pour des raisons historiques.

— Chepner

D'après vos autres questions, vous utilisez OS X. Le système de fichiers HFS + par défaut sur OS X ne tient pas compte de la casse: vous ne pouvez pas avoir deux fichiers nommés "abc" et "ABC" dans le même répertoire et essayez d'accéder au même répertoire. l'un ou l'autre nom ira au même fichier. La même chose peut arriver sous Cygwin ou avec des systèmes de fichiers insensibles à la casse (comme FAT32 ou ciopfs ) n’importe où.

Parce que grepest un vrai exécutable, il est recherché sur le système de fichiers (dans les répertoires de PATH). Lorsque votre shell cherche l’ /usr/binun grepou l’ autre, GREPil trouvera l’ grepexécutable.

Les éléments intégrés au shell ne sont pas examinés sur le système de fichiers: comme ils sont intégrés, ils sont accessibles via des comparaisons de chaînes (sensibles à la casse) dans le shell même.

Ce que vous rencontrez est un cas intéressant. While cdest intégré, accessible en respectant les majuscules et les minuscules, CDen tant qu’exécutable /usr/bin/cd. L' cdexécutable est plutôt inutile: étant donné qu'il cdaffecte l'environnement d'exécution actuel du shell, il est toujours fourni en tant que shell standard , mais il existe néanmoins un cdexécutable pour POSIX , qui change de répertoire pour lui-même et se termine immédiatement, laissant le shell environnant. où cela a commencé.

Vous pouvez les essayer avec le programme typeintégré :

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

typevous indique ce que le shell fera lorsque vous exécuterez cette commande. Lorsque vous exécutez, cdvous accédez à la commande intégrée, mais vous trouvez CDle fichier exécutable. Pour les autres fonctions intégrées, celles-ci et l'exécutable seront raisonnablement compatibles (essayez echo), mais cdcela n'est pas possible.

— Michael Homer
source

bonne réponse. J'étais sur le point de dire cygwin, ce qui aurait le même effet.

— Josué

@ Josué Le problème du PO est résolu, mais je pense que pour les lecteurs ultérieurs de la question, une réponse basée sur cygwin serait au moins aussi utile que la réponse existante; Peut-être pourriez-vous en faire une réponse distincte, même si elle est brève, et vous reporter à la réponse existante pour plus de détails?

— Volker Siegel

Pourquoi posix nécessiterait-il une commande inutile comme cd, et pourquoi le cd interne d'osx n'est-il pas admissible?

— John

51 votes positifs! J'aurais juste dû poster une réponse, au lieu d'un commentaire :)

— chepner

/ usr / bin / cd a un but. la syntaxe est la suivante: / usr / bin / cd arguments du programme de répertoire

— Joshua