Pourquoi le terminal est-il sensible à la casse?

En fin de count, 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 l'ont fait les créateurs de MS-DOS une décennie plus tard, mais cela a aussi ses inconvénients.

Il est trop profondément ancré dans * ix la culture pour changer maintenant. Le problème de système de files sensible à la casse soulevé par eppesuig n'en est qu'une partie. Les systèmes Mac OS X – qui sont basés sur Unix – ont généralement des filesystems insensibles à la casse, de sorte que, sur de tels systèmes, les commands externes au shell sont en fait traitées sans distinction de casse. Mais, les builtins comme cd restnt sensibles à la casse.

Même avec un système de files insensible à la casse, l'histoire des choses complote contre vos souhaits, Hussain. Si je tape ls sur mon Mac, j'obtiens une list de directory colorisée. Si je tape LS place, /bin/ls s'exécute toujours, mais la list n'est pas colorée parce que l'alias qui ajoute le drapeau -C est sensible à la casse.

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

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

Les systèmes techniques que j'utilise et respecte sont presque exclusivement sensibles à la casse: que ce soit un OS ou un 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, ainsi que 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 parameters en majuscules). (Corrigez-moi si je me trompe.) Quant à Ada, le mode Emacs vous corrigera si vous tapez par exemple un nom de procédure en minuscules, même si cela n'a pas d'importance lors de la compilation. Donc, même quand il y a une insensibilité à la casse, il semble que les gens s'accordent à dire que c'est une mauvaise idée.

La raison en est que vous obtenez beaucoup plus de pouvoir expressif avec la sensibilité à la casse. Non seulement quantitativement – CD est un, mais CD , Cd , cD et cd sont quatre – mais plus important encore, vous pouvez exprimer le but, 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 hi et HI la même façon!

Mais, pour vous donner un exemple de monde informatique, dans le langage de programmation Ada (à partir 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 des procédures et des parameters sont en majuscules, tout comme les types de données, tout le rest est minuscule. Notez également que le nom du paramètre "tout en majuscules" indique que c'est un acronyme. Maintenant, comparez ceci à

 procedure body p(scb : in out semaphore_control_block) is 

Ceci est possible, car Ada est insensible à la casse (ou, pour être exact, le compilateur le changera comme 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 (eh bien, peut-être pas). Point est, un système sensible à la casse ne forcera pas seulement les gens à être cohérent, ils seront également aidés par elle (lisibilité) et l'utiliseront à leur avantage (l'exemple ci-dessus).

Ce n'est pas plus ou less étrange que le fait que nous ayons un alphabet majuscule et minuscule pour commencer. Si vous regardez dans /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 exponentiellement avec la longueur du mot. Par exemple, en utilisant 26 caractères, il y a 26 ^ 3 (17576) différentes possibilités 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 cas «supérieur / inférieur» peut être (et est en fait) une chose spécifique aux parameters locaux qui, comme toute autre complication de design doit être poussée aussi près que possible du point d'utilisation dans la stack d'application, ne fait pas partie du coeur.

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

Comme sharepoint départ, la raison pour laquelle cette question a été posée et la raison pour laquelle vous y findez beaucoup de discussions si vous faites de Google sur le sujet est que la sensibilité à la casse rend plus difficile l'apprentissage et l'utilisation d'un langage de programmation ou d'une command line interface.

La sensibilité à la casse a ses origines dans la faible puissance des ordinateurs dans le passé. Pour rendre les choses insensibles exigées une opération d'parsing supplémentaire avant la command a été fournie à l'interpréteur ou à un compilateur avant son exécution et les premiers concepteurs n'étaient pas prêts à gaspiller la puissance de l'ordinateur pour la commodité de la sensibilité à la casse.

Je crois qu'il y a un certain nombre d'affirmations incorrectes dans les commentaires ci-dessus. Tout d'abord, les psychologues vous diront que les humains ne font pas automatiquement de discrimination entre un mot écrit en majuscules ou en minuscules ou même une combinaison des deux en termes de signification du mot. Le cas est utilisé dans les langues expressives normales pour donner un sens supplémentaire. Par exemple, l'utilisation d'une lettre majuscule qui commence un mot dans une phrase indique que c'est probablement un nom propre. Les 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 "Parole" et "Parole" sont considérés par l'esprit humain comme signifiant la même chose.

Les créateurs de DOS et d'ADA et Pascal, pour n'en nommer que quelques-uns, ont apprécié que la sensibilité à la casse était un fardeau supplémentaire pour le débutant. Plus tard, les éditeurs de text dans les «Environnements de Développement Intégrés» (IDE), reconnaissant un mot de réserve, pourraient reformuler ce mot de manière à ce qu'il soit cohérent avec le style de toute façon; plus l'afficher dans une couleur différente pour faire ressortir le mot. Ainsi, l'argument selon lequel la sensibilité à la casse rend le code plus lisible est fallacieux. Cela ne concerne pas 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 sharepoint vue de la facilité d'utilisation par un débutant. Il impose une ssortingcte sensibilité à la casse mais, stupidement, permettra au programmeur d'avoir deux fonctions, toutes les deux du même nom, mais qui sont en fait des fonctions différentes du fait que l'on a un set différent d'arguments à 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, en passant par 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 de l'ordinateur. La deuxième est que les personnes qui se retrouvent dans 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 apprécier que la sensibilité à la casse est à la fois inutile et un obstacle à l'apprentissage et à l'utilisation d'un langage de programmation.