Aaaahhhhh, les joies de l'encodage et des locales différentes... Mais Git ne se configure pas pour pallier à ces problèmes (je sais qu'il gère les retours à la ligne /r/n <-> /n, mais j'ai jamais fait attention aux locales...)

Ben chez moi tout est en UTF8, et ça marche. Git le gère très bien, j'ai des fichiers latex écrits en utf-8.

Je vote pour vous faites une belle bande de pebkac ;)

On utilise un COD après le verbe pallier.

CTLP, il ne faut pas utiliser Git c'est tout. /Troll

Non, là le problème concerne le nom des fichiers, pas le contenu des fichiers. Dans un environnement à la configuration contrôlée, ça ne pose pas de problème le contenu... En revanche, sur certains systèmes, les charsets utilisables pour les noms de fichiers dépendent du système de fichier utilisé !

Mais bon, je pense que le mieux est quand même d'éviter ce genre de problèmes. Je pars du principe que tous ceux qui seront amenés un jour à travailler sur un projet n'auront pas forcément tous ces caractères accessibles sur leur clavier (je travaille souvent avec des équipes internationales). Quant aux espaces, autant les éviter pour simplifier les scripts qu'on aurait éventuellement à faire pour des traitements de masse.

C'est quoi d'abord git ? Encore un truc fait par un type dans son garage !

Charset sur système de fichier est aussi en UTF8 : pas de problèmes. Si la configuration est contrôlée, tu sais aussi ce qu'ils ont sur leur clavier et généralement c'est fait avec le même OS (ça évite les soucis de con.html);)

J'ai des collègues qui préfèrent travailler en qwerty, bien que leur claviers soient étiquetés en azerty... Il y a même un fou qui a configuré son poste en bépo !
/me sifflote

Par un gar même pas barbu en plus !

Ouais bon c'est vrai que normalement ca marche bien en utf-8 mais bon c'est pas une raison pour tenter le diable ...

CTLPEBKAC
Si git a du mal avec les caractères étendus, c'est soit un bug de git soit un bug de la configuration.

Quant-aux devs qui disent « mes scripts ne gèrent pas les espaces », ce sont des feignisses qui méritent la peine capitale. Dans 99 % des cas, protéger une chaine de caractère contre ce problème demande juste de la mettre entre guillemets.

Au temps pour moi, je rectifie donc : *pour pallier ces problèmes

Exercice : faire un traitement de masse en utilisant la commande find avec une version non-GNU (et donc sans l'option -print0).
Vous avez une semaine...

L'option « -print0 » peut être remplacée par « -exec echo -ne "{}/x0" /; », « -exec printf "%s/0" {} /; » ou une construction similaire.
L'option « -exec » permet d'ailleurs souvent d'éviter d'avoir à lire la sortie de « find ». Quand le traitement travaille sur chaque fichier séparément, il suffit de créer une fonction (ou un script) qui fait le traitement et d'appeler cette fonction directement depuis find : « ... -exec fonction {} /; ».

J'ai bien précisé « dans 99 % des cas » : même si tu trouve une exception, ça ne veux pas dire que ce n'est pas *généralement* le cas.

Le gros problème avec -exec est que tu as un fork à chaque match. Dans le cas de grosses arborescences, ça peut devenir très pénible au niveau du temps d'exécution. Franchement, je préfère éviter les problèmes, même si normalement ça devrait marcher. Je pars aussi du principe que très souvent, le client impose des outils, et ce ne sont jamais les mieux codés !

Mouais, enfin vu que dans un script une commande sur deux provoque un fork, je ne suis pas sûr que l'on soit à ça près...

Après je comprends qu'il faille s'adapter à l'environnement, mais critiquer une limitation d'un logiciel n'est pas un PEBKAC.

Justement, tu as là un fork à chaque fichier trouvé.

Le gros intérêt du couple find ... -print0 | xargs -0 ... est que tu peux traiter les fichiers par lots. La différence est vraiment notable quand on parle de milliers de fichiers !