Quand je le fais - CD ..au lieu de cd ..
cela, cela me donne une erreur de dire -

CD: command not found

Pourquoi le terminal est- il sensible aux commandes Linux? Je veux dire que vous devriez pouvoir exécuter la commande avec des caractères "tout en majuscules" ou "tous en minuscules".

Je sais que cela est dû à une raison quelconque, mais je suis simplement curieux.

En fin de compte, c'était un choix arbitraire fait par les créateurs d'Unix il y a plus de quatre décennies maintenant. Ils auraient pu choisir de rendre les choses insensibles à la casse comme les créateurs de MS-DOS l'ont fait une décennie plus tard, mais cela a aussi ses inconvénients.

Il est trop profondément ancré dans la culture * ix pour changer maintenant. Le problème du système de fichiers sensible à la casse soulevé par eppesuig n'en est qu'une partie. Les systèmes macOS - qui sont basés sur Unix - ont généralement des systèmes de fichiers qui ne respectent pas la casse (mais en préservant la casse), de sorte que ces commandes de systèmes externes au shell sont en fait traitées sans respect de la casse. Mais, les builtins commecd restent sensibles à la casse.

Même avec un système de fichiers insensible à la casse, l'histoire des choses conspire contre votre gré, Hussain. Si je tape lssur mon Mac, j'obtiens une liste de répertoires colorisés. Si je tape à la LSplace, /bin/lss'exécute toujours, mais la liste n'est pas colorisée car l'alias qui ajoute l' -Cindicateur est sensible à la casse.

Mieux vaut juste s'y habituer. Si vous le pouvez, apprenez à l'aimer.

Ce n'est pas un problème "terminal", c'est une fonctionnalité de système de fichiers. Comment le shell doit-il rechercher vos commandes sur le système de fichiers (toujours sensible à la casse)?

Les systèmes techniques que j'utilise et respecte sont presque exclusivement sensibles à la casse: que ce soit l'OS ou le langage de programmation ou autre chose.

Les exceptions auxquelles je pourrais penser en ce moment sont les balises HTML et certaines implémentations de SQL, et le langage de programmation Ada.

Même dans ces cas, je pense qu'il y a de fortes tendances à écrire des balises HTML en minuscules et la sémantique des requêtes SQL en majuscules (et les paramètres en majuscules). (Corrigez-moi si je me trompe.) Comme pour Ada, le mode Emacs vous corrigera si vous tapez par exemple un nom de procédure en minuscule, bien que cela n'ait pas d'importance lors de la compilation. Donc, même lorsqu'il y a insensibilité à la casse, il semble que les gens conviennent que c'est une mauvaise idée.

La raison en est que vous obtenez une puissance beaucoup plus expressive avec la casse. Non seulement quantitativement - CDest l' un, mais CD, Cd, cDet cdsont quatre - mais plus important encore , vous pouvez l'objet explicite, l' accent, etc. , en utilisant majuscules et minuscules sensiblement; De plus, lors de la programmation, vous améliorerez la lisibilité.

Intuitivement, il est clair que vous ne lisez pas hiet de HIla même manière!

Mais, pour vous donner un exemple du monde informatique, dans le langage de programmation Ada (des années 1980), la première ligne d'un bloc de code de procédure pourrait ressembler à ceci:

procedure body P(SCB : in out Semaphore_Control_Block) is

comme vous le voyez, les noms de procédure et de paramètre sont en majuscules, tout comme les types de données, tout le reste est en minuscules. Notez également que le nom du paramètre «tout en majuscules» nous indique qu'il s'agit d'un acronyme. Maintenant, comparez cela à

procedure body p(scb : in out semaphore_control_block) is

C'est possible, car Ada est insensible à la casse (ou, pour être exact, le compilateur le changera de la manière dans mon premier exemple, mais bien sûr ne changera pas votre code). Ou que diriez-vous:

PROCedure body P(Scb : IN Out semaphore_CONTROL_BLOCK) iS

Celui-là est un peu ridicule, je sais; mais quelqu'un serait assez stupide pour l'écrire de cette façon (enfin, peut-être pas). Le fait est qu'un système sensible à la casse forcera non seulement les gens à être cohérents, ils seront également aidés par lui (lisibilité) et l'utiliseront à leur avantage (l'exemple d'acronyme ci-dessus).

Ce n'est pas plus ou moins étrange que le fait que nous ayons un alphabet majuscule et minuscule pour commencer. Si vous regardez /usr/bin, vous remarquerez que (très) peu d'exécutables exploitent la capitalisation.

Un espace de noms sensible à la casse n'est pas seulement deux fois plus grand qu'un espace insensible - la différence augmente de façon exponentielle avec la longueur des mots. Par exemple, en utilisant 26 caractères, il existe 26 ^ 3 (17576) possibilités différentes en trois lettres; en utilisant 52 (2 * 26) caractères, il y a 52 ^ 3 = 140608. Un espace de noms ouvert est une bonne chose;)

Le concept de majuscules / minuscules peut être (et est en effet) une chose spécifique aux paramètres régionaux, qui, comme toute autre complication de conception, doit être poussée le plus près possible du point d'utilisation dans la pile d'applications, ne pas faire partie de la coeur.

Avoir un environnement sensible à la casse permet de l'envelopper dans un environnement insensible à la casse, mais pas l'inverse.

Ce n'est pas le terminal, c'est le système de fichiers. Ou dans le cas cd(cd est un shell intégré), le shell est sensible à la casse.

Il aurait pu être possible (au moins avec ASCII), de faire est insensible à la casse. C'est plus difficile avec l'unicode maintenant utilisé (si deux caractères sont identiques, cela peut dépendre du local).

Que faire à ce sujet

• Vivre avec.
• Essayez ces options de shell. Ils offrent un compromis et facilitent les choses sans introduire tous les problèmes d'insensibilité à la casse.
  • shopt -s nocaseglob #c'est dans mon ~/.bashrc
  • shopt -s nocasematch #ce serait également ~/.bashrc
  • set completion-ignore-case on #c'est dans mon ~/.inputrc

Comme point de départ, la raison pour laquelle cette question a été posée, et la raison pour laquelle vous y trouverez de nombreuses discussions si vous effectuez une recherche sur Google, est que la sensibilité à la casse rend plus difficile pour les personnes "normales" d'apprendre et d'utiliser un langage de programmation ou une ligne de commande. interface.

La sensibilité à la casse trouve son origine dans la faible puissance des ordinateurs dans le passé. Pour rendre les choses insensibles à la casse, il fallait une opération d'analyse supplémentaire avant que la commande ne soit envoyée à l'interpréteur ou à un compilateur avant son exécution et les premiers concepteurs n'étaient pas prêts à gaspiller l'énergie de l'ordinateur pour la commodité de la casse.

Je pense qu'il y a un certain nombre d'affirmations incorrectes dans les commentaires ci-dessus. Premièrement, les psychologues vous diront que les humains ne font pas automatiquement de distinction entre un mot écrit en lettres majuscules ou minuscules ou même une combinaison des deux en termes de signification du mot. La casse est utilisée dans les langages expressifs normaux pour transmettre une signification supplémentaire. Par exemple, l'utilisation d'une majuscule commençant un mot dans une phrase indique qu'il s'agit très probablement d'un nom propre. Les lettres majuscules sont également utilisées pour donner une structure en prose. Par exemple, une lettre majuscule est utilisée pour indiquer le début d'une phrase. Mais «mot» et «mot» sont considérés par l'esprit humain comme signifiant la même chose.

Les créateurs de DOS et d'ADA et de Pascal, pour n'en nommer que quelques-uns, ont apprécié que la sensibilité à la casse soit un fardeau supplémentaire pour le débutant. Plus tard, les éditeurs de texte des "environnements de développement intégrés" (IDE), reconnaissant un mot de réserve, pourraient refondre ce mot de manière à ce qu'il soit cohérent avec le style de toute façon; et affichez-le dans une couleur différente pour faire ressortir le mot. L'argument selon lequel la sensibilité à la casse rend le code plus lisible est donc fallacieux. Ce n'est pas pour les gens "normaux". Il ajoute simplement une couche inutile et parfois déroutante à une tâche déjà exigeante.

Java est un exemple extrême d'un langage très pauvre du point de vue de la facilité d'utilisation par un débutant. Il applique une sensibilité à la casse stricte mais, stupidement, permettra au programmeur d'avoir deux fonctions, toutes les deux portant le même nom, mais qui sont en fait des fonctions différentes en raison du fait que l'un a un ensemble d'arguments différent de l'autre. En effet, Java est un tel avortement d'un langage que lorsque les universités sont passées de l'enseignement de la syntaxe Pascal aux étudiants, entreprenant des cours non informatiques, le taux de réussite est passé d'environ 70% à 40%.

Donc, en résumé, la sensibilité à la casse est apparue pour deux raisons. L'un était le manque de puissance informatique. La seconde était que les personnes qui se frayent un chemin vers l'informatique sont souvent sur le spectre autistique et ne correspondent pas bien aux besoins des personnes "normales". En conséquence, ces personnes ne peuvent pas comprendre que la sensibilité à la casse est à la fois inutile et un obstacle à l'apprentissage et à l'utilisation d'un langage de programmation.

La sensibilité à la casse est une idée stupide qui est née parce que les rédacteurs Unix ne comprenaient pas que ASCII est conçu pour être facilement insensible à la casse. On ignore simplement les bits de tête. Ascii est un codage à 7 bits avec un A majuscule à la valeur décimale 65 1000001 et un décimal au bit 97 1100001. Les lettres suivent par ordre alphabétique. Cela a généré toutes sortes d'idées telles que toutes les clés dans les paires de valeurs clés doivent être numériques pour éviter que les pantoufles soient différentes des pantoufles. La base de données Pick Multi-Value l'a réalisé dès le début et n'est pas sensible à la casse.