bonjour

dans le tuto d'oc il y a ecrit :

Linux gère sans problème les noms de fichiers et dossiers contenant des espaces, des accents et des majuscules. Toutefois, vous remarquerez que la plupart du temps on préfère les éviter. On trouve ainsi plutôt des noms tout en minuscules sans accents ni espaces, commeusr,bin,apache, etc.
Souvenez-vous qu'il n'est pas obligatoire de nommer vos fichiers en suivant la même règle, mais la plupart des programmes que vous installerez préfèrent utiliser des noms tout en minuscules sans espaces ni accents, ne soyez donc pas surpris.

pourquoi il faut mieux tout ecrire en minuscule sans accents et sans espace ?

Salut,

Plus simple à gérer dans la console, pas besoin d'échapper des caractères et comme ça on peut assurer la compatibilité des noms de fichier avec à peu près tous les OS.

merci pour ta reponse

pour échappement d'accord avec les espaces. par contre les majuscules et les espaces normalement ça doit marché sur tout les os puisqu'ils sont codé sur 7 bits (ascii)

c'est juste pour les accents (codé sur 8 bits) que ça peut poser un soucis, non ?

Pour les majuscules, je dirais que c'est principalement par flemme : il faut appuyer sur une touche de plus pour les faire. Et les espaces, il faut les échapper.

TagAda7 a écrit:

merci pour ta reponse

pour échappement d'accord avec les espaces. par contre les majuscules et les espaces normalement ça doit marché sur tout les os puisqu'ils sont codé sur 7 bits (ascii)

c'est juste pour les accents (codé sur 8 bits) que ça peut poser un soucis, non ?

Pour les accents, oui, le codage peut varier d'un système à un autre (même si UTF-8 est largement le plus répandu je crois). Et puis même pour retaper les noms, toutes les dispositions de clavier ne permettent pas de faire des accents par défaut.

Eviter les espaces, c'est surtout pour éviter les erreurs dans des scripts, petit exemple:

$ ls -l dossier
-r--r--r-- 1 user user 0 Jan 1 00:00 'Un autre fichier'
-r--r--r-- 1 user user 0 Jan 1 00:00 'Un fichier'

Imaginons un script (inutile) qui affiche le contenu de tous les fichiers du dossier:

for fichier in dossier/*; do
    cat $fichier
done

Tu obtiens des erreurs parce que le délimiteur des args de cat est l'espace.

Le but, comme l'a fait remarqué Typhlos est de choisir des noms de fichier simple pour éviter de s'arracher les cheveux. Si tout le monde suit la même convention, c'est beaucoup plus simple.

-
Edité par KoaTao 29 décembre 2019 à 23:57:12

> par contre les majuscules et les espaces normalement ça doit marché sur tout les os puisqu'ils sont codé sur 7 bits (ascii)

Tous les filesystem ne font pas la différence entre majuscule et minuscule. Par défaut, sur windows (partition ntfs), il n'y a pas de différence. Sur linux (ext4), si. Il y a d'autre type de partition et il est possible de les configurer, mais il peut y avoir une différence. Résultat, les fichiers hello.txt et Hello.txt sont des fois les mêmes, des fois différent.

> c'est juste pour les accents (codé sur 8 bits) que ça peut poser un soucis, non ?

Les accents ne sont pas forcement sur 8bits, cela dépend de l'encodage utilisé. Et là aussi c'est dépendant de l'OS :/

Et certains filesystems ont des limitations, par exemple, ntfs n'aime pas les fichiers qui commencent par [ ou contiennent certains caractères (<>:"\|?*).

Sur la console, je trouve que l'auto-complétion fait suffisamment bien le boulot pour ne pas être gêné par les caractères spéciaux ou la différence majuscule/minuscule.

EDIT:

> Tu obtiens des erreurs parce que le délimiteur des args de cat est l'espace.

C'est surtout parce que les gens:

• Ne suivent pas les bonnes pratiques: une variable doit être utilisée avec des double quotes ("$var").
• Utilisent un langage de script assez pénible à se niveau (voir 1 :p) comme bash ou sh. Zsh par exemple n'a pas se comportement.

-
Edité par jo_link_noir 29 décembre 2019 à 23:43:56

jo_link_noir a écrit:

> Tu obtiens des erreurs parce que le délimiteur des args de cat est l'espace.

C'est surtout parce que les gens:

• Ne suivent pas les bonnes pratiques: une variable doit être utilisée avec des double quotes ("$var").
• Utilisent un langage de script assez pénible à se niveau (voir 1 :p) comme bash ou sh. Zsh par exemple n'a pas se comportement.

Je voulais surtout montrer (sans rentrer dans les détails et pas forcément avec le meilleur des exemples j’admets ^^) qu'utiliser des espaces, c'est donner le bâton pour se faire battre.

Je ne suis pas trop d'accord avec le 2nd point, on doit admettre que les gens utilisent tous types de FS mais pas les shells les plus portables et les plus répandus?! Et c'est bien pour ça qu'on doit éviter les noms de fichiers exotiques: parce qu'ils peuvent être réutilisés de plein de manière différentes.

> Je voulais surtout montrer qu'utiliser des espaces, c'est donner le bâton pour se faire battre.

C'est une considération de développeur, les utilisateurs lambdas remplacent rarement les espaces par des _ ou des -. Ce n'est pas les utilisateurs qu'il faut éduquer, mais les développeurs. Pour un dév, c'est plus simple et moins risqué pour le déploiement avec des noms sans espace et caractère spéciaux (et c'est pourquoi les programmes sont ainsi), mais un programme ne devrait jamais considérer que tout l'environnement suit la même convention. Juste sur le nom d'utilisateur, je ne serais pas étonné si les espaces sont acceptés.

> on doit admettre que les gens utilisent tous types de FS mais pas les shells les plus portables et les plus répandus?!

Le shell utilisé se spécifie au début du script. Tout le monde n'utilise pas le même par défaut, il y a du dash, bash, zsh, fish et ksh (pour les principaux) avec chacun des comportements différents. Là aussi c'est un problème de dév, s'il veut bash, il l'indique et met des "" partout. Ce n'est pas que sur les noms de fichier, une chaîne qui contient des espaces va poser le même problème (exemple: une recherche de morceau de phrase avec grep). D'ailleurs, seuls les langages de type shell ont des "problèmes" avec les espaces.

Le seul réel problème avec un nom "exotique", concerne les limitations entre device. Les partitions linux accepte un peu près tout, une clef usb en fat ou ntfs (les plus courant) rejette certaines choses. Et le problème ne se situe pas sur les accents qui sont finalement bien supportés, mais plutôt les symboles ascii.

-
Edité par jo_link_noir 30 décembre 2019 à 1:34:03

ok merci.

et pour remplacer les espaces je vois beaucoup de personnes mettre de underscore (tiret du 8)

mais si on met un trait d'union tirer du 6 c'est bien aussi, non ?

Aucune différence, c'est juste que _ n’apparaît dans aucun mot/phrase, alors que certains groupes de mots contiennent des -. Et aussi parce que - n'est pas un caractère valide dans beaucoup de langage de programmation, je suppose que cela joue.

Je suis tombé complètement par hasard sur ça aujourd'hui:

https://dwheeler.com/essays/fixing-unix-linux-filenames.html

https://dwheeler.com/essays/filenames-in-shell.html

C'est un peu de lecture, mais c'est totalement dans le thème. Et ça résume bien (avec de bons exemples ) l'ampleur du problème.

Franchement c'est archaïque de vouloir se contenter de fichiers ascii. Quand j'extrais les musiques de CD audio que j'achète je suis bien content que les accents et autres caractères restent. Après il est clair que si tu utilises la ligne de commande tu devras souvent mettre des guillemets ou utiliser la tabulation qui fait tout pour toi. Concernant l'encodage, c'est une mauvaise raison, n'importe quelle personne sensée utilise UTF-8 qui est l'encodage par défaut.

Si seulement Windows utilisait UTF-8... Bon, on pourrait argumenter sur la sanité chez Microsoft, mais ce serait un sujet trop trollesque. Moi, troller? Noooooooon.