Est-ce que bash sous OSX est insensible à la casse ?

Question

Est-ce que bash sous OSX est insensible à la casse ?

Demandé el 17 de Août, 2011: Quand la question a-t-elle été
68151 affichage: Nombre de visites la question a
5 Réponses: Nombre de réponses aux questions
Résolu: Situation réelle de la question

Les commandes bash sous OSX sont-elles insensibles à la casse ? Je tape "which TR" et il affiche /usr/bin/TR, bien que ce binaire n'existe pas. Même chose pour les autres binaires, lorsqu'ils sont en majuscules. Ou est-ce que Terminal.app effectue cette traduction ? Comment puis-je désactiver cette fonction ?

Demandé el 17 de Août, 2011 par verboze

0 votes

Par curiosité, pourquoi voulez-vous désactiver cette fonction ?

Commenté el 17 de Août, 2011 par Sören Kuklau

0 votes

C'est une question spectaculaire. Bash a un nocaseglob pour contrôler si les cas correspondent à des plages, mais ce petit tour de passe-passe est plus profond que l'option normale locale y complétion-ignore-case / nocaseglob

Commenté el 17 de Août, 2011 par Oskar

6 votes

La raison pour laquelle je voulais l'éteindre est stupide, vraiment. Je suis habitué à la sensibilité à la casse lorsque je travaille sur le shell. Je suis juste inquiet que cette fonctionnalité me fasse trébucher. Par exemple, j'écris un bash , je fais une erreur en tapant 'lS' ; le script fonctionnera bien sous OSX. Je le déplace sur ma boîte cenTOS, et il se casse. Accordé, ce serait facile à détecter et à corriger, mais pourrait éviter le scénario entièrement si je pouvais garder les fonctionnant de la même manière entre les deux systèmes. J'ai découvert cela par accident, et cela n'a pas été une nuisance jusqu'à présent, donc je ne vais probablement pas passer par l'exercice de changer les systèmes de fichiers juste pour cela.

Commenté el 19 de Août, 2011 par verboze

Afficher 5 autres commentaires

Answer 1

5 Réponses

Answer 2

114voto

Rizwan Sattar Points 121

Il s'agit en fait d'une caractéristique du système de fichiers de votre disque, et non de bash ou de Terminal.app.

HFS+ (le système de fichiers du Mac) est généralement configuré pour être insensible à la casse mais préservation du cas . Cela signifie que le système de fichiers considérera foo y FoO sont les mêmes, mais lorsque vous créez un nouveau fichier, il se souviendra des lettres qui étaient en majuscules et de celles qui ne l'étaient pas.

Lorsque vous formatez un disque avec HFS+, vous pouvez choisir si le système de fichiers doit respecter la casse ou non. Si vous choisissez de formater avec UFS (Unix FileSystem), il est toujours sensible à la casse, AFAIK.

Pour vérifier si un disque est sensible à la casse, exécutez :

 diskutil info <device>

Par exemple :

 diskutil info disk0s2

Cherchez le Name: ligne. Si vous lisez quelque chose comme Mac OS Extended (Case-sensitive, Journaled) cela signifie qu'il est sensible à la casse. Si on lit simplement Mac OS Extended (sans le Case-sensitive ), alors c'est seulement préservation du cas mais pas sensible à la casse .

Répondu el 17 de Août, 2011 par Rizwan Sattar (121 Points )

0 votes

HFS+ est un peu bizarre, car il est capable de reconnaître et d'ignorer les cas de figure. en même temps . Votre remarque sur la préservation de la casse était absente de ma réponse, et elle est importante pour un système d'exploitation basé sur Unix qui devrait normalement respecter la casse lorsque Foo et FOO sont deux fichiers différents. Je soupçonne que le comportement est apparu entre Mac OS 9 HFS et Mac OS X HFS+ et la nécessité d'être compris par les applications classiques et nouvelles, etc.

Commenté el 17 de Août, 2011 par stuffe

7 votes

En dehors d'Unix, la conservation des cas n'est pas si inhabituelle. Par exemple, NTFS est similaire : il n'est pas sensible à la casse par défaut, mais vous pouvez le formater pour qu'il le soit. Je pense également que le Par défaut, la casse n'est pas prise en compte Je suis venu par Mac OS 9, mais le fait que beaucoup de développeurs Mac et Windows sont paresseux à cet égard et ne se soucient pas de la casse correcte rend presque impossible le passage à la casse par défaut, ce qui casse beaucoup d'applications. Venant d'Unix, j'ai également trouvé cela très étrange au début.

Commenté el 17 de Août, 2011 par Rizwan Sattar

0 votes

Je ne suis pas retourné en arrière et n'ai pas regardé, mais je suis presque sûr que Mac OS a utilisé des systèmes de fichiers préservant la casse (mais non sensibles à la casse) depuis le Mac original de 1984 (qui utilisait MFS -- Macintosh File System -- pour formater ses disquettes de 400k).

Commenté el 17 de Août, 2011 par Gordon Davisson

Afficher 6 autres commentaires

Answer 3

10voto

FreddyBushBoy Points 171

J'ai réussi à résoudre ce problème en une seule ligne en suivant les instructions suivantes http://blog.nickburwell.com/blog/2008/11/mac-os-x-terminal-case-insensitive-auto

echo "set completion-ignore-case On" >> ~/.inputrc

Répondu el 31 de Décembre, 2013 par FreddyBushBoy (171 Points )

0 votes

Cette réponse semble être la seule qui réponde à la question "comment puis-je désactiver cette fonction" de l'OP.

Commenté el 15 de Décembre, 2019 par Chaim Eliyah

Answer 4

6voto

stuffe Points 25320

Jetez un coup d'œil à votre système de fichiers, car il existe des variantes de HFS sensibles à la casse et d'autres non sensibles à la casse. Par défaut, le système est insensible à la casse. Dans ce cas, ce n'est pas tant BASH qui est en cause, mais le système de fichiers sous-jacent. Vous pouvez tester cela en formatant une clé USB de rechange avec l'option de sensibilité à la casse, et en copiant les fichiers dessus pour répéter votre test, etc.

Répondu el 17 de Août, 2011 par stuffe (25320 Points )

Answer 5

2voto

Simon Points 558

C'est votre système de fichiers.

J'utilise APFS, il est également insensible à la casse mais préserve la casse. Voici poste fournit une bonne explication sur H(ierarchical)FS et APFS.

#include <sys/stat.h>
#include <iostream>

int main(int argc, char **argv) {
    struct stat sb;
    int ret = stat(argv[0], &sb);
    std::cout << ret << std::endl;
}

sortie de ce programme en utilisant stat :

$ ./a.out ./test_dir/cat.png
0
$ ./a.out ./test_dir/caT.png
0

un simple test bash

$ cp cat.png caT.png
cp: caT.png and cat.png are identical (not copied).

Quant à bash, je crois qu'il n'est pas non plus sensible à la casse sur Mac OS si vous utilisez le HFS ou l'APFS par défaut puisque l'exécutable de la commande est aussi un fichier et que lorsque vous tapez un nom de commande, le nom est utilisé pour effectuer une recherche dans le PATH pour trouver ce fichier à exécuter.

$ echo x X
x X
$ eChO x X
x X

Répondu el 7 de Janvier, 2020 par Simon (558 Points )

Answer 6

1voto

elves Points 11

Bash est définitivement sensible à la casse.

Je viens de taper whoami dans le terminal et le bouton de verrouillage des majuscules était activé.

J'ai eu une réponse complètement différente de WHOAMI .

Je peux voir qu'il y a un WHOAMI avec which mais je ne peux pas le trouver avec ls .

Répondu el 21 de Avril, 2017 par elves (11 Points )

9 votes

Ce n'est pas l'interpréteur de commandes qui est sensible à la casse, c'est l'interpréteur de commandes qui est sensible à la casse. whoami le programme lui-même. C'est en fait le même programme que id mais il vérifie sous quel nom il a été exécuté, et utilise une sortie différente (équivalent à id -un ) s'il est exécuté sous le nom de "whoami". Ce La vérification est sensible à la casse. Comparez la sortie de id , WHOAMI , WhOaMi , WhoAmI etc. Comparez également la sortie de ls -li /usr/bin/whoami vs ls -li /usr/bin/WHOAMI et notez que le numéro d'inode (la première chose listée dans la sortie) est le même - ce sont deux façons différentes de spécifier exactement le même fichier.

Commenté el 21 de Avril, 2017 par Gordon Davisson

Est-ce que bash sous OSX est insensible à la casse ?

Réponses

Questions en vedette

Top Tags

LesApples.com

Powered by:

Est-ce que bash sous OSX est insensible à la casse ?

Réponses

Questions connexes

Questions en vedette

Top Tags

Dans notre réseau

LesApples.com

Powered by: